[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
Robert Moskowitz
MIS Technical Support
Chrysler Corporation
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04620;
3 Aug 93 10:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04612;
3 Aug 93 10:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05603;
3 Aug 93 10:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04578;
3 Aug 93 10:34 EDT
Received: from babyoil.ftp.com by IETF.CNRI.Reston.VA.US id aa02861;
3 Aug 93 9:13 EDT
Received: by ftp.com
id AA14710; Tue, 3 Aug 93 09:14:31 -0400
Date: Tue, 3 Aug 93 09:14:31 -0400
Message-Id: <9308031314.AA14710 at ftp.com>
To: ALH at eagle.es.net
Subject: Re: Last Call: Use of ISO CLNP in TUBA
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Frank Kastenholz <kasten at ftp.com>
Reply-To: kasten at ftp.com
Cc: ietf at IETF.CNRI.Reston.VA.US
Tony Hain says:
> It is not clear that a 'large constituency' belives we do, so much as a
> 'vocal constituency'. The IETF does not NEED change control for anything
> more than a justification to block progression of work on the RFC track.
> Several people have pointed out external references (ethernet, fddi, etc...)
> that the IETF has no change control over. There have also been discussions
> about what the REAL customer wants here, and what I see is they want to
> keep running their existing applications. The TUBA effort is an attempt to
> do exactly that with a minimum of disruption.
>
> The TUBA effort should be allowed to progress on the basis that it has met
> the established requirements that any proposal needs to. It should not be
> blocked because a vocal contingent keeps throwing out smoke screens.
Tony,
I find this statement deeply disturbing.
The IETF has claimed for itself the territory of building a ubiquitous
global Internetwork. The critical protocols for that goal are the
internetwork-layer protocol (now IP, someday will be IPng) and its
associated routing protocols. Without these protocols being correct
(whatever that means), we simply can not do what we have set out to do.
The internetwork-layer protocols are ubiquitous. By and large, they define
what The Internet is. This set of protocols, by being common and
ubiquitous, is what creates this single environment in which all hosts
on the net can play as equals. Not a small number of people consider
"Internet Connectivity" to be nothing less than IP connectivity -- if
you can not ping sri-nic.arpa then you are not really on the net. So,
this set of protocols defines what we are and what we are trying to do.
It is the essence of our being, our soul if you will (sorry to get
a bit away from technology but this issue is not completely based in
technology).
If we give up control of the internet layer to someone else, whether
that someone else is the ISO or, for that matter, me, we will be giving
up that which defines what we are doing.
The other external standards are all secondary to this goal. If Ethernet
changes, we will change the protocols related to IP-Over-Ethernet and
life will go on. Ethernet is not ubiquitous, nor as essential to the
health of The Internet as IP is. Also, they are simply outside of the
realm of what we, as an organization, have staked out as "our turf."
In a twisted sort of way, the standards for FDDI or Ethernet are about
as relevant as the standards for screw threads. We use things built
to these standards to build our boxes, but that is all. If there were
no standards for screw threads, we'd use something else to put together
our boxes (glue, rivets, chewing gum -- it doesn't matter).
FDDI, Ethernet, et al, are components out of which we build parts of our
network, but they define what The Internet is about as much as the
screws that hold our routers together do.
You mention the "REAL customer." The IETF has two "customers", one is The
Internet and all the folks who are connected to it, and the other is all
the people who are not connected to The Internet, but use IP anyway.
Generally we have to balance the sometimes contradictory needs of these
two groups. However, I see no real balancing issue here.
The people who are not connected to The Internet can continue to use
IPv4 forever. What works today will work tomorrow. I do not see any
problems here.
If we do not field the "correct" IPng then the Internet as we know it
will fade away and the people who are connected to the Internet will no
longer be connected to it. In short, they will join the second group of
"customers" and they can run IPv4 forever and there will be no problems.
So, it seems to me that our overriding goal here must be to keep The
Internet viable. Anything less means that The Internet will die,
everyone will stay with IPv4 -- or whatever other internet-layer
protocol(s) strike their fancy -- and at best we will have a balkanized
network.
--
Frank Kastenholz
FTP Software
2 High Street
North Andover, Mass. USA 01845
(508)685-4000
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06364;
3 Aug 93 11:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07690;
3 Aug 93 11:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06347;
3 Aug 93 11:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06153;
3 Aug 93 11:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07476;
3 Aug 93 11:49 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06145;
3 Aug 93 11:49 EDT
To: IETF-Announce: ;
Subject: TN3270E BOF at INTEROP
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
Date: Tue, 03 Aug 93 11:49:29 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9308031149.aa06145 at IETF.CNRI.Reston.VA.US>
AGENDA
TN3270 Enhancements BOF
INTEROP 93 Meeting
August 26, 1993
7:30 - 9:30 (= 19:30 - 21:30)
We expect new faces and we have a lot to cover, with only two
hours, so at the very least we shouldn't get bored.
19:30-19:45
1. Introductions and purpose of the TN3270E WG. 15 min
19:45-20:00
2. Condensed version of the IETF 26 presentation that led to the
formation of this Working Group.
20:00-21:00
3. Discussion and feedback of current RFC drafts.
"Current TN3270 practices" - An Informational RFC
"LUname/Printer Selection" - An Experimental RFC proposal from
Open Connect Systems
"TN3270 Enhancements" - The TN3270 Standards RFC
21:00-21:15
4. Where do we go from here?
Implementation recommendations
Any other general TELNET options to cover?
Promoting drafts to RFCs.
Vendor interest in implementing "TN3270 Enhancements" and
user testing.
21:15-21:30
5. Wrap up. See you all on the list.
Robert Moskowitz
Chrysler Corporation
TN3270E WG Chair
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07002;
3 Aug 93 12:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06995;
3 Aug 93 12:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08764;
3 Aug 93 12:32 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06985;
3 Aug 93 12:32 EDT
Received: from large.cisco.com by IETF.CNRI.Reston.VA.US id aa06960;
3 Aug 93 12:30 EDT
Received: by large.cisco.com id AA07577
(5.67a/IDA-1.5 for ietf at IETF.CNRI.Reston.VA.US); Tue, 3 Aug 1993 09:31:20 -0700
Date: Tue, 3 Aug 1993 09:31:20 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199308031631.AA07577 at large.cisco.com>
To: 0003858921 at mcimail.com
Cc: ALH at eagle.es.net, ietf at IETF.CNRI.Reston.VA.US
In-Reply-To: "Robert G. Moskowitz"'s message of Tue, 3 Aug 93 10:56 GMT <00930803105600/0003858921NA1EM at mcimail.com>
Subject: Last Call: Use of ISO CLNP in TUBA
In someelse's message a few days ago a point was made that CLNP filters on
host, whereas IPv4 filters on network or host or port or any combination.
WE USE FILTERS HERE! They are admin pains, but in some cases real
important. In some cases a single filter insures that traffic for one plant
routes directly to corporate instead of through another plant (even when the
'cost' of the plant-plant-corp connection is 'cheaper'). This single filter
is controlling a few hundred device's traffic. If we have to use a few
hundred filters instead....
So filters would be one area where you would have to make changes to CLNP.
The flexibility of filters in a CLNP router implementation is not a CLNP
protocol issue, but mainly an implementation issue. The one pertinent
architectural issue is that CLNP addresses do not map to individual media
wires like IP (in my opinion, a feature, not a bug), so the effective
granularity of filters is per IS-IS area (or per host). This seems like
a reasonable policy point to do filtering.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07574;
3 Aug 93 13:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07567;
3 Aug 93 13:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09839;
3 Aug 93 13:04 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07557;
3 Aug 93 13:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07523;
3 Aug 93 13:02 EDT
Received: from aerospace.aero.org by CNRI.Reston.VA.US id aa09767;
3 Aug 93 13:02 EDT
Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT)
id AA03372 for ietf at cnri.reston.va.us; Tue, 3 Aug 1993 10:00:30 -0700
Posted-Date: Tue, 03 Aug 1993 10:00:07 -0700
Message-Id: <199308031700.AA03372 at aerospace.aero.org>
Received: from merlin.aero.org by antares.aero.org (4.1/AMS-1.0)
id AA29343 for to:cnom at maestro.bellcore.com; Tue, 3 Aug 93 10:00:21 PDT
To: Hannu Toivonen <htoivone at tele.nokia.fi>, To: cnom at maestro.bellcore.com;,
ietf at CNRI.Reston.VA.US, snmp at uu.psi.com, rmonmib at jarthur.claremont.edu
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
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,
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>
Cc: yoshida at nttops.ntt.jp, Makoto Yoshida <myoshida at attmail.com>,
Shri Goyal <goyal at gte.com>
Subject: All Submissions to Shri Goyal
Date: Tue, 03 Aug 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: Joe Betser <betser at aero.org>
Dear NOMS Contributor :
As per the instructions at the attached Call for Submissions,
we would like to emphasize that submissions are coordinated by Shri Goyal
of GTE.
We have had several questions on the submission address. Submissions are
expected by our Technical Program Chair:
SUBMIT TO :
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
From: htoivone at tele.nokia.fi (Hannu Toivonen)
Message-Id: <9308021545.AA29358 at tnso06.tele.nokia.fi>
Subject: NOMS '94
To: betser at aero.org
Date: Mon, 2 Aug 93 18:45:34 EET DST
X-Mailer: ELM [version 2.3 PL11]
Dear Dr. Betser
We intend to submit a presentation to NOMS '94, but we are still
lacking the detailed instructions for submissions.
All we know so far is that the presentation should consist of
about 10 visuals with explanatory text, and that the dead-line
is August 10.
Could you please inform us at the earliest convenient point
about the exact format of presentations, the number of copies
to submit, and the address where they should be sent to.
Thank you!
with kind regards,
Hannu Toivonen
++++
Subject: NOMS 94 - Invitation to Submit
Date: Wed, 21 Jul 1993 18:22:21 -0700
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.)
SUBMIT TO :
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
------- End of Forwarded Message
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07704;
3 Aug 93 13:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07695;
3 Aug 93 13:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09965;
3 Aug 93 13:09 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07680;
3 Aug 93 13:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07589;
3 Aug 93 13:07 EDT
Received: from vela.acs.oakland.edu by CNRI.Reston.VA.US id aa09905;
3 Aug 93 13:07 EDT
Received: from via.dsf4.merit.edu by vela.acs.oakland.edu with SMTP id AA29926
(5.65c+/IDA-1.4.4); Tue, 3 Aug 1993 13:08:22 -0400
Date: Tue, 3 Aug 93 12:36:59 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Allen Simpson <bill.simpson at um.cc.umich.edu>
Message-Id: <933.bill.simpson at um.cc.umich.edu>
To: ietf at CNRI.Reston.VA.US
Reply-To: bsimpson at morningstar.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA
> 'However, there is another issue: change control. I don't think that
> anything from the TUBA WG should be published by the IETF except as
> "informational", just as any other proprietary protocol.'
>
> Which was the first time in my life I had heard a de jure standard referred
> to as proprietary.
>
Eva apparently missed the word "other" in her reading, even when quoting.
> Working with the extensions first, prototyping them, and then adding them
> to the ISO CLNP standard does not really seem to me to be such a difficult
> path to follow. The workers on both sides (it is the same people, after all!)
vv
Eva argues that TUBA changes have to be added to the ISO CLNP standard.
Since that is outside the scope of the IETF process, she is arguing
against her own case.
> instead of accepting that it already works this way. In the meantime, this
> process is what has been followed informally for a long time and what you
> have coming out now has incorporated ideas from IETF already. It is already
> working! What counts is getting the job done, not whose name is on it.
>
Good. But this discussion is about the IETF Standards, not other
bodies' standards.
I thank the CLNP proponents for reaching consensus that the TUBA work
engendered in the IETF be submitted to OSI for incorporation.
Should the TUBA WG continue to exist to shepherd its recommendations
through the OSI standards process, or should it be dissolved when OSI
creates its own group to consider the recommendations? I request the
latter, to avoid inconsistency and conflict.
Bill.Simpson at um.cc.umich.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07919;
3 Aug 93 13:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07912;
3 Aug 93 13:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10212;
3 Aug 93 13:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07897;
3 Aug 93 13:17 EDT
Received: from mcigateway.mcimail.com by IETF.CNRI.Reston.VA.US id aa07849;
3 Aug 93 13:15 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ac24401;
3 Aug 93 16:27 GMT
Date: Tue, 3 Aug 93 16:31 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: ietf <ietf at IETF.CNRI.Reston.VA.US>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Message-Id: <05930803163150/0003858921NA2EM at mcimail.com>
I said:
>>In some cases a single filter insures that traffic for one
>>plant routes directly to corporate instead of through another
>>plant (even when the 'cost' of the plant-to-plant connection
>>is 'cheaper'). This single filter is controlling a few
>>hundred device's traffic. If we have to use a few hunder
>>filters instead...
I received a private response:
>You *don't* have to use a few hunder filters instead. You just assign
>addresses to these 'few hundred devices' in such a way that they'll
>have a common prefix and install a *single* filter for that prefix. For
>example, if these devices are on a common subnetwork then you turn this
>subnetwork into an area. So, that it will look pretty much like addresses
>on an IP subnetwork.
This sounds OK to me, if this is correct, and the sender is known to me as
someone who really knows this stuff, then CLNP filtering seems workable.
Now all we need is DOS CLNP/TUBA implementations that do not use any more
memory than the TCP/IP stuff of today...
Robert Moskowitz
Chyrsler Corp
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08358;
3 Aug 93 13:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08350;
3 Aug 93 13:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11022;
3 Aug 93 13:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08339;
3 Aug 93 13:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08303;
3 Aug 93 13:49 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa10924;
3 Aug 93 13:49 EDT
Received: by ginger.lcs.mit.edu
id AA21136; Tue, 3 Aug 93 13:49:29 -0400
Date: Tue, 3 Aug 93 13:49:29 -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: <9308031749.AA21136 at ginger.lcs.mit.edu>
To: 0003858921 at mcimail.com, dkatz at cisco.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
> In some cases a single filter insures that traffic for one plant routes
> directly to corporate instead of through another plant... This single
> filter is controlling a few hundred device's traffic. If we have to use
> a few hundred filters instead....
The one pertinent architectural issue is that CLNP addresses do not map to
individual media wires like IP (in my opinion, a feature, not a bug), so
the effective granularity of filters is per IS-IS area (or per host).
One way to get IP-like behaviour is to follow an IP-like model and give each
wire a separate level 1 area identification. Of course, this sort of voids
some of the advantages of the NSAP idea, which allows hosts to move among the
wires of a level 1 area without changing their address. However, to the extent
that an administrative entity which you wish to make a single policy statement
about has a number of media wires, each currently with a separate IP subnet
number, you could actually *reduce* the number of access control terms (i.e.
filters) by making it a single level 1 area.
There are, of course, other forces pushing back on making giant level 1 areas,
to increase host mobility; the larger and larger you make your level 1 areas,
it does increase the routing overhead, since, as you point out, CLNP routing
keeps track of each end-system individually inside a level 1 area. It's a
multi-way tradeoff of routing overhead versus mobility scope versus policy
control conciseness.
CLNP can be seen as giving you a little more flexibility than IP here, but you
could get many of the same effects in IP by a combination of bridges and IP
routers (bridge together all the wires which would want to form an 'IP level 1
area'), albeit with some missing capabilities, such as level 1 partition
repair, which you get in CLNP (partially as a result not having two different
routing systems at different layers in the stack, but that's a different
debate :-).
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09842;
3 Aug 93 14:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09827;
3 Aug 93 14:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13391;
3 Aug 93 14:58 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09813;
3 Aug 93 14:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09759;
3 Aug 93 14:56 EDT
Received: from relay.hp.com by CNRI.Reston.VA.US id aa13329; 3 Aug 93 14:56 EDT
Received: from hpindda.cup.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA01727; Tue, 3 Aug 93 11:57:24 -0700
Received: by hpindda.cup.hp.com
(15.11/15.5+IOS 3.20+cup+OMrelay) id AA02778; Tue, 3 Aug 93 11:57:10 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: <9308031857.AA02778 at hpindda.cup.hp.com>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: bsimpson at morningstar.com
Date: Tue, 3 Aug 93 11:57:07 PDT
Cc: ietf at CNRI.Reston.VA.US, eva at hpindda.cup.hp.com
In-Reply-To: <933.bill.simpson at um.cc.umich.edu>; from "William Allen Simpson" at Aug 3, 93 12:36 (noon)
Mailer: Elm [revision: 64.9]
Bill,
>
> > 'However, there is another issue: change control. I don't think that
> > anything from the TUBA WG should be published by the IETF except as
> > "informational", just as any other proprietary protocol.'
> >
> > Which was the first time in my life I had heard a de jure standard referred
> > to as proprietary.
> >
> Eva apparently missed the word "other" in her reading, even when quoting.
Actually, the word other is the one which makes it sound like it is being
referred to as an other proprietary protocol. So I have to read that
sentence with the same pauses that you are putting there mentally to make
it read the way you think I should read it. If you say that's what it
really means, fine, I misunderstood. I'll try reading it again later :-)
>
>
> > Working with the extensions first, prototyping them, and then adding them
> > to the ISO CLNP standard does not really seem to me to be such a difficult
> > path to follow. The workers on both sides (it is the same people, after all!)
> vv
> Eva argues that TUBA changes have to be added to the ISO CLNP standard.
> Since that is outside the scope of the IETF process, she is arguing
> against her own case.
I did not say that they are needed now. All I said was that if they are needed
this is not a problem. After all, the Internet did not write IP either. It
came from Darpa, right? So a precedent has already been set for using
someone else's network protocol and adding enhancements. Enhancements don't
even need for the protocol machine to change. Policy enhancements are really
protocol independent as many have pointed out already. The extensions that
are being worked on, like multicasting, are already being done in ISO thanks
to the work of the IETF folks. So we have been doing already what people
claim would fail to work. CLNP is already an Internet protocol. This is
TCP and UDP over CLNP just takes advantage of this. CLNP enhancements
have been ongoing, with IDRP being the latest addition. Multicasting is
already progressing. So I am not arguing against my own case. I am
just saying that the process already works to collaborate so I am puzzled
why there are folks who think it wouldn't work. It just really does not
matter much where the work is being done as long as it gets done.
>
>
> > instead of accepting that it already works this way. In the meantime, this
> > process is what has been followed informally for a long time and what you
> > have coming out now has incorporated ideas from IETF already. It is already
> > working! What counts is getting the job done, not whose name is on it.
> >
> Good. But this discussion is about the IETF Standards, not other
> bodies' standards.
It is also about recognition of an existing standard to be used on
the Internet. Any RFC can validly point to an existing stable
standard. I really fail to understand the issue of control. The
Implementors Workshops develop implementors agreements based on the
ISO and CCITT base standards. This is pretty similar to an RFC. We
send defect reports in as we find them. When something is not in the standard
we write recommended practices documents. We write International Standardized
Profiles and submit them to ISO for publication. The OIW documents are
kept online at NIST. None of the workshops have asked for change control
on the ISO documents. They do comment on enhancements. But the thought
that was proposed about an ISP for the CLNP for the Internet is intriguing.
At various times bodies other than the Regional Workshops have developed
ISPs and this is something that should be investigated. It might just
be possible. In this case the editing organization retains the change
control on the ISP since it retains the maintenance role for the ISP.
Any thoughts from the TUBA Folks on this one?
>
> I thank the CLNP proponents for reaching consensus that the TUBA work
> engendered in the IETF be submitted to OSI for incorporation.
>
> Should the TUBA WG continue to exist to shepherd its recommendations
> through the OSI standards process, or should it be dissolved when OSI
> creates its own group to consider the recommendations? I request the
> latter, to avoid inconsistency and conflict.
I don't think there is either inconsistency or conflict. All that needs
to be done is what is done for any other RFC. The group is developing
a methodology for use on the Internet. It is pointing to standards developed
by ISO. It is running TCP applications over the standards from ISO. I see
no reason why the TUBA group should be in ISO. A working collaboration
between IETF and ISO is an excellent way grow CLNP. It may not need to
grow. It may need to grow. Either way, the strong liaison is already
there and should be encouraged, not discouraged. I don't see any reason
yet why the Internet community cannot work collaboratively with the
ISO community to do joint development of standards which both communities
use today. But the rest of the TUBA work involves the use of existing
Internet applications over an ISO protocol on the Internet so the group
definitely belongs in IETF, not ISO, although it makes valuable
contributions to ISO.
Eva
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09927;
3 Aug 93 15:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09920;
3 Aug 93 15:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13535;
3 Aug 93 15:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09910;
3 Aug 93 15:02 EDT
Received: from atc.boeing.com by IETF.CNRI.Reston.VA.US id aa09870;
3 Aug 93 15:00 EDT
Received: by atc.boeing.com (5.57)
id AA17282; Tue, 3 Aug 93 12:05:30 -0700
Date: Tue, 3 Aug 93 12:05:30 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Eric Fleischman <ericf at atc.boeing.com>
Message-Id: <9308031905.AA17282 at atc.boeing.com>
To: ALH at eagle.es.net, ietf at IETF.CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: ericf at atc.boeing.com
Dear Noel,
I have been a member of this list for roughly two years. During this
time I have formed an extremely high opinion of many of the regular
list participants (including you) and have read your many comments with
great interest. I hope someday to get to meet you because I find your
input to be most informative and valuable. However, the purpose of this
note is to publically respond to the final paragraph of your last posting:
>This whole episode is putrid and repellent. If we are to be sentenced to
>enduring this sort of thing as long as we are trying to integrate the ISO and
>TCP/IP communities, I for one am ready to give up on that goal. There are real,
>major, technical problems out there, and I want to spend my time on them, not
>this drivel.
>
> Noel
I must say that I share the frustration you are expressing. It appears
to me that some list participants are really not *listening* to what
others are saying. This is *frustrating*. I have sent several private
communications to members of this list expressing sympathy for what I
view as the unfounded accusations they have been enduring. This is not
right nor is it professional nor is it just. The growing "us against them"
tenor of this list is inappropriate and nonproductive. I agree with
you: Please, list, let's stop this emotionalism now. It serves no useful
purpose. I can't understand why everyone can't see that it is very
important for all issues to be rationally explored within complex topics if
we are to arrive at "the best" consensus position. Certainly, I personally
believe that a consensus is still a ways off so that these explorations
are most justified. In any case, I view a "contrary" opinion as an
opportunity to enhance or shore up weaknesses in my approach. Without
them we are likely to fall into any number of pitfalls. Thus, "contray"
opinions are invaluable if they are politely and technically stated. Thus,
in this area I fully agree with the sentiment which you have expressed
and whole-heartedly hope that your posting will have its desired affect.
However, because I am an "end user", I want to say that I perceive that
the IETF would much more adequately meet my community's needs if it
enhances those activities which foster integration of the TCP/IP family
of protocols with my installed base, including OSI. It is my personal
belief that in the past the IETF did not always have the end users best
interests in mind when "not invented here" and non-integratable solutions
were chosen for various technologies. I view this unfortunate past to
be gradually changing and cite the recent formation of the SNANAU and
TN3270E working groups as concrete examples of the type of integration
activities which I perceive that we end users need. I also hope that
vendors of TCP/IP products will begin to deploy application layer products
using "standard Application Programming Interfaces" to permit
cross-protocol-family integrations/migrations of application-layer
technologies. More to the point, I also greatly value the liaison
activities of ISOC with the ITU and ISO as being extremely significant
for large end users. Really, these liaison activities are one of the most
encouraging/hopeful aspects of our current environment from my perspective.
Thus, while I sympathize with the frustration of "enduring this sort of
thing as long as we are trying to integrate the ISO and TCP/IP communities",
I, for one, believe that this integration is of the upmost importance.
While I recognize the emotional (and technical) reactions of the strong
"OSI-is-the-enemy" camp within our community -- and their emotional (and
technical) antagonists -- I nevertheless believe that both sides have
valuable insights to contribute. That is, I WANT integration of TCP/IP
with OSI. That is something which I value. However, the solution must
be such that the rough-consensus of our community can live with it and
endorse it. This means that we must listen closely to the anti-OSI
people if we are to ever achieve an acceptable integration approach simply
because no adequate solution is likely to be found without their help.
Who says that "the best" answer to the integration of TCP/IP with OSI has
yet been identified? Who says that the current solutions/alternatives
can't be modified to become acceptable? We won't know the best answers
to these (or any other) questions without open and free dialog. However,
unless we become civil and considerate with each other we may never see
the benign compromises lieing just before our noses. We *REALLY NEED* each
other. Thus, I urge that integration be pursued. However, it can only
succeed with civility, kindness, and *listening* to what others have to say.
Thank you, Noel, for being a force for reason in this needlessly
emotional environment. I hope that the entire community will support
you in this matter.
Sincerely yours,
--Eric Fleischman
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10637;
3 Aug 93 15:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10629;
3 Aug 93 15:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14288;
3 Aug 93 15:31 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10619;
3 Aug 93 15:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10559;
3 Aug 93 15:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14202;
3 Aug 93 15:29 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10547;
3 Aug 93 15:29 EDT
To: Eva Kuiper <eva at hpindda.cup.hp.com>
cc: bsimpson at morningstar.com, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-reply-to: Your message of "Tue, 03 Aug 93 11:57:07 PDT."
<9308031857.AA02778 at hpindda.cup.hp.com>
Date: Tue, 03 Aug 93 15:29:06 -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: <9308031529.aa10547 at IETF.CNRI.Reston.VA.US>
Eva,
just one remark about the origins of IP. The Internet was
developed by ARPA. Your note sort of makes it sound as if
Internet was hanging around somewhere and snatched IP from
ARPA. The ARPA project began in 1973 and developed the protocols
largely during the 1973-1978 period, then a period of
consolidation, extensive implementation on a variety of
hardware and software platforms until they were made standard
and required in 1982/3 by ARPA and the Defense Communications
Agency.
vint
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10733;
3 Aug 93 15:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10724;
3 Aug 93 15:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14372;
3 Aug 93 15:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10710;
3 Aug 93 15:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10685;
3 Aug 93 15:33 EDT
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa14347;
3 Aug 93 15:33 EDT
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <13420>; Tue, 3 Aug 1993 12:33:40 PDT
Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 3 Aug 1993 12:33:37 -0700
To: ietf at CNRI.Reston.VA.US
Cc: deering at parc.xerox.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Date: Tue, 3 Aug 1993 12:33:35 PDT
X-Orig-Sender: Steve Deering <deering at parc.xerox.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Deering <deering at parc.xerox.com>
Message-Id: <93Aug3.123337pdt.12171 at skylark.parc.xerox.com>
In Amsterdam, the chairs of the TUBA group were the only ones, of all the
IPng chairs, to say they would *not* shut down their working group if their
proposal were not adopted by the IETF as IPng. The reason given was that
there is a constituency for TUBA, independent of the choice of IPng.
Now, some advocates of TUBA are making the same argument in support of
publishing the TUBA spec as a standards-track RFC, independent of the IPng
selection process. I'd like to challenge the rationale for this alleged
constituency.
If people want to run TCP/UDP-based applications, they can do so over IP.
If, for some (presumably political) reason, some of those people have an
infrastructure that can only carry CLNP, they can encapsulate IP inside of
CLNP for conveyence across the CLNP cloud. (Embedding IP addresses inside of
NSAP addresses would enable that to be accomplished without all the manual
configuration typically involved in such tunneling.) That would be far
better than the TUBA approach, because it would allow the TCP/UDP
applications on the CLNP-attached hosts to communicate with peers anywhere
in the IP Internet (by placing conventional IP routers between the CLNP
cloud and the rest of the IP Internet), rather than being limited to
communicating only with peers in the same CLNP cloud. The TUBA approach
creates a community of machines running TCP/UDP applications that cannot
interoperate the existing TCP/UDP machines.
Now of course the IPng process is working towards replacing IP with a new
internet protocol, and that protocol may well turn out to be CLNP. It is
*only* in that context that TUBA makes sense, in my opinion. I believe it
is vital for the continued growth of the global Internet that all TCP/UDP
applications run over a common internetwork layer, and if that layer turns
out not to be CLNP, we do *not* want to promulgate a standard for running
TCP/UDP over CLNP. What we *do* want to do, if CLNP is not adopted as IPng,
is work to achieve whatever international recognition is required to make
IPng politically acceptable everywhere.
I suppose it comes down to whether or not you believe our goal should be
a single, ubiquitous internet protocol. Some people think that a "multi-
protocol Internet" is a Good Thing. I consider it a Necessary Evil, a stage
we have to go through in our evolution towards a single internet protocol.
Having multiple, worldwide, public, non-interoperable Internets is as
undesirable as multiple, worldwide, public, non-interoperable phone systems.
The chairs of the groups other than TUBA have, in essence, said that it is
more important that there be One Internet Protocol than that their own
particular proposal be that one. The TUBA folks apparently disagree.
(Maybe this should not be surprising, given the acceptance by the OSI
world of both CONS and CLNP.) To decide whether or not to publish the
TUBA spec independent of its selection as IPng, I think the IETF has to
answer the larger question: is our long-term goal to build one Internet or
multiple, non-interoperable Internets?
Steve
p.s. If you wish to take exception to this posting, please do so based
on what I have written here, not based on whatever motives you might
imagine me to have.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11333;
3 Aug 93 15:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15187;
3 Aug 93 15:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11316;
3 Aug 93 15:55 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11187;
3 Aug 93 15:53 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: tuba at lanl.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-tuba-sysids-02.txt
Date: Tue, 03 Aug 93 15:53:42 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308031553.aa11187 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 TCP/UDP over CLNP-addressed
Networks Working Group of the IETF.
Title : Assignment of System Identifiers for TUBA/CLNP Hosts
Author(s) : D. Piscitello
Filename : draft-ietf-tuba-sysids-02.txt
Pages : 8
This document describes conventions whereby the system identifier portion
of an RFC1237 style NSAP address may be guaranteed uniqueness within a
routing domain for the purpose of autoconfiguration in TUBA/CLNP internets.
The mechanism is extensible and can provide a basis for assigning system
identifiers in a globally unique fashion.
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-tuba-sysids-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-tuba-sysids-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-tuba-sysids-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tuba-sysids-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 aa11371;
3 Aug 93 15:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15217;
3 Aug 93 15:56 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11350;
3 Aug 93 15:56 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11231;
3 Aug 93 15:54 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-piscitello-ftp-bigports-02.txt
Date: Tue, 03 Aug 93 15:54:30 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308031554.aa11231 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : FTP Operation Over Big Address Records (FOOBAR)
Author(s) : D. Piscitello
Filename : draft-piscitello-ftp-bigports-02.txt
Pages : 5
This paper describes a convention for specifying longer addresses in the
PORT command.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-piscitello-ftp-bigports-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-piscitello-ftp-bigports-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-piscitello-ftp-bigports-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-piscitello-ftp-bigports-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 aa11474;
3 Aug 93 15:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11466;
3 Aug 93 15:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15292;
3 Aug 93 15:57 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11456;
3 Aug 93 15:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11360;
3 Aug 93 15:56 EDT
Received: from eagle.nersc.gov by CNRI.Reston.VA.US id aa15216;
3 Aug 93 15:56 EDT
Date: Tue, 3 Aug 1993 12:24:29 -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: <930803122429.439 at EAGLE.ES.NET>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: ietf at CNRI.Reston.VA.US
X-Vmsmail-To: smtp%"ietf at cnri.reston.va.us"
Let me respond to a couple of points and then get back to work,
Noel>The question should be "is this reasonable on its own merits".
This is exactly the point I have been trying to make. Again:
"The TUBA effort should be allowed to progress on the basis that it has met
the established requirements that any proposal needs to."
Noel>Would you care to share with us what led you to the apparent
Noel>conclusion that some hold was being contemplated?
An out of band rumor (granted unsubstantiated) that members of the
IESG are trying to kill the TUBA effort.
Frank>So, this set of protocols defines what we are and what we are trying to do.
Frank>It is the essence of our being, our soul if you will ....
I understand there are strong feelings here, and my intent in this whole thread
has been to point out that these feelings are influencing what should be a
discussion on the technical progress of TUBA. If in the process of that I have
insulted anyone I apologize.
Unlike your position, I consider IP to be a tool to accomplish a task. I also
consider DECnet, X.25, Appletalk, and CLNP to be tools to accomplish tasks.
Much as IPv4 uses underlying tools (Ethernet, FDDI, DS1, DS3, ATM, SMDS, Frame
Relay, X.25....) TCP uses an underlying tool. Which tool is a function of the
task at hand.
Defining the interface between tools is what the IETF does well. A group has
defined an interface between the TCP tool and the CLNP tool and is asking to
progress that effort. What needs to happen here is to drop the IPng issue
and progress TUBA as a defined interface between TCP and CLNP. CLNP is not
perfect, but several implementations exist for hosts and routers. The missing
link is the 'standard defined interface' for TCP based applications to make
use of it. We have the 'defined' part of that, we are just having trouble
getting the 'standard' part. The issue here is that vendors refuse (rightly so)
to make any changes that are not 'standard'.
You have hit the heart of the matter, the IETF does need to understand where
its soul is. Is it a protocol, a layer, or the ability communicate between
endpoints? My guess is that a poll of the IETF would show N^3 answers because
it is a context sensitive issue where background is a factor.
Tony
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11718;
3 Aug 93 16:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11709;
3 Aug 93 16:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15685;
3 Aug 93 16:10 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11695;
3 Aug 93 16:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11651;
3 Aug 93 16:08 EDT
Received: from newsun.Novell.COM by CNRI.Reston.VA.US id aa15604;
3 Aug 93 16:08 EDT
Received: from va.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1)
id AA01765; Tue, 3 Aug 93 13:08:51 PDT
Received: by va.SJF.Novell.COM (4.1/SMI-4.1)
id AA17097; Tue, 3 Aug 93 13:06:38 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Neal Castagnoli <Neal_Castagnoli at novell.com>
Message-Id: <9308032006.AA17097 at va.SJF.Novell.COM>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Date: Tue, 3 Aug 93 13:06:38 PDT
Cc: 0003858921 at mcimail.com, dkatz at cisco.com, ietf at CNRI.Reston.VA.US,
jnc at ginger.lcs.mit.edu
In-Reply-To: <9308031749.AA21136 at ginger.lcs.mit.edu>; from "Noel Chiappa" at Aug 3, 93 1:49 pm
X-Mailer: Elm [version 2.1 alpha-test]
>
> > In some cases a single filter insures that traffic for one plant routes
> > directly to corporate instead of through another plant... This single
> > filter is controlling a few hundred device's traffic. If we have to use
> > a few hundred filters instead....
>
> The one pertinent architectural issue is that CLNP addresses do not map to
> individual media wires like IP (in my opinion, a feature, not a bug), so
> the effective granularity of filters is per IS-IS area (or per host).
>
> One way to get IP-like behaviour is to follow an IP-like model and give each
> wire a separate level 1 area identification. Of course, this sort of voids
> some of the advantages of the NSAP idea, which allows hosts to move among the
> wires of a level 1 area without changing their address. However, to the extent
> that an administrative entity which you wish to make a single policy statement
> about has a number of media wires, each currently with a separate IP subnet
> number, you could actually *reduce* the number of access control terms (i.e.
> filters) by making it a single level 1 area.
I would assume that having multiple administrative entities on the same box is
quite common (certainly that is the case in our network). However,
to my knowledge no router manufactorer has implemented this capability for
CLNP.
As you have pointed out, there is nothing in the IS - IS model that prevents
multiple administrative entity per box, because you can run multiple
instantiations of the routing protocol on a single box. But, until
someone implements this solution, you can only theorize about the affects
of multiple administrative entities on one box.
So, while theoretically you can reduce the number of filters, in practice you
may find that you can't. Being able to reduce filters is predicated on the
creation of systems that don't exist, and so it is difficult to say how such
a system would actually behave, and perform, and whether such a system is
useable (from an administrative point of view).
(Is this pertinant, even. I would assume that the routing protocols and
network layer interaction with higher layer protocols would be of importance
in this discussion.)
--Neal Castagnoli
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13305;
3 Aug 93 16:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13298;
3 Aug 93 16:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17323;
3 Aug 93 16:59 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13285;
3 Aug 93 16:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13188;
3 Aug 93 16:57 EDT
Received: from xap.xyplex.com by CNRI.Reston.VA.US id aa17287;
3 Aug 93 16:57 EDT
Received: by xap.xyplex.com id <AA19104 at xap.xyplex.com>; Tue, 3 Aug 93 18:57:16 -0500
Date: Tue, 3 Aug 93 18:57:16 -0500
Message-Id: <9308032357.AA19104 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: Steve Deering's message of Tue, 3 Aug 1993 12:33:35 PDT <93Aug3.123337pdt.12171 at skylark.parc.xerox.com>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
>p.s. If you wish to take exception to this posting, please do so based
> on what I have written here, not based on whatever motives you might
> imagine me to have.
I started this response to another message (Eric's), then gave up. Steve
pushed me.
Impugning motives is at best of no effect and at worst damaging. If I'm
manipulating you, I know that and am highly unlikely to quit because you
accuse me. I'm more likely to get better at manipulating. If I'm not
manipulating you, I'm likely to decide you're a silly person who doesn't know
what's going on, and I therefore shouldn't listen to you. Of course that's if
I don't get mad and be a silly person, too, thus wasting everyone's time.
I know the acid pen stuff is much more fun to write, but let's keep it
technical. I propose that input impugning motives be dismissed out of hand.
Just say, "delete."
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13561;
3 Aug 93 17:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13554;
3 Aug 93 17:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17648;
3 Aug 93 17:08 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13540;
3 Aug 93 17:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13484;
3 Aug 93 17:07 EDT
Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa17610;
3 Aug 93 17:07 EDT
Received: by ftp.com
id AA18297; Tue, 3 Aug 93 17:07:52 -0400
Date: Tue, 3 Aug 93 17:07:52 -0400
Message-Id: <9308032107.AA18297 at ftp.com>
To: deering at parc.xerox.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Frank Kastenholz <kasten at ftp.com>
Reply-To: kasten at ftp.com
Cc: ietf at CNRI.Reston.VA.US
> I believe it
> is vital for the continued growth of the global Internet that all TCP/UDP
> applications run over a common internetwork layer, and if that layer turns
> out not to be CLNP, we do *not* want to promulgate a standard for running
> TCP/UDP over CLNP. What we *do* want to do, if CLNP is not adopted as IPng,
> is work to achieve whatever international recognition is required to make
> IPng politically acceptable everywhere.
Steve, in the interests of perhaps trying to put out a fire before it
gets too big, is the general case of what you are saying really something like:
"we do *not* want to promulgate a standard for running TCP/UDP over
anything but IP, IPv4 today, IPng when that gets finalized."
That is, your statement applies to N-1 of the IPng proposals, where the
N'th proposal is the one that gets selected as IP.
I would hate for someone to misinterpret a personal statement of broad policy
and general applicability as something that is aimed particularly at
their own preferred protocol and then get all bent out of shape and
claim that you are, for example, narrow minded and a member of the
secret consipracy (typo intentional) to prevent their perferred protocol
from taking over the world -- or some such silliness :-)
--
Frank Kastenholz
FTP Software
2 High Street
North Andover, Mass. USA 01845
(508)685-4000
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14325;
3 Aug 93 17:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14318;
3 Aug 93 17:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18975;
3 Aug 93 17:44 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14306;
3 Aug 93 17:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14272;
3 Aug 93 17:43 EDT
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa18941;
3 Aug 93 17:43 EDT
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <13447>; Tue, 3 Aug 1993 14:43:32 PDT
Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 3 Aug 1993 14:43:22 -0700
To: ietf at CNRI.Reston.VA.US
Cc: deering at parc.xerox.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Date: Tue, 3 Aug 1993 14:43:08 PDT
X-Orig-Sender: Steve Deering <deering at parc.xerox.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Deering <deering at parc.xerox.com>
Message-Id: <93Aug3.144322pdt.12171 at skylark.parc.xerox.com>
Someone kindly pointed out that the following statement in my last message
might be misinterpreted to apply *only* to CLNP:
> ...I believe it
> is vital for the continued growth of the global Internet that all TCP/UDP
> applications run over a common internetwork layer, and if that layer turns
> out not to be CLNP, we do *not* want to promulgate a standard for running
> TCP/UDP over CLNP.
What I meant is that, in my opinion, it would be inadvisable for the IETF
to promulgate a standard for running TCP/UDP over *any* internet protocol
other than IP, that is, IPv4 at present and IPng in the future.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15537;
3 Aug 93 19:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15530;
3 Aug 93 19:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21147;
3 Aug 93 19:21 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15520;
3 Aug 93 19:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15495;
3 Aug 93 19:19 EDT
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa21104;
3 Aug 93 19:19 EDT
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <13491>; Tue, 3 Aug 1993 16:14:08 PDT
Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 3 Aug 1993 16:13:58 -0700
To: Tony Hain <ALH at eagle.es.net>
Cc: ietf at CNRI.Reston.VA.US, deering at parc.xerox.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-reply-to: Your message of "Tue, 03 Aug 93 12:24:29 PDT."
<930803122429.439 at EAGLE.ES.NET>
Date: Tue, 3 Aug 1993 16:13:48 PDT
X-Orig-Sender: Steve Deering <deering at parc.xerox.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Deering <deering at parc.xerox.com>
Message-Id: <93Aug3.161358pdt.12171 at skylark.parc.xerox.com>
> Defining the interface between tools is what the IETF does well. A group has
> defined an interface between the TCP tool and the CLNP tool and is asking to
> progress that effort.
If the IETF is to retain its reputation for designing good interfaces, it
should not standardize TUBA *unless* it first picks CLNP as IPng. *If* CLNP
is not IPng, TUBA is a technically inferior way of supporting TCP/UDP-based
applications on a CLNP-capable host. There are at least two better
approaches:
(1) run an IP[ng] stack in parallel with the CLNP stack, and run
TCP/UDP over that IP[ng] stack.
(2) run TCP/UDP over IP[ng] over CLNP.
Both of those approaches have the advantage of enabling the TCP/UDP apps to
communicate transparently with any other TCP/UDP host in the Internet
(subject to firewalls, etc.), not just those running CLNP.
If you think that the IETF should standardize TCP/UDP-directly-over-CLNP,
should it also standardize TCP/UDP-directly-over-AppleTalk and
TCP/UDP-directly-over-IPX and TCP/UDP-directly-over-Pup and so on? Don't
you see that that leads to a world in which Macintoshes can FTP files only
from machines running AppleTalk, PCs can open X Windows only to machines
running IPX, and government computers can participate in packet
videoconferences only with machines running CLNP?
*Only* if CLNP is chosen as IPng does it make sense to run TCP/UDP over
CLNP. I am certainly willing to accept such a choice, if the IETF makes
it in a fair and open manner. In that case, we (the Internet community)
will strive to get CLNP installed on all the Unix, Macintosh, DOS,
Windows, NT, etc. hosts in the Internet, so that we retain the ubiquitous
connectivity among heterogeneous machines that is the great success of
the (IP) Internet.
(You may globally replace "CLNP" with "SIP", "Pip", "TP/IX" or any other
internet protocol name, in this message.)
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15628;
3 Aug 93 19:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15621;
3 Aug 93 19:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21360;
3 Aug 93 19:30 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15611;
3 Aug 93 19:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15576;
3 Aug 93 19:29 EDT
Received: from large.cisco.com by CNRI.Reston.VA.US id aa21275;
3 Aug 93 19:29 EDT
Received: by large.cisco.com id AA26207
(5.67a/IDA-1.5 for ietf at cnri.reston.va.us); Tue, 3 Aug 1993 16:29:58 -0700
Date: Tue, 3 Aug 1993 16:29:58 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199308032329.AA26207 at large.cisco.com>
To: Neal_Castagnoli at novell.com
Cc: ietf at CNRI.Reston.VA.US
Subject: Last Call: Use of ISO CLNP in TUBA
So, while theoretically you can reduce the number of filters, in practice you
may find that you can't. Being able to reduce filters is predicated on the
creation of systems that don't exist, and so it is difficult to say how such
a system would actually behave, and perform, and whether such a system is
useable (from an administrative point of view).
I guess I don't share your pessimism. Certainly the ability to
support multiple areas has been demonstrated (albeit in OSPF), the
ability to provide arbitrary filtering on NSAP addresses in various
places has been implemented, and methods for assigning addresses in
order to perform clustering has been studied extensively and are
being deployed today.
The most difficult aspect of this seems to be doing a good job of
designing the network, but customers building a complex network know
enough to get expert assistance.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18022;
3 Aug 93 22:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18015;
3 Aug 93 22:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25704;
3 Aug 93 22:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18004;
3 Aug 93 22:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17977;
3 Aug 93 22:32 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa25661;
3 Aug 93 22:32 EDT
Received: by ginger.lcs.mit.edu
id AA23406; Tue, 3 Aug 93 22:33:13 -0400
Date: Tue, 3 Aug 93 22:33:13 -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: <9308040233.AA23406 at ginger.lcs.mit.edu>
To: ericf at atc.boeing.com, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: jnc at ginger.lcs.mit.edu
the IETF would much more adequately meet my community's needs if it
enhances those activities which foster integration of the TCP/IP family of
protocols with my installed base, including OSI ... in the past the IETF
did not always have the end users best interests in mind when "not
invented here" and non-integratable solutions were chosen for various
technologies. ... while I sympathize with the frustration of "enduring
this sort of thing as long as we are trying to integrate the ISO and
TCP/IP communities", I, for one, believe that this integration is of the
upmost importance. ... We *REALLY NEED* each other. Thus, I urge that
integration be pursued.
I've usually felt, for a while now, that this is true. We all share the common
goal of producing a ubiquitous internetwork that has certain properties such
as robustness, elegance, flexibility, etc. However, it has been a long, and
occasionally very rocky, road, and occasionally (especially while getting
bounced over the rocks :-) I wonder whether a rational summing up of the pros
and cons would still produce the same result.
In short, is the time, energy and aggravation which has been expended on this
integration worth the benefit to the users, or, in a cold, rational analysis,
*would it have been a shorter and less painful path to a working, integrated
internet* if we explicitly take the position that integration of the two was
more trouble (politically and technically) than it was worth, and move
decisively to implement that decision by explicitly forgoing integration of
the two protocol stacks, and opting for a simple conversion.
I'm not going to try and answer that definitively, but it's certainly true
that more energy and time has been used by this than by any other single issue
that has come before the IETF and predecessors in the 16 years I've been
around. These people issues, which I reckon are the chief cause of the
problems we see here, are as tough as any of the technical challenges, and
maybe tougher.
In light of these points, it needs to be clear to everybody that every time we
have one of these passages of suspicion and ill-feeling, the con side of the
summing-up ledger above just got a little larger. I'm obviously personally
tired enough of it that I'm seriously considering whether we're near the
break-even point. Obviously, different people do these sums differently. The
users see the costs to them, but the people trying to produce the designs see
a different picture. We need to see and understand your problems, but you
need to consider ours too.
A tremendous amount of time and energy has gone down the tubes over the years
in the human sideshows which accompanied CMOT/SNMP, IS-IS/OSPF, etc, etc,
etc. Was this in fact the most efficient path to the future, or could the
researcher/designer/implementor time that was consumed there have been better
spent elsewhere, to produce a (by now) better Internet? It's not at all clear
to me what the answer is. It's this bitter knowledge of the cost, in lost
opportunities, which makes me so upset. I sat for a while last night, trying
to decide if that message was appropriate to send, and finally decided to go
ahead, given what we are losing. If it went too far for some, I'm sorry, but I
wanted to really wake everyone up to the gravity of things.
In sum, I think a number of people, and not all radicals by any means, and
from both sides, are really reaching the end of their ropes on this incredible
waste of time and energy, *especially while so many hard problems lie before
us*, and everyone needs to realize that we can't go through many more of these
before, all the eloquent pleas of Eric et al notwithstanding, people simply
conclude that faster overall progress toward the ultimate goal will be made
without this distraction. Such a decision might well be wrong, but it will not
be utterly irrational. Everyone must be careful if we are to prevent this.
However, it can only succeed with civility, kindness, and *listening* to
what others have to say.
This is quite true. About the only good thing I can say about the blowups is
that, to the degree that we get these things out in the open, and straightened
out, it's better to have them, and get them out of the way, than have people
muttering darkly in corners to their supposed allies, and co-conspirators.
How I wish there were a less painful way! That's life, I suppose...
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20160;
3 Aug 93 23:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20153;
3 Aug 93 23:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26296;
3 Aug 93 23:08 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20142;
3 Aug 93 23:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20119;
3 Aug 93 23:06 EDT
Received: from nic.near.net by CNRI.Reston.VA.US id aa26281; 3 Aug 93 23:06 EDT
Received: from nic.near.net by nic.near.net id aa23544; 3 Aug 93 23:07 EDT
To: Steve Deering <deering at parc.xerox.com>
cc: Tony Hain <ALH at eagle.es.net>, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-reply-to: Your message of Tue, 03 Aug 1993 16:13:48 -0700.
<93Aug3.161358pdt.12171 at skylark.parc.xerox.com>
Date: Tue, 03 Aug 1993 23:07:11 -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: <9308032306.aa26281 at CNRI.Reston.VA.US>
Upon seeing Noel's last message (about effort potentially wasted
through the pursuit of IP/CLNP integration), I considered whether
this message was still of value. I believe it discusses a larger
issue (that if, the role of the IETF) and is not, per se, about
CLNP or TUBA.
] From: Steve Deering <deering at parc.xerox.com>
] Subject: Re: Last Call: Use of ISO CLNP in TUBA
] Date: Tue, 3 Aug 1993 16:13:48 PDT
]
] If the IETF is to retain its reputation for designing good interfaces, it
] should not standardize TUBA *unless* it first picks CLNP as IPng. *If* CLNP
] is not IPng, TUBA is a technically inferior way of supporting TCP/UDP-based
] applications on a CLNP-capable host.
Preface: I was unable to be at Amsterdam and therefore have little background
into the promotion of TUBA as a independent technology in addition to
its role as an IPng candidate. Presumably, some folks have a need for
TCP/UDP applications on their CLNP nets and feel TUBA is an option.
I believe in a fully-connected Internet. I know that Internet service
providers have gone to great lengths insuring full connectivity where
ever possible. I'd like to see the Internet remain "fully-connected",
and can only assume that fellow network providers feel likewise.
On the other hand, I don't think one can (or even should) legislate a
a system of beliefs. There are an amazing number of ways for network
providers to balkanize the Internet, and while the IETF is wonderful
organization, it is (opinion follows) NOT the IETF's role to specify
the services that will or will not be offered. It is the IETF's role
to promote technical excellence in networking through the development
of standards.
If TUBA (as a technology) meets the IETF requirements for standardization,
it should be allowed on the standards track. Some folks will claim that
it does meet these requirements, some will claim it doesn't, but that is
a question that IESG or IAB can decide.
] If you think that the IETF should standardize TCP/UDP-directly-over-CLNP,
] should it also standardize TCP/UDP-directly-over-AppleTalk and
] TCP/UDP-directly-over-IPX and TCP/UDP-directly-over-Pup and so on? Don't
] you see that that leads to a world in which Macintoshes can FTP files only
] from machines running AppleTalk, PCs can open X Windows only to machines
] running IPX, and government computers can participate in packet
] videoconferences only with machines running CLNP?
A great question. Who insures we remain one-global-connected-Internet?
My guess would be "the same folks who insure that today", i.e. the users
who want to buy access to a fully-connected Internet.
Nothing prevents one from creating a DECNETp5 internet or an appletalkp2
internet other than lack of desirable applications and services. TUBA is
one way for CLNP to suddenly support more applications. Would anyone buy
a TUBA service? I don't know, but I do question whether it's the IETF's
function to prohibit such a service by fiat. Shall we follow the
"TCP/UDP services may only be run over IP[x]" announcement with one that
states "PEM messages may only be transferred over SMTP" and see if we can
kill X.400?
/John
p.s. As always, apologies for length...
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22161;
3 Aug 93 23:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22154;
3 Aug 93 23:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26911;
3 Aug 93 23:44 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22138;
3 Aug 93 23:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21385;
3 Aug 93 23:41 EDT
Received: from qdeck.com by CNRI.Reston.VA.US id aa26866; 3 Aug 93 23:41 EDT
Received: from angel.qdeck.com by rockall.qdeck.com (4.1/SMI-4.1)
id AA21778; Tue, 3 Aug 93 20:40:25 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: jcurran at nic.near.net, deering at parc.xerox.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: ALH at eagle.es.net, ietf at CNRI.Reston.VA.US
X-Mailer: ScoMail 1.0
Date: Tue, 3 Aug 1993 20:35:33 -0700 (PDT)
Message-Id: <9308032035.aa16179 at angel.qdeck.com>
> Nothing prevents one from creating a DECNETp5 internet or an appletalkp2
> internet other than lack of desirable applications and services. TUBA is
> one way for CLNP to suddenly support more applications. Would anyone buy
> a TUBA service? I don't know, but I do question whether it's the IETF's
> function to prohibit such a service by fiat.
The IETF is fundamentally incapable of prohibiting such a service. What,
the ISOC is going to hire hit squads to go after people who put TCP on top
of IPX?
HOWEVER, the IETF is certainly within its rights to refuse to endorse such
a service. If some other organization thinks that TCP-on-NETBIOS is important,
they can specify it, and anybody who wants to can implement and run it.
But it won't be an Internet Standard. If you define _The Internet_ as the
globally-connected network currently based on IP and in the future based on
IPng, it seems only proper that Internet Standards apply to _The Internet_,
and TCP-over-Ethernet (who needs the IP layer anyway? :-) doesn't.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23704;
4 Aug 93 0:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23694;
4 Aug 93 0:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27364;
4 Aug 93 0:01 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23684;
4 Aug 93 0:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23615;
3 Aug 93 23:59 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa27254;
3 Aug 93 23:59 EDT
Received: by ginger.lcs.mit.edu
id AA23558; Tue, 3 Aug 93 23:59:41 -0400
Date: Tue, 3 Aug 93 23:59:41 -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: <9308040359.AA23558 at ginger.lcs.mit.edu>
To: deering at parc.xerox.com, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: jnc at ginger.lcs.mit.edu
I believe it is vital for the continued growth of the global Internet that
all TCP/UDP applications run over a common internetwork layer, and if that
layer turns out not to be CLNP, we do *not* want to promulgate a standard
for running TCP/UDP over CLNP. ... I suppose it comes down to whether or
not you believe our goal should be a single, ubiquitous internet protocol.
Some people think that a "multi- protocol Internet" is a Good Thing. I
consider it a Necessary Evil, a stage we have to go through in our
evolution towards a single internet protocol. Having multiple, worldwide,
public, non-interoperable Internets is .. undesirable ... To decide
whether or not to publish the TUBA spec independent of its selection as
IPng, I think the IETF has to answer the larger question: is our long-term
goal to build one Internet or multiple, non-interoperable Internets?
<Sigh, I wish this whole IPng decision topic, in all its forms and variants,
would please Go Away for a while!>
I've been musing about this for a while. I think most everyone probably shares
your assessment that a multi-protocol Internet is a necessary evil, a stage in
development toward a common system, and I think we also all pretty much share
the goal of a single Internet. I don't think that's the question.
The question is, what's the right way to handle this issue of how to choose
between multiple competing standards to serve some particular purpose. How do
we make the decision? Should we ever endorse more than one (and let the market
or something outside decide), or should we attempt to make a decision inside
the IETF? There are arguments on both sides, and we've faced this question
before in the IETF, with other places where there were multiple protocols
designed for a single purpose.
One side of the argument says that to have multiple standards will confuse
users and vendors, and cause a delay in getting everyone settled on a
replacement and getting it available. There is also the point you raise, that
it will tend to lengthen the time in which there are two independant,
non-interacting internetworks. (I don't think the choice is quite as dire as
you frame it, i.e. one or several. Even if we did put up several different
internets, over time the advantages of a single common system would drive out
N-1 of them. However, there could still be an extended period during which the
dichotomy causes a certain amount of pain and hassle.)
There is a lot to these points. Obviously, the potential costs are a lot
steeper here than with other instances of several potential protocol solutions
for one purpose, since we aren't talking about an infrequently used
application, or something which will impact only routers, but the basic core
of everything we do. However, we've answered the other way previously, for
good reasons, and when I look at the other side here, I think that perhaps
the answer is still the same.
For one thing, the IETF tradition has been that we don't decide on designs by
discussion; we actually try things, and decide based on experience. It's kind
of hard to do this without doing some deployment. Usually, we advance all the
contendors to PS, and let things simmer for a while, until it's obvious which
one to promote further. Competition improves the breed. I'm worried that once
we depart this path, we'll have lost one of the things that helped the IETF do
well. For another, this will leave us to make the decision on the protocol of
choice (for IPng, in this case) by some other means inside the IETF. I'd have
through the one thing which would be crystal clear after all these years is
that arguing back and forth over which one to pick simply generates a lot of
hostility, and not a useful decision. So, that's another giant trap. In
addition, I like the tradition (oh, how it has worked for me many times :-)
that someone who strongly believe that X is the Right Thing technically can go
on pushing it, no matter how little support he may have (within some broad
limits of course, as certain individual have found :-). So, there's another
reason to be leery of shutting things down.
Finally, and most importantly, the IETF simply does not have a police force.
If we all decide to take protocol X out and shoot it, we have no mechanism to
enforce that decision. The people who did the work can simply leave, and
pursue pushing the protocol outside the IETF, albeit with no guarantees of
getting very far. At least inside the IETF, we have rules which guarantee the
availability of specs openly, a forum of competent engineers to critique them
openly, and a tradition (however much honoured in the breach) of picking the
technically superior design. Better to keep people inside, and honor bound to
at least pretend to play by the rules (i.e. we can all beat them up in email
if they go off the rails :-) than drive them out, to no useful end.
In sum, much as it's a process open to abuse (and I'll talk about how in a
sec), I think going forward with deployment is the only thing to do. Is this
going to upset the vendors, and confuse the users? You bet. It's called a free
market, and while they are much disliked because of the obvious waste, and the
way that they trash the unaware and unsophisticated, in the long run they
aren't so bad. Like Churchill said about democracy, "it's the worst form of
government, except all the others". I personally don't believe the market will
pick up on *any* of them, at which point we'll *all* have to go back to the
drawing board, but we'll see.
Of course, it's open to abuse. Anything is open to abuse, especially by people
with brains (as most IETF people have in relative abundance) and ill-will, or
no sense that the common good will protect them too in time. One way to abuse
the system is to keep pushing something when it's obvious that it is history;
to do so just lengthens the time before we can stop confusing the poor users,
etc. My brain is running out of computes, but there are others. I hope the
people who are in the IETF will refrain from abusing the system, and there are
people in all camps who I am thinking of when I say this. You know who you
are.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23736;
4 Aug 93 0:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23726;
4 Aug 93 0:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27486;
4 Aug 93 0:04 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23716;
4 Aug 93 0:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22148;
3 Aug 93 23:44 EDT
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa26906;
3 Aug 93 23:44 EDT
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <13540>; Tue, 3 Aug 1993 20:44:26 PDT
Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 3 Aug 1993 20:44:18 -0700
To: John Curran <jcurran at nic.near.net>
Cc: ietf at CNRI.Reston.VA.US, deering at parc.xerox.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-reply-to: Your message of "Tue, 03 Aug 93 20:07:11 PDT."
<93Aug3.200719pdt.13510 at alpha.xerox.com>
Date: Tue, 3 Aug 1993 20:44:16 PDT
X-Orig-Sender: Steve Deering <deering at parc.xerox.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Deering <deering at parc.xerox.com>
Message-Id: <93Aug3.204418pdt.12171 at skylark.parc.xerox.com>
> ...Would anyone buy a TUBA service? I don't know, but I do question
> whether it's the IETF's function to prohibit such a service by fiat.
John,
The IETF does not have the power to prohibit a TUBA service, nor should it.
Anyone who wants to run TUBA is free to do so, regardless of the IETF's
approval. I am simply suggesting that the IETF would be harming its own
cause (that of Engineering The Internet) if it were to "bless" TUBA as
an Internet Standard, unless it were also to adopt CLNP as the future basis
of that Internet.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24563;
4 Aug 93 1:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24552;
4 Aug 93 1:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29544;
4 Aug 93 1:05 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24532;
4 Aug 93 1:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24503;
4 Aug 93 1:04 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa29496;
4 Aug 93 1:04 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA26975; Tue, 3 Aug 93 22:04:53 -0700
Message-Id: <9308040504.AA26975 at Mordor.Stanford.EDU>
To: ietf at CNRI.Reston.VA.US
Subject: TUBA w/out IPng (was: Re: Last Call: Use of ISO CLNP in TUBA)
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Tue, 03 Aug 93 20:44:16 -0700. <93Aug3.204418pdt.12171 at skylark.parc.xerox.com>
Date: Tue, 03 Aug 93 22:04:53 -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 IETF has generally gone in the direction of single standards for
solving a problem. There have been exceptions, but the
one-problem/one-solution approach is pretty consistently preferred. Up
until now, we've been luckly. When there were two or more contenders,
only one, finally, came to the party. The party has been defined as:
1. Willing body of worker bees to produce the spec,
2. A competent spec,
3. Production of running code from that spec, and
4. Willing body of end-users.
We've been lucky, in previous debates, because the losers have failed
on points 1, 2, or 3. IPng is having rather a more interesting time of
it.
TUBA was created as a direct result of the ROAD group. I.e., it was
created for IPng. Arguments that it be separated from that effort are
odd, indeed. But to the extent that it is being proposed seriously,
then it should formally step down from IPng contention and it should
formally ask to be considered only and completely on the usual merits
of an IETF standard.
To that end, let's ask how it is doing on the above list. In fact, it
seems to be doing pretty well. While one can argue that it might not
be sufficiently complete (I have no opinion on that, but am echoing
comments that I've heard from credible sources) the point that warrants
considerable discussion is point 4. (Well, I also think that Deering's
line of concern is quite strong and needs careful consideration.)
Just who are the intended users? What evidence is there that they a)
want, and b) need this technical solution?
Also, we have a lengthy history of doing standards that involve specs
from other bodies. IP-over-... embodies a large set, as does
SNMP-over... We have also had to deal with ...-over-PPP. So
TCP-over-CLNP might be within our purview. But perhaps it isn't.
Perhaps it is in the purview of the owners of CLNP.
(This point about CLNP ownership has irritated some folks. Sorry, but
we've spent quite a lot of energy trying to avoid stepping on the toes
of other standards bodies and we have no formal indication that we
should stop, now. So messing around with their specs scares me a bit.)
This leaves us with 3 questions I suggest we consider:
1. Is TUBA -- as an independent technical solution -- of
appropriate technical quality and operational benefit to
warrant IETF standardization?
2. Who is the end-user consituency for TUBA, independent of
IPng?
3. Is the IETF the right place to pursue such a standard?
Dave
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00614;
4 Aug 93 3:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00604;
4 Aug 93 3:03 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01661;
4 Aug 93 3:03 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00588;
4 Aug 93 3:03 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00529;
4 Aug 93 2:55 EDT
Received: from relay.hp.com by CNRI.Reston.VA.US id aa01514; 4 Aug 93 2:55 EDT
Received: from hpindda.cup.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA21547; Tue, 3 Aug 93 23:26:47 -0700
Received: by hpindda.cup.hp.com
(15.11/15.5+IOS 3.20+cup+OMrelay) id AA19394; Tue, 3 Aug 93 23:26:45 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: <9308040626.AA19394 at hpindda.cup.hp.com>
Subject: Re: TUBA w/out IPng (was: Re: Last Call: Use of ISO CLNP in TUBA)
To: dcrocker at mordor.stanford.edu
Date: Tue, 3 Aug 93 23:26:43 PDT
Cc: ietf at CNRI.Reston.VA.US, eva at hpindda.cup.hp.com
In-Reply-To: <9308040504.AA26975 at Mordor.Stanford.EDU>; from "Dave Crocker" at Aug 03, 93 10:04 pm
Mailer: Elm [revision: 64.9]
Dave,
> TUBA was created as a direct result of the ROAD group. I.e., it was
> created for IPng. Arguments that it be separated from that effort are
> odd, indeed. But to the extent that it is being proposed seriously,
> then it should formally step down from IPng contention and it should
> formally ask to be considered only and completely on the usual merits
> of an IETF standard.
I do not feel that there is any reason, either technical or
political, that TUBA be required to abstain from the IPng list
as a criterion for being advanced to proposed standard. These two
issues are totally and entirely unrelated. The two paths are orthogonal.
Does this mean that as each IPng contender reaches the stage when it
is ready to go to proposed standard it first has to remove itself
from the IPng list? This leads us to no candidates :-)
Considering that IP is only now reaching completion, just as it finds
itself needing to be replaced, it is unrealistic to require full
completion at this phase of any new contender.
Because TUBA already meets the criteria for proposed standard it
should be advanced at this point. It should not be required to drop off
the IPng list to achieve this status.
>
> 1. Is TUBA -- as an independent technical solution -- of
> appropriate technical quality and operational benefit to
> warrant IETF standardization?
Yes.
>
> 2. Who is the end-user consituency for TUBA, independent of
> IPng?
Anybody who is concerned about convergence of existing open protocols
in use today using a strategy which allows for a single network
protocol to be managed.
>
> 3. Is the IETF the right place to pursue such a standard?
Yes.
Eva
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00901;
4 Aug 93 4:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00891;
4 Aug 93 4:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02696;
4 Aug 93 4:05 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00878;
4 Aug 93 4:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00852;
4 Aug 93 4:03 EDT
Received: from bells.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa02667;
4 Aug 93 4:03 EDT
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.23868-0 at bells.cs.ucl.ac.uk>; Wed, 4 Aug 1993 09:03:25 +0100
To: Dave Crocker <dcrocker at mordor.stanford.edu>
cc: ietf at CNRI.Reston.VA.US, J.Crowcroft at cs.ucl.ac.uk
Subject: Re: TUBA w/out IPng (was: Re: Last Call: Use of ISO CLNP in TUBA)
In-reply-to: Your message of "Tue, 03 Aug 93 22:04:53 PDT." <9308040504.AA26975 at Mordor.Stanford.EDU>
Date: Wed, 04 Aug 93 09:03:10 +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: <9308040403.aa02667 at CNRI.Reston.VA.US>
> 1. Willing body of worker bees to produce the spec,
>
> 2. A competent spec,
>
> 3. Production of running code from that spec, and
>
> 4. Willing body of end-users.
>
>We've been lucky, in previous debates, because the losers have failed
>on points 1, 2, or 3. IPng is having rather a more interesting time of
>it.
>
>TUBA was created as a direct result of the ROAD group. I.e., it was
>created for IPng. Arguments that it be separated from that effort are
>odd, indeed. But to the extent that it is being proposed seriously,
>then it should formally step down from IPng contention and it should
>formally ask to be considered only and completely on the usual merits
>of an IETF standard.
>
To that end, let's ask how it is doing on the above list.
the more i lisaten to the TUBA debate, the more i am puzzled.
the argument is
TUBA< because CLNP, and CLNP because the rotuers all do CLNP.
However, the hosts don't except in CLNP nets. Now, in CLNP nets, the
hosts must be running other applications on TP4 or othter on CLNP (or
else what are the nets for:-)
If they are prepared to take all those hosts, and change them to run
altered stacks so TCP can run on CLNP, why not just run TCP on IP, and
enable the IP in the routers and run TCP on ip and not alter anything?
basically, I do not buy the arugment that there is a CLNP therefore
TUBA consituency - it makes no sense at all.
that is NOT to say that CLNP makes no sense as an IPng, just that the
constituency argument is void. (people who came fro mthe other way of
having an IP net and discovering that they could enable CLNP i ntheir
routers will tell you that there was no rush to go out and run
anything in end systems at all, not even in the UK where we have
already a) bitten the datagram bullet and b) got a national
NSAP allocation scheme)
jon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01910;
4 Aug 93 7:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01891;
4 Aug 93 7:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06239;
4 Aug 93 7:36 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01859;
4 Aug 93 7:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01819;
4 Aug 93 7:34 EDT
Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa06171;
4 Aug 93 7:34 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ad28021;
4 Aug 93 11:28 GMT
Date: Wed, 4 Aug 93 11:33 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Message-Id: <12930804113321/0003858921NA4EM at mcimail.com>
Steve Deering Said:
>I suppose it comes down to whether or not you believe our goal should be
>a single, ubiquitous internet protocol. Some people think that a "multi-
>protocol Internet" is a Good Thing. I consider it a Necessary Evil, a
>stage we have to go through in our evolution towards a single internet
>protocol. Having multiple, worldwide, public, non-interoperable Internets
>is as undesirable as multiple, worldwide, public, non-interoperable phone
>systems.
Then you would not be of the position that firewalled companies can 'run
IPv4 forever'? If so, then please consider what we are up against.
Our users are not supposed to be computer jockies. The software should,
within reason, plug and play. It should mix well with everything else we
have on a predominitely DOS world with DOS/Windows gaining momemtum.
Additionally the ratio of *REAL* technical people to systems is around
1:1000. The ration of people that understand DOS well enough to do some
simple configurations (not play with memory maps) is around 1:200.
And finally we buy network software (not customize PD stuff, as good as it
is), that integrates internetworking with O/A NOSs. We perfer one stop
shopping so we can easily point the finger if network access goes south.
We will gladly change from IPv4 if we get some real support value out of
IPng that will not cost our users so much memory that they can no longer do
their real work.
Also, we are frequently well educated in SNA networking, and have painfully
learned the lesson of guarenteed bandwidth for key applications. There are
such things as production windows.
So I need easy config NOW. I need QOS NOW. I need, I need. You get the
point.
Weigh this against your (the BIG INTERNET's, that is) needs of growth and
future functionality.
Where do the various contenders stand?
Robert Moskowitz
MIS Technical Support
Chrysler Corporation
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02129;
4 Aug 93 7:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02119;
4 Aug 93 7:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06569;
4 Aug 93 7:49 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02107;
4 Aug 93 7:49 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02079;
4 Aug 93 7:48 EDT
Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa06539;
4 Aug 93 7:48 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id af28317;
4 Aug 93 11:41 GMT
Date: Wed, 4 Aug 93 11:46 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: TUBA w/out IPng (was: Re: Last Call: Use of ISO CLNP in TUBA)
Message-Id: <75930804114657/0003858921NA1EM at mcimail.com>
Eva Kuiper Said:
>> 2. Who is the end-user consituency for TUBA, independent of
>> IPng?
>Anybody who is concerned about convergence of existing open protocols
>in use today using a strategy which allows for a single network
>protocol to be managed.
This is nice. This is really important. But it 'doesn't sell cars', as I
have often been told. Granted we are the smallist of the 'Big Three', but
we do not run ANY OSI apps. We have no OSI hosts. We have a number of
REALLY BIG SNA hosts, lots of IPX hosts, and lots of IP hosts.
The SNA hosts will continue to support their dedicated terminal network for
their 'legacy systems'. These same systems can also play in just about any
networking scheme. Most of the IPX hosts are also IP hosts. Not the other
way though. So I am only concerned with the convergence of a proprietary
and an open protocol. Or I may decide to join those in my company that say
to continue to run both.
IPng, to me, means addressing my technical needs where IPv4 is deficient.
Not just merging two networking technologies.
BTW, someone pointed me to where I can get the CLNP documentation online in
Postscript format. I and many other technical people out here cannot read
postscript documents online. I do not consider these as online
documentation, rather a more efficient means of distributing printed
documentation. So how am I to learn how well CLNP addresses my needs?
Without it, I cannot decide if TUBA is a better future for our networks than
SIP, PIP, or IP/IX. Maybe I should buy a copy of M. Rose's Open book?
Probably have the same cost as printing all of those PS files...
Robert Moskowitz
MIS Technical Services
Chrysler Corporation
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03658;
4 Aug 93 8:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03648;
4 Aug 93 8:41 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08335;
4 Aug 93 8:41 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03629;
4 Aug 93 8:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03512;
4 Aug 93 8:39 EDT
Received: from mitsou.inria.fr by CNRI.Reston.VA.US id aa08218;
4 Aug 93 8:39 EDT
Received: by mitsou.inria.fr
(5.65c/IDA-1.2.8) id AA11725; Wed, 4 Aug 1993 14:39:44 +0200
Message-Id: <199308041239.AA11725 at mitsou.inria.fr>
To: "Robert G. Moskowitz" <0003858921 at mcimail.com>
Cc: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of "Wed, 04 Aug 93 11:33:00 GMT."
<12930804113321/0003858921NA4EM at mcimail.com>
Date: Wed, 04 Aug 93 14:39:43 +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>
Robert,
Your point is quite significative -- a variant of the "little internet"
(firewalled or otherwise isolated IP users) vs "big Internet" (the
connectivity addict) debate. Clearly, just having larger addresses "per se"
does not bring much to the "little internet" users. They could as well use
their own isolated addressing plan combined with application gateways in the
firewall..
If we want users to actually buy, or even merely install, the new IPng, then
there are in my opinion a set of absolute conditions:
1) It should not disrupt the installed base. That is, it should be essentially
"a new release of IP", completely upward compatible with the previous
release. That is, an IPng host shall be able to speak "IP as usual" with the
existing IP hosts. There are indeed many way to do this, from "dual stack"
to "integrated routing", but any new release of IP clearly has to to be ...
a release of IP!
2) It should bring added value, and in should in no way be a "regression"
compared to the normal eveolution of IP. This means that the recently
developped or almost finalized IP evolutions like multicast or mobility
support should absolutely be distributed "as part of the new release".
And you are not alone in mentioning that autoconfiguration -- unwrap,
plug and play -- is also a necessary feature.
3) It should easily support some form of policy routing, at the very least
provider selection on a call per call basis (read datagram per datagram).
This is actually a legal requirement for some regulated carriers (e.g.
RBOCs) -- and a practical requirement for budget conscious users.
4) It should come with a clear evolution path for supporting at least two
services which are not quite as mature as "multicast", "mobility" and
"autoconfiguration", i.e. "real time" and "IP level security". I have
good hope that the current work on these two subjects will soon converge for
IPv4, but we should not delude ourselves and think that we have a solution
ready now...
As mentioned above, this is a personal opinion. Not an IAB statement. Nor an
endorsement that solution FOO does it better than solution BAR. But it would
take a lot of persuasion to convince me to endorse a solution that does not
meet these four points (I am not prone of warlike metaphors, but I already
heard Vint Cerf mentioning "over my dead body" in a similar circumstance).
Christian Huitema
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05240;
4 Aug 93 9:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05228;
4 Aug 93 9:38 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10189;
4 Aug 93 9:38 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05206;
4 Aug 93 9:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05151;
4 Aug 93 9:36 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa10124;
4 Aug 93 9:36 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA09198; Wed, 4 Aug 93 06:31:58 -0700
Message-Id: <9308041331.AA09198 at Mordor.Stanford.EDU>
To: Eva Kuiper <eva at hpindda.cup.hp.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: TUBA w/out IPng (was: Re: Last Call: Use of ISO CLNP in TUBA)
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Tue, 03 Aug 93 23:26:43 -0700. <9308040626.AA19394 at hpindda.cup.hp.com>
Date: Wed, 04 Aug 93 06:31:57 -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
Eva,
Please clarify one point:
---- Included message:
> 2. Who is the end-user consituency for TUBA, independent of
> IPng?
Anybody who is concerned about convergence of existing open protocols
in use today using a strategy which allows for a single network
protocol to be managed.
As Steve Deering observes, the effect of TCP-over-CLNP -- when taken as
independent of IPng -- is a parallel TCP world to the one that uses IP.
Since this sounds like the OPPOSITE of convergence, I'd like to hear how
you see it differently.
Thanks.
d/
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07568;
4 Aug 93 10:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12753;
4 Aug 93 10:54 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07506;
4 Aug 93 10:54 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07207;
4 Aug 93 10:49 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-manning-dns-nsap-03.txt
Date: Wed, 04 Aug 93 10:49:12 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308041049.aa07207 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : DNS NSAP Resource Records
Author(s) : B. Manning, R. Colella
Filename : draft-manning-dns-nsap-03.txt
Pages : 11
The Internet is moving towards the deployment of an OSI lower layers
infrastructure. This infrastructure comprises the connectionless network
protocol (CLNP) and supporting routing protocols. Also required as part of
this infrastructure is support in the Domain Name System (DNS) for mapping
between names and NSAP addresses.
This document defines the format of two new Resource Records (RRs) for the
DNS, replacing the earlier work in RFC 1348. The RRs defined in this paper
allow the DNS to support domain name-to-NSAP and NSAP-to-domain name
mappings. The RRs may be used with any NSAP address format.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-manning-dns-nsap-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-manning-dns-nsap-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-manning-dns-nsap-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-manning-dns-nsap-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 aa07582;
4 Aug 93 10:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12764;
4 Aug 93 10:54 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07502;
4 Aug 93 10:54 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07245;
4 Aug 93 10:49 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ups-mib at cs.utk.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-upsmib-00.txt
Date: Wed, 04 Aug 93 10:49:47 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308041049.aa07245 at IETF.CNRI.Reston.VA.US>
--NextPart
Note: This Internet Draft replaces the previous I-D
<draft-case-ups-mib-01.txt>
A New Internet Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Uninterruptible Power Supply
Working Group of the IETF.
Title : UPS Management Information Base
Author(s) : J. Case
Filename : draft-ietf-upsmib-00.txt
Pages : 33
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for managing uninterruptable
power supply (UPS) systems.
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-upsmib-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-upsmib-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-upsmib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-upsmib-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 aa07584;
4 Aug 93 10:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12761;
4 Aug 93 10:54 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07505;
4 Aug 93 10:54 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07287;
4 Aug 93 10:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: snanaumib at thumper.bellcore.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-snanau-snamib-00.txt
Date: Wed, 04 Aug 93 10:50:13 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308041050.aa07287 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 SNA NAU Services MIB Working
Group of the IETF.
Title : Definitions of Managed Objects for SNA NAUs
Author(s) : Z. Kielczewski, K. Shih
Filename : draft-ietf-snanau-snamib-00.txt
Pages : 49
This Internet-Draft defines an extension to the Management Information Base
(MIB) for use with SNMP-based network management. In particular, it
defines objects for managing the configuration, monitoring and control of
Physical Units (PUs) and Logical Units (LUs) in an SNA environment. PUs
and LUs are two types of Network Addressable Units (NAUs) in the logical
structure of an SNA network. NAUs are the origination or destination points
for SNA data streams. This draft identifies managed objects for SNA Node
Type 2.0 and LUs 0, 1, 2, 3.
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-snanau-snamib-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-snanau-snamib-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-snanau-snamib-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-snanau-snamib-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 aa07589;
4 Aug 93 10:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12755;
4 Aug 93 10:54 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07499;
4 Aug 93 10:54 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07329;
4 Aug 93 10:50 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: madman at innosoft.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-madman-mtamib-02.txt
Date: Wed, 04 Aug 93 10:50:29 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308041050.aa07329 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 Mail and Directory Management
Working Group of the IETF.
Title : Mail Monitoring MIB
Author(s) : N. Freed, S. Kille
Filename : draft-ietf-madman-mtamib-02.txt
Pages : 10
This document extends the basic Network Services Monitoring MIB to allow
monitoring of Message Transfer Agents (MTAs).
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-madman-mtamib-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-madman-mtamib-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-madman-mtamib-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-madman-mtamib-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 aa09894;
4 Aug 93 12:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09882;
4 Aug 93 12:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16871;
4 Aug 93 12:50 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09870;
4 Aug 93 12:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09840;
4 Aug 93 12:48 EDT
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa16791;
4 Aug 93 12:48 EDT
Received: from goshawk.lanl.gov by mailhost.lanl.gov (5.65/1.14)
id AA03995; Wed, 4 Aug 93 10:49:00 -0600
Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17)
id AA13302; Wed, 4 Aug 93 10:49:04 MDT
Message-Id: <9308041649.AA13302 at goshawk.lanl.gov>
To: Bill Fink <bill at wizard.gsfc.nasa.gov>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of Mon, 02 Aug 93 21:43:28 -0400.
<9308030143.AA07773 at wizard.gsfc.nasa.gov>
Date: Wed, 04 Aug 93 10:49:03 MST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: peter at goshawk.lanl.gov
Bill,
The documents for CLNP, ES-IS, IS-IS, and IDRP are online for
anonymous FTP from merit.edu:pub/iso.
There is an ongoing effort to get these documents into RFC format
and put into the RFC series.
>>> It would be helpful to have a clear statement from the TUBA folks
>>> as to what the exact intent of the TUBA spec is.
I believe the topic of this discussion is the status of the spec that
defines how to run TCP and UDP over CLNP written by Dave Piscitello.
>>> If it's just an interface specification, then I doubt there's as
>>> much controversy over that.
ok.
>>> If it's an IPng candidate, then it needs to be considered much more
>>> carefully.
An overall package which details everything necessary for the future
Internet will certainly need additional scrutiny.
It is probably best to simply say that the use of CLNP in the Internet
as a future replacement of IPv4 is a work in progress.
The reason the TUBA group forwarded this document to the IESG to be put up
as a proposed standard (PS) is that:
a) it is meant to be used by people implementing TCP/UDP over
CLNP, thus we felt it should go into the RFC "system"
since TCP and UDP are IETF standards.
b) we read RFC 1310 and figured that PS was the best fitting slot for
this document.
>>> If, as I suspect, it's some of both, it might
>>> be useful to come up with some way of separating the two aspects,
>>> like having a clean and distinct "TCP Over CLNP" interface RFC which
>>> doesn't even mention any IPng issues, and keeping the TUBA/IPng parts
>>> as IDs or experimental or prototype RFCs.
I believe when you read the document you will be satisfied.
cheers,
peter
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11236;
4 Aug 93 13:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11226;
4 Aug 93 13:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18318;
4 Aug 93 13:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11202;
4 Aug 93 13:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11154;
4 Aug 93 13:46 EDT
Received: from newsun.Novell.COM by CNRI.Reston.VA.US id aa18244;
4 Aug 93 13:46 EDT
Received: from va.SJF.Novell.COM by newsun.Novell.COM (4.1/SMI-4.1)
id AA21737; Wed, 4 Aug 93 10:47:25 PDT
Received: by va.SJF.Novell.COM (4.1/SMI-4.1)
id AA06704; Wed, 4 Aug 93 10:45:11 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Neal Castagnoli <Neal_Castagnoli at novell.com>
Message-Id: <9308041745.AA06704 at va.SJF.Novell.COM>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: Dave Katz <dkatz at cisco.com>
Date: Wed, 4 Aug 93 10:45:11 PDT
Cc: Neal_Castagnoli at novell.com, ietf at CNRI.Reston.VA.US
In-Reply-To: <199308032329.AA26207 at large.cisco.com>; from "Dave Katz" at Aug 3, 93 4:29 pm
X-Mailer: Elm [version 2.1 alpha-test]
>
> So, while theoretically you can reduce the number of filters, in practice you
> may find that you can't. Being able to reduce filters is predicated on the
> creation of systems that don't exist, and so it is difficult to say how such
> a system would actually behave, and perform, and whether such a system is
> useable (from an administrative point of view).
>
> I guess I don't share your pessimism. Certainly the ability to
> support multiple areas has been demonstrated (albeit in OSPF), the
^^^^
> ability to provide arbitrary filtering on NSAP addresses in various
> places has been implemented, and methods for assigning addresses in
> order to perform clustering has been studied extensively and are
> being deployed today.
>
> The most difficult aspect of this seems to be doing a good job of
> designing the network, but customers building a complex network know
> enough to get expert assistance.
>
Actually, OSPF has multiple area support built in. This is different than
IS - IS. In IS - IS, in order to support multiple areas, you must have
multiple instantiations of the routing protocol. Because of this, when there
is a change in the backbone, you will run Dijkstra for as many areas
(administrative entities) as you have created on the router. This is
different from OSPF, in that OSPF will run Dijkstra only once per change in
the network, per router. In IS - IS, you could be running Dijkstra many
times per network change. I do think that this will have an impact on the
way that individuals may design their networks.
Also, I think that running multiple instantiations of the routing protocol on
a box may also pose problems, in that it may be difficult to administer,
since, in essence, you have taken a single box and made it into many logical
boxes, each requireing administration.
--Neal Castagnoli
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11787;
4 Aug 93 14:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11777;
4 Aug 93 14:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18785;
4 Aug 93 14:05 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11764;
4 Aug 93 14:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11713;
4 Aug 93 14:03 EDT
Received: from watson.ibm.com by CNRI.Reston.VA.US id aa18725;
4 Aug 93 14:03 EDT
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8415;
Wed, 04 Aug 93 14:04:15 EDT
Date: Wed, 4 Aug 93 14:04:14 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: yakov at watson.ibm.com
To: peter at goshawk.lanl.gov, bill at wizard.gsfc.nasa.gov
cc: ietf at CNRI.Reston.VA.US
Subject: Last Call: Use of ISO CLNP in TUBA
Message-ID: <9308041403.aa18725 at CNRI.Reston.VA.US>
Ref: Your note of Wed, 04 Aug 93 10:49:03 MST
>There is an ongoing effort to get these documents
>into RFC format...
IDRP in RFC format *is* available via anonymous FTP from
merit.edu - pub/iso/idrprfc.txt[.z].
Yakov Rekhter
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12959;
4 Aug 93 15:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12949;
4 Aug 93 15:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21556;
4 Aug 93 15:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12936;
4 Aug 93 15:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12875;
4 Aug 93 15:33 EDT
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa21472;
4 Aug 93 15:33 EDT
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <13636>; Wed, 4 Aug 1993 12:32:38 PDT
Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 4 Aug 1993 12:32:23 -0700
To: Eva Kuiper <eva at hpindda.cup.hp.com>
Cc: ietf at CNRI.Reston.VA.US, deering at parc.xerox.com
Subject: Re: TUBA w/out IPng (was: Re: Last Call: Use of ISO CLNP in TUBA)
In-reply-to: Your message of "Tue, 03 Aug 93 23:26:43 PDT."
<9308040626.AA19394 at hpindda.cup.hp.com>
Date: Wed, 4 Aug 1993 12:32:18 PDT
X-Orig-Sender: Steve Deering <deering at parc.xerox.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Deering <deering at parc.xerox.com>
Message-Id: <93Aug4.123223pdt.12171 at skylark.parc.xerox.com>
> Does this mean that as each IPng contender reaches the stage when it
> is ready to go to proposed standard it first has to remove itself
> from the IPng list? This leads us to no candidates :-)
Eva,
This is all getting quite silly, and no doubt it is partly my fault.
Let me try to clear up at least my own concerns, since they seem to
have been misunderstood by some.
I had assumed that the IESG would impose certain requirements that each
of the IPng candidates would have to satisfy before proceeding to Proposed
Standard, such as the need for a complete set of documents (protocol specs,
addressing guidelines, routing schemes, transition plans, environmental-
impact statements, and so on), similar to the way routing protocols have
extra-ordinary requirements for advancing along the Standards track. If that
is not the case, and the IESG is willing to advance each group's documents
one at a time, as they become ready, that's fine with me. I will immediately
submit the SIP spec as a PS, Paul will submit all of his Pip documents, and
Robert will request that his Experimental RFCs be reclassified as PSs. I
believe all of those documents have met the normal requirements for advancing
to PS status.
We need to hear from the IESG what their policy is with respect to IPng
candidates filing for PS. *If* it turns out that they are going to impose
extra-ordinary requirements, then I think it would be inappropriate to
exempt the TUBA spec from those requirements based on the claim that
TUBA has a constituency independent of the IPng process. I think it
would be inappropriate on procedural grounds (we must all play by the
same rules if the IPng selection process is to be seen as fair), and on
technical grounds (because TUBA as a means of supporting TCP/UDP applications
on CLNP hosts makes sense technically only in the context of CLNP as an IPng
candidate).
I am *not* trying to put procedural obstacles in the way of CLNP being
adopted as IPng. If the IESG will permit the IPng groups to advance
documents to PS status one at a time, great! If they insist on a complete
document set, that's fine too -- I suspect that the TUBA group will be able
to satisfy that requirement sooner than the other groups, and I would *not*
insist on making TUBA wait for all the other groups to catch up.
So, let's hear what the IESG has to say.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13781;
4 Aug 93 16:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13771;
4 Aug 93 16:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23006;
4 Aug 93 16:21 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13759;
4 Aug 93 16:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13710;
4 Aug 93 16:19 EDT
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa22925;
4 Aug 93 16:19 EDT
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <13636>; Wed, 4 Aug 1993 13:20:05 PDT
Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 4 Aug 1993 13:19:53 -0700
To: "Robert G. Moskowitz" <0003858921 at mcimail.com>
Cc: ietf at CNRI.Reston.VA.US, deering at parc.xerox.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-reply-to: Your message of "Wed, 04 Aug 93 04:33:00 PDT."
<12930804113321/0003858921NA4EM at mcimail.com>
Date: Wed, 4 Aug 1993 13:19:42 PDT
X-Orig-Sender: Steve Deering <deering at parc.xerox.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Steve Deering <deering at parc.xerox.com>
Message-Id: <93Aug4.131953pdt.12171 at skylark.parc.xerox.com>
> >I suppose it comes down to whether or not you believe our goal should be
> >a single, ubiquitous internet protocol. Some people think that a "multi-
> >protocol Internet" is a Good Thing. I consider it a Necessary Evil, a
> >stage we have to go through in our evolution towards a single internet
> >protocol. Having multiple, worldwide, public, non-interoperable Internets
> >is as undesirable as multiple, worldwide, public, non-interoperable phone
> >systems.
>
> Then you would not be of the position that firewalled companies can 'run
> IPv4 forever'?
Au contraire. I have no problem with organizations continuing to run
IPv4 and AppleTalk and IPX and Chaosnet and Pup and so on for as long
as they get some value out of doing so. In fact, we have worked hard
in the SIP/IPAE group to make sure that SIP hosts will be able to talk
to IPv4 hosts within the same local domain "forever".
My concern (in this thread of messages, not my *only* concern) is with the
worldwide, capital "I" Internet that allows different organizations and
individuals to communicate with each other. I'd hate to see us build
multiple, non-interoperable Internets. (By "us" I mean the IETF/Internet
community. Novell will probably build a parallel internet anyway. It
will be a lot easier for them, because they won't have to build concencus
the way we do.) I'd *particularly* hate to see us build multiple, non-
interoperable Internets for TCP/UDP applications!
> So I need easy config NOW. I need QOS NOW. I need, I need. You get the
> point.
Yes, I get the point. I believe all of the IPng proposals are attempting
to satify those needs, plus more (multicast, security, mobility, ...),
at the same time as dealing with the scaling problems of Big Internet
addressing and routing. If we don't, no one will deploy it.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14945;
4 Aug 93 17:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14941;
4 Aug 93 17:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26270;
4 Aug 93 17:50 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14932;
4 Aug 93 17:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14928;
4 Aug 93 17:50 EDT
Received: from SAFFRON.ACC.COM by CNRI.Reston.VA.US id aa26226;
4 Aug 93 17:50 EDT
Received: by saffron.acc.com (4.1/SMI-4.1)
id AA14133; Wed, 4 Aug 93 14:50:38 PDT
Date: Wed, 4 Aug 93 14:50:38 PDT
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Fred Baker <fbaker at acc.com>
Message-Id: <9308042150.AA14133 at saffron.acc.com>
To: craig at aland.bbn.com, ietf at CNRI.Reston.VA.US
Subject: re: Last Call: Compressing IPX Headers Over WAN Media (CIPX) to Proposed Standard
Cc: IESG at CNRI.Reston.VA.US
Craig:
Novell and Telebit, among others, wrote the draft that you're questioning.
PPP WG has already standardized DECNET, AppleTalk, and other things over PPP;
there is plenty of precedent for this document.
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15822;
4 Aug 93 19:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29180;
4 Aug 93 19:59 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15797;
4 Aug 93 19:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15729;
4 Aug 93 19:56 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa29121;
4 Aug 93 19:56 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA04931>; Wed, 4 Aug 1993 16:56:45 -0700
Message-Id: <199308042356.AA04931 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1497 on BOOTP Extensions
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 04 Aug 93 16:56:40 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 1497:
Title: BOOTP Vendor Information Extensions
Author: J. Reynolds
Mailbox: jkrey at isi.edu
Pages: 8
Characters: 16,805
Obsoletes: 1395, 1084, 1048
Updates: 951
This RFC is a slight revision and extension of RFC-1048 by Philip
Prindeville, who should be credited with the original work in this
memo. This memo will be updated as additional tags are are defined.
This edition introduces Tag 18 for Extension Path.
This memo is a status report on the vendor information extensions used
in the Bootstrap Protocol (BOOTP). 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 rfc1497.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1497.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 aa15851;
4 Aug 93 19:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15832;
4 Aug 93 19:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29187;
4 Aug 93 19:59 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15799;
4 Aug 93 19:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15741;
4 Aug 93 19:56 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa29128;
4 Aug 93 19:56 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA04947>; Wed, 4 Aug 1993 16:57:34 -0700
Message-Id: <199308042357.AA04947 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1498 on On the Naming and Binding of Network Destinations
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Wed, 04 Aug 93 16:57:29 PDT
X-Orig-Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-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 1498:
Title: On the Naming and Binding of Network Destinations
Author: J. Saltzer
Mailbox: Saltzer at MIT.EDU
Pages: 10
Characters: 24,698
Updates/Obsoletes: none
This brief paper offers a perspective on the subject of names of
destinations in data communication networks. It suggests two ideas:
First, it is helpful to distinguish among four different kinds of
objects that may be named as the destination of a packet in a network.
Second, the operating system concept of binding is a useful way to
describe the relations among the four kinds of objects. To illustrate
the usefulness of this approach, the paper interprets some more subtle
and confusing properties of two real-world network systems for naming
destinations.
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 rfc1498.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1498.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 aa16236;
4 Aug 93 21:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16226;
4 Aug 93 21:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01138;
4 Aug 93 21:36 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16211;
4 Aug 93 21:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16185;
4 Aug 93 21:34 EDT
Received: from [192.26.147.1] by CNRI.Reston.VA.US id aa01031;
4 Aug 93 21:34 EDT
Received: by WLV.IIPO.GTEGSC.COM (5.65/1.35)
id AA03162; Wed, 4 Aug 93 18:34:20 -0700
Date: Wed, 4 Aug 93 18:34:20 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Merton Campbell Crockett <mcc at wlv.iipo.gtegsc.com>
Message-Id: <9308050134.AA03162 at WLV.IIPO.GTEGSC.COM>
To: 0003858921 at mcimail.com, ietf at CNRI.Reston.VA.US
Subject: Re: TUBA w/out IPng (was: Re: Last Call: Use of ISO CLNP in TUBA)
>From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
>BTW, someone pointed me to where I can get the CLNP documentation online in
>Postscript format. I and many other technical people out here cannot read
>postscript documents online. I do not consider these as online
>documentation, rather a more efficient means of distributing printed
>documentation.
First time I can recall postscript being described as an efficient means
of distributing printed material. ;-)
Merton Campbell Crockett
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16375;
4 Aug 93 21:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16365;
4 Aug 93 21:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01655;
4 Aug 93 21:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16343;
4 Aug 93 21:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16317;
4 Aug 93 21:54 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa01554;
4 Aug 93 21:55 EDT
Received: by ginger.lcs.mit.edu
id AA06546; Wed, 4 Aug 93 21:55:39 -0400
Date: Wed, 4 Aug 93 21:55:39 -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: <9308050155.AA06546 at ginger.lcs.mit.edu>
To: ietf at CNRI.Reston.VA.US
Subject: Re: RFC1498 on On the Naming and Binding of Network Destinations
Cc: jnc at ginger.lcs.mit.edu
This is the first of (hopefully :-) a series of key networking papers
that I am going to try to make avilable online, as Informational RFC's, for
the benfit of the community.
For those of you who've never read, or heard of, this 1982 paper, I
cannot recommend it more highly. (I typed it in by hand myself, from an
ancient paper copy, to make it available! :-) It is one of those rare computer
science papers that says something so fundamental that, years after it came
out, the basic message is as important and useful as the day it was written
(although the technology examples will be a bit dated, obviously). The ideas
still have not been fully absorbed into the community idea base.
Everyone, and I mean *everyone*, who is involved in designing
networking protocols *has* to read this paper; it may not be the most
important networking paper of all time, but it's pretty close, certainly one
of the top 10 or so, by my estimation. I hope you can all find the time to
retrieve and read it; it is fairly short, and easy to read. It will be worth
it.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16548;
4 Aug 93 22:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16538;
4 Aug 93 22:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02215;
4 Aug 93 22:21 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16526;
4 Aug 93 22:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16500;
4 Aug 93 22:20 EDT
Received: from large.cisco.com by CNRI.Reston.VA.US id aa02196;
4 Aug 93 22:20 EDT
Received: by large.cisco.com id AA05405
(5.67a/IDA-1.5 for ietf at CNRI.Reston.VA.US); Wed, 4 Aug 1993 19:21:21 -0700
Date: Wed, 4 Aug 1993 19:21:21 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Katz <dkatz at cisco.com>
Message-Id: <199308050221.AA05405 at large.cisco.com>
To: Neal_Castagnoli at novell.com
Cc: Neal_Castagnoli at novell.com, ietf at CNRI.Reston.VA.US
In-Reply-To: Neal Castagnoli's message of Wed, 4 Aug 93 10:45:11 PDT <9308041745.AA06704 at va.SJF.Novell.COM>
Subject: Last Call: Use of ISO CLNP in TUBA
Actually, OSPF has multiple area support built in. This is different than
IS - IS. In IS - IS, in order to support multiple areas, you must have
multiple instantiations of the routing protocol. Because of this, when there
is a change in the backbone, you will run Dijkstra for as many areas
(administrative entities) as you have created on the router. This is
different from OSPF, in that OSPF will run Dijkstra only once per change in
the network, per router. In IS - IS, you could be running Dijkstra many
times per network change. I do think that this will have an impact on the
way that individuals may design their networks.
Also, I think that running multiple instantiations of the routing protocol on
a box may also pose problems, in that it may be difficult to administer,
since, in essence, you have taken a single box and made it into many logical
boxes, each requireing administration.
There are ways of finessing implementations in order to avoid doing
multiple level-2 Dijkstra calculations and to make administration reasonable.
We should drop this thread, since we are both guilty of willful
conjecture at this point--let's spare the poor masses. :-)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01180;
5 Aug 93 6:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01170;
5 Aug 93 6:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02084;
5 Aug 93 6:14 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01152;
5 Aug 93 6:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01119;
5 Aug 93 6:05 EDT
Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa01969;
5 Aug 93 6:05 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ab11073;
5 Aug 93 10:01 GMT
Date: Thu, 5 Aug 93 10:05 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Message-Id: <50930805100505/0003858921NA3EM at mcimail.com>
Peter said:
>The documents for CLNP, ES-IS, IS-IS, and IDRP are online for
>anonymous FTP from merit.edu:pub/iso.
>There is an ongoing effort to get these documents into RFC format
>and put into the RFC series.
Those are the ones that are PS files..... ugh.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01546;
5 Aug 93 6:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01536;
5 Aug 93 6:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02933;
5 Aug 93 6:54 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01524;
5 Aug 93 6:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01474;
5 Aug 93 6:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aq02740;
5 Aug 93 6:53 EDT
Received: from relay.hp.com by IETF.CNRI.Reston.VA.US id aa00896;
5 Aug 93 4:45 EDT
Received: from hpindda.cup.hp.com by relay.hp.com with SMTP
(16.6/15.5+IOS 3.13) id AA14654; Thu, 5 Aug 93 01:44:31 -0700
Received: by hpindda.cup.hp.com
(15.11/15.5+IOS 3.20+cup+OMrelay) id AA20806; Thu, 5 Aug 93 01:44:29 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: <9308050844.AA20806 at hpindda.cup.hp.com>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: deering at parc.xerox.com
Date: Thu, 5 Aug 93 1:44:28 PDT
Cc: 0003858921 at mcimail.com, ietf at CNRI.Reston.VA.US, eva at hpindda.cup.hp.com
In-Reply-To: <93Aug4.131953pdt.12171 at skylark.parc.xerox.com>; from "Steve Deering" at Aug 4, 93 1:19 pm
Mailer: Elm [revision: 64.9]
Steve,
I regret I am going off on vacation and can't enjoy more of this
discussion, but I am beginning to see from what you said below how
that we look at the world in a different way. I see the role of
a Global Internet as being able to handle different business needs
and different requirements by providing the glue which ties things
together. This includes things like network gateways, IPng <-> x, whether
x is Novell or Banyan or IPv4 or whatever. I don't see it as a "one
size fits all" where there is only one solution which everyone must
agree to use. The suggestion that those who need something different have to
find a different network to run on is totally orthogonal to the concept of
a truly global open network. Instead, it promotes multiple closed
networks. I don't see a network where everyone is told they have to
do things exactly the same way as an open network. I see it as closed
and proprietary. The Internet has many service providers, some of which
are commercial and serve industries which have requirements to use
applications and networks which are not just IPv4. These industries are
as global as the Internet itself and benefit from an infrastructure which
has the flexibility to allow the end user to choose what is best for
his business needs. If part of his business world uses IPv4 and part uses
CLNP and part uses IPX a truly global network would allow him communication
with all these communities depending on varying day-to-day requirements.
A truly global internet would promote the concept of learning how to use
the best technical concepts to provide the means to communicate when
users choose different applications and networks. It is obvious that forcing
everyone to have only one option gives maximum interoperability, but this
does not address the real world of many excellent choices which
communities of users in like industries might feel are best for them.
Multiple internets are only non-interoperable when they are so physically
isolated that the technology to tie them together has to be moved to the
end systems instead of being shared by multiple communities. The concept
of a global network should be one that provides the technology to avoid
this type of situation. I guess I don't quite understand a world where
only one choice can be the right choice and all other choices therefore
must be wrong. Up until now the Internet seemed to be a truly open network,
but I feel that the openness really starts to disappear when choices are
restricted.
Eva
>
> Au contraire. I have no problem with organizations continuing to run
> IPv4 and AppleTalk and IPX and Chaosnet and Pup and so on for as long
> as they get some value out of doing so. In fact, we have worked hard
> in the SIP/IPAE group to make sure that SIP hosts will be able to talk
> to IPv4 hosts within the same local domain "forever".
>
> My concern (in this thread of messages, not my *only* concern) is with the
> worldwide, capital "I" Internet that allows different organizations and
> individuals to communicate with each other. I'd hate to see us build
> multiple, non-interoperable Internets. (By "us" I mean the IETF/Internet
> community. Novell will probably build a parallel internet anyway. It
> will be a lot easier for them, because they won't have to build concencus
> the way we do.) I'd *particularly* hate to see us build multiple, non-
> interoperable Internets for TCP/UDP applications!
>
> > So I need easy config NOW. I need QOS NOW. I need, I need. You get the
> > point.
>
> Yes, I get the point. I believe all of the IPng proposals are attempting
> to satify those needs, plus more (multicast, security, mobility, ...),
> at the same time as dealing with the scaling problems of Big Internet
> addressing and routing. If we don't, no one will deploy it.
>
> Steve
>
>
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04166;
5 Aug 93 9:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06987;
5 Aug 93 9:27 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04154;
5 Aug 93 9:27 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04089;
5 Aug 93 9:22 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: tuba at lanl.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-tuba-clnp-04.txt
Date: Thu, 05 Aug 93 09:22:43 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308050922.aa04089 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 TCP/UDP over CLNP-addressed
Networks Working Group of the IETF.
Title : Use of ISO CLNP in TUBA Environments
Author(s) : David Piscitello
Filename : draft-ietf-tuba-clnp-04.txt
Pages : 23
This document describes the use of CLNP to provide the lower-level service
expected by Transmission Control Protocol and User Datagram Protocol. CLNP
provides essentially the same datagram service as Internet Protocol, but
offers a means of conveying bigger network addresses (with additional
structure, to aid routing).
While the protocols offer nearly the same services, IP and CLNP are not
identical. This document describes a means of preserving the semantics of
IP information that is absent from CLNP while preserving consistency
between the use of CLNP in Internet and OSI environments. This maximizes
the use of already-deployed CLNP implementations.
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-tuba-clnp-04.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-tuba-clnp-04.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-tuba-clnp-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tuba-clnp-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 aa05444;
5 Aug 93 10:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05430;
5 Aug 93 10:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08487;
5 Aug 93 10:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05404;
5 Aug 93 10:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05345;
5 Aug 93 10:05 EDT
Received: from shiva2.cac.washington.edu by CNRI.Reston.VA.US id aa08434;
5 Aug 93 10:05 EDT
Received: by shiva2.cac.washington.edu
(5.65/UW-NDC Revision: 2.28 ) id AA23190; Thu, 5 Aug 93 07:02:15 -0700
Date: Thu, 5 Aug 1993 06:52:22 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Terry Gray <gray at cac.washington.edu>
X-Orig-Sender: Terry Gray <gray at cac.washington.edu>
Reply-To: Terry Gray <gray at cac.washington.edu>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: Eva Kuiper <eva at hpindda.cup.hp.com>
Cc: deering at parc.xerox.com, 0003858921 at mcimail.com, ietf at CNRI.Reston.VA.US
In-Reply-To: <9308050844.AA20806 at hpindda.cup.hp.com>
Message-Id: <Pine.3.84.9308050623.M23021-0100000 at shiva2.cac.washington.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
On Thu, 5 Aug 1993, Eva Kuiper wrote:
> I see the role of
> a Global Internet as being able to handle different business needs
> and different requirements by providing the glue which ties things
> together.
> I don't see it as a "one
> size fits all" where there is only one solution which everyone must
> agree to use. The suggestion that those who need something different have to
> find a different network to run on is totally orthogonal to the concept of
> a truly global open network. Instead, it promotes multiple closed
> networks. I don't see a network where everyone is told they have to
> do things exactly the same way as an open network. I see it as closed
> and proprietary.
Eva,
Your definition of "openess" is very different than my own.
To me the difference between running multiple non-interoperable protocols
over a single set of wires ("network") vs. running them over separate
dedicated wires ("networks") is purely a matter of cost savings; using a
single set of wires does nothing to promote interoperability.
For me, "openess" implies choice of vendors and sources, not having an
admixture of conflicting technologies around. Your goals are obviously
different, but like Deering, I believe the key goal for the Internet
should be pervasive end-to-end interoperability. There are many levels
where interoperability (or perhaps more generally, "interworking") can
break down, but if you fail to achieve it at layer 3 you are without
rational hope of achieving it at the user level. (No, I don't want to
hear about the wonders of application gateways... :)
You've heard me say it before: heterogeneity *always* costs you more than
you think it will --and the cost is not always in dollars; at layer 3, it
keeps you from getting your work done, unless you are content to live in
a closed community. (Some networking diversity only affects costs, but
not so much interoperability; e.g. if you choose to support both Enet and
Token Ring at your site it will cost you more than just picking one, but
users of both can still interoperate. The same is NOT true at layer 3.)
> I guess I don't quite understand a world where
> only one choice can be the right choice and all other choices therefore
> must be wrong. Up until now the Internet seemed to be a truly open network,
> but I feel that the openness really starts to disappear when choices are
> restricted.
As Steve said, "au contraire"... Choices *must* be restricted in order to
achieve interoperability.
Again, one of the ironies of our business is that to permit a "thousand
flowers to bloom" on the desktop, that is, a wide diversity of different
but *interoperable* applications, it is essential to agree on what goes
across the wire, especially at layer 3. Therefore, just as having
defined both CONS and CLNP in the OSI family seriously hindered its
prospects, stating that multiprotocolism is a goal of the Internet will
appease conflicting political forces, but will be disasterous to the
cause of interoperability. As usual the end-users, not the vendors, will
be the losers. From my perspective, the absolutely worst outcome --for
the users-- of the IPng debate would be failing to choose a single protocol.
I care far less which technology wins than I care that there be only one.
It's an old analogy, but still appropriate: the different gauge railroad
tracks in certain European countries require you to change trains when
you cross the border. You are advocating the same thing for the
Internet. That is NOT the network world I want to live in.
-teg
p.s. Have a nice vacation!
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09287;
5 Aug 93 12:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09277;
5 Aug 93 12:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13460;
5 Aug 93 12:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09252;
5 Aug 93 12:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09186;
5 Aug 93 12:31 EDT
Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa13421;
5 Aug 93 12:31 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id bx23100;
5 Aug 93 16:11 GMT
Date: Thu, 5 Aug 93 16:15 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: ietf <ietf at CNRI.Reston.VA.US>
Subject: Another requirement for IPng
Message-Id: <73930805161537/0003858921NA1EM at mcimail.com>
I just had a terrible image pass my vision: IPlg or last generation.
There we will be realizing that we can't do NATs becuase of imbedded
addressing structures in apps and imbedded CRC calculations and who knows
what else that had crept in. We will be wringing our collective hands about
how to transition and how to convince our funding agencies to come up with
the $$$ for all of this.
CAN WE PLEASE HAVE A LITTLE FORSIGHT?
Here we are, 'fixing' FTP so it can handle bigger addresses. How big is big
enough? What other variants on big addresses are possible?
We are looking at kernels that will run both IPv4 and IPng as old stuff just
dosn't seem to want to go away (we are still running DOS 3.3 on thousands of
PCs and that cramps many a batch file).
The more I seem to get in sync with what you enjineers are up to, the less
sleep I get at night...
Maybe, just maybe, we need a radical view point. I don't knwo; brain numb,
can't think...
Robert Moskowitz
MIS Tech Services
Chrysler Corp
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09303;
5 Aug 93 12:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09289;
5 Aug 93 12:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13465;
5 Aug 93 12:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09254;
5 Aug 93 12:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09175;
5 Aug 93 12:31 EDT
Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa13403;
5 Aug 93 12:31 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id bv23100;
5 Aug 93 16:11 GMT
Date: Thu, 5 Aug 93 16:15 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: ietf <ietf at CNRI.Reston.VA.US>
Subject: What is 'Openess'?
Message-Id: <52930805161525/0003858921NA1EM at mcimail.com>
Terry Gray said:
>For me, "openess" implies choice of vendors and sources, not having an
>admixture of conflicting technologies around. Your goals are obviously
>different, but like Deering, I believe the key goal for the Internet
>should be pervasive end-to-end interoperability. There are many levels
>where interoperability (or perhaps more generally, "interworking") can
>break down, but if you fail to achieve it at layer 3 you are without
>rational hope of achieving it at the user level. (No, I don't want to
>hear about the wonders of application gateways... :)
Here comes the corporate end user support staff again....
As an important aside first, I really enjoyed reading RFC1498; 'what's in a
name?'.
Openess can mean many things to many people. But if a group discussing it
do not agree on its definition, then there can be very little understanding
in the conversation.
Our TeleComm people can 'open' up our WAN to multiple protocols. Does this
make our WAN an open architecture? Well, yes as IT is communicating many
things successfully between its components. But the user running DECNet
cannot reach an IBM host without an application gateway (fortunately, we
have just about eliminated DECNet as a protocol here, one down and...).
The user, and I mean THOUSANDs of DOS users, need access to many services.
We can and are constantly throwing gateways at the problem. And we can't
look to multi-protocol as the answer, as DOS won't die easily.
As Terry said, Openess, in a networking view, is at the 3rd level. I also
contend it is at the 4th level as well.
Robert Moskowitz
MIS Tech Services
Chrysler Corp
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09703;
5 Aug 93 12:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09693;
5 Aug 93 12:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13928;
5 Aug 93 12:54 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09658;
5 Aug 93 12:54 EDT
Received: from SAFFRON.ACC.COM by IETF.CNRI.Reston.VA.US id aa09542;
5 Aug 93 12:53 EDT
Received: by saffron.acc.com (4.1/SMI-4.1)
id AA15453; Thu, 5 Aug 93 09:53:45 PDT
Date: Thu, 5 Aug 93 09:53:45 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Fred Baker <fbaker at acc.com>
Message-Id: <9308051653.AA15453 at saffron.acc.com>
To: ericf at atc.boeing.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: ietf at IETF.CNRI.Reston.VA.US
Eric:
I just read your call for reason (just got back from Europe and am
still a few days behind in my mail) with sympathy and appreciation. I
understand NIH and the feeling of ownership that one has for an
approach one has worked long and hard on (have been known to make that
error myself), and I see all sides in this debate occasionally falling
into the trap.
I think that we have all the necessary facts to come to a consensus. We
have a set of requirements, we know what the differing approaches will
and will not do, we know that they are all implementable and have
deployable if immature implementations. What we lack is a clear
technical winner; as a result, we are not working on technical issues
at this point, IMHO. It looks to me like any of TP/IX, PIP, SIP, or
TUBA will accomplish the job for the next five to ten years. Whether
any of them will actually last longer is anybody's guess. Frank
Solenski tells us we might well have 75,000,000 IP/SIP/IPv7 networks or
NSAP prefixes to contend with within a decade, and it's my guess that
we'll be back to discussing the implications of that long before
running out of bigger addresses is a glimmer of a problem in any
approach.
The big issue at this point is coexistence and its effect on the
applications. The approaches are *not* equal here. I propose that we
focus our thrashing on getting a solution that will coexist well
without requiring a gateway or major host/application changes to do
so. I would suggest that we *ignore* the effect on the routers other
than memory efficiency - the relative cost of the routers is a drop in
the bucket compared to the cost of the hosts, and the staff that
maintains the routers is very different from the folks who use the
hosts.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10125;
5 Aug 93 13:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10114;
5 Aug 93 13:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14678;
5 Aug 93 13:10 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10099;
5 Aug 93 13:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10052;
5 Aug 93 13:09 EDT
Received: from pooh.cc.iastate.edu by CNRI.Reston.VA.US id aa14625;
5 Aug 93 13:09 EDT
Received: by iastate.edu with sendmail-5.57/4.7
id <AA00391 at iastate.edu>; Thu, 5 Aug 93 12:09:52 -0500
Message-Id: <9308051709.AA00391 at iastate.edu>
To: "Robert G. Moskowitz" <0003858921 at mcimail.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Another requirement for IPng
In-Reply-To: Your message of Thu, 05 Aug 93 16:15:00 +0000.
<73930805161537/0003858921NA1EM at mcimail.com>
Date: Thu, 05 Aug 93 12:09:51 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>
> We are looking at kernels that will run both IPv4 and IPng as old stuff just
> dosn't seem to want to go away ...
> The more I seem to get in sync with what you enjineers are up to, the less
> sleep I get at night...
> Robert Moskowitz
> MIS Tech Services
> Chrysler Corp
Just consider it getting even for the b*st*rds who mixed
U.S. and Metric fasteners on our cars... ;-)
(a nice example of how 2 "open standards" are not better than 1)
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11061;
5 Aug 93 13:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11051;
5 Aug 93 13:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15532;
5 Aug 93 13:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11034;
5 Aug 93 13:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10966;
5 Aug 93 13:36 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa15487;
5 Aug 93 13:36 EDT
Received: by ginger.lcs.mit.edu
id AA09522; Thu, 5 Aug 93 13:36:33 -0400
Date: Thu, 5 Aug 93 13:36:33 -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: <9308051736.AA09522 at ginger.lcs.mit.edu>
To: gray at cac.washington.edu, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: jnc at ginger.lcs.mit.edu
I believe the key goal for the Internet should be pervasive end-to-end
interoperability. ... if you fail to achieve it at layer 3 you are without
rational hope of achieving it at the user level. ... heterogeneity
*always* costs you more than you think it will
How true, all of them...
stating that multiprotocolism is goal of the Internet will appease
conflicting political forces, but will be disasterous to the cause of
interoperability.
I have a complex reaction to this (as is perhaps not unsurprising from the
person who invented the concept of the multi-protocol router and backbone,
at MIT in the late 70's :-), and I agree to some degree with both you and Eva.
Lyman Chapin has this model I believe in, which is that networks (and not just
data) display a cyclical pattern. Multiple options for communicating with
exist, and then you (at some cost :-) establish ubiquity, in which the
advantages of having just one form of communication which allows everyone to
communicate brings a single choice to the top. Then, the limitations of that
choice, and the difficulty of changing an installed base which is being relied
on for service, cause new things to emerge, and the cycle repeats itself.
When I came up with the multi-protocol idea, I frankly didn't have this cycle
in mind. The sitation at MIT at the time was much like today; two protocols
(CHAOS, and TCP/IP) were in use, and it became painfully (very painfully; oh,
protocol wars :-) obvious that it was easier to have the communication
infrastructure support both, and allow the users to decide, than to decide the
issue among the protocol people themselves. They, for good technical reasons,
not to mention the inevitable human ones, each truly thought their option
superior, and the arguments got nowhere. (Sound familiar? :-) Hence, the
multi-protocol router/backbone. I thought at the time that it was a passing
phase, eventually to be supplanted by the One True Protocol (i.e. it was
adopted for political reasons, i.e. to bypass the politics). Now I see that
there are perhaps structural reasons (advance of technology, etc) why the
cycle might repeat itself again.
From my perspective, the absolutely worst outcome of the IPng debate would
be failing to choose a single protocol. I care far less which technology
wins than I care that there be only one.
"The grass is always greener on the other side." From where you sit, in the
middle of this confusion, it may seem worse, but I assure you that if you were
locked into a lobotomized protocol, the multi-protocol model would seem not so
bad. Would I prefer that the entire network share a single internetworking
layer? Absolutely. Do I see multi-protocol support as the *least painful way*
of getting to that future. Also true.
Allowing the market to choose sounds inefficent, but think back: what cost the
most in the ISO/TCP-IP, SNMP/CMOT, OSPF/IS-IS battles; the political fighting,
or the marketplace deciding? Multi-protocol support is the most efficient,
and least painfully political way, of letting the market decide.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12293;
5 Aug 93 14:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12281;
5 Aug 93 14:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16775;
5 Aug 93 14:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12264;
5 Aug 93 14:13 EDT
Received: from uu7.psi.com by IETF.CNRI.Reston.VA.US id aa12212;
5 Aug 93 14:12 EDT
Received: from gdc.com by uu7.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA15216 for ietf at ietf.cnri.reston.va.us; Thu, 5 Aug 93 14:12:41 -0400
Received: by gdc.com (4.1/GDC.-B)
id AA14567; Thu, 5 Aug 93 14:12:33 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Seng-Poh Lee <lee at gdc.com>
Message-Id: <9308051812.AA14567 at gdc.com>
Subject: Subscirbe
To: ietf at IETF.CNRI.Reston.VA.US
Date: Thu, 5 Aug 1993 14:12:32 -0400 (EDT)
X-Whois: SL175
X-Mailer: ELM [version 2.4 PL0]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Length: 382
Subscribe ietf Seng-Poh Lee
--
=========================================================================
Seng-Poh Lee | Internet: Work: splee at gdc.com
General DataComm Ind. Inc. | Alt : splee at pd.org
Middlebury, CT | splee at gnu.ai.mit.edu
=========================================================================
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12350;
5 Aug 93 14:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12340;
5 Aug 93 14:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16830;
5 Aug 93 14:14 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12330;
5 Aug 93 14:14 EDT
Received: from GINGER.LCS.MIT.EDU by IETF.CNRI.Reston.VA.US id aa12269;
5 Aug 93 14:13 EDT
Received: by ginger.lcs.mit.edu
id AA09766; Thu, 5 Aug 93 14:13:47 -0400
Date: Thu, 5 Aug 93 14:13:47 -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: <9308051813.AA09766 at ginger.lcs.mit.edu>
To: ericf at atc.boeing.com, fbaker at acc.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: ietf at IETF.CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
I think that we have all the necessary facts to come to a consensus. We
have a set of requirements, we know what the differing approaches will
and will not do
Pardon me while I disagree with the implicit conclusion of your first
assertion; i.e. that having the facts in hand, and agreed to, means we *can*
come to a consensus.
This community covers a wide range of people, who i) consider costs at
different points on the timeline to be more or less important, ii) embody very
different engineering philosophies (and the professional experiences and
training which drive these philosophies), iii) have different goals and
viewpoints, etc, etc, etc. We may have the facts in common, but the systems in
which we evaluate them and weigh them are varied, hence, there is no reason
to expect consensus (and a lot of reason to expect disagreement :-).
as a result, we are not working on technical issues at this point
Again, I don't think so. Given the differences above, it is entirely
understandable that different people are coming up with different designs, and
it's not just for personal reasons. E.g. Steve Deering and I disagree over
some SIP design decisions not just because we sometimes (often? :-) irritate
each other personally. There are real differences of technical design
philosophy.
I propose that we focus ... on getting a solution that will coexist well
without requiring a gateway or major host/application changes to do so. I
would suggest that we *ignore* the effect on the routers other than...
See? From your viewpoint, you think minimizing the impact on hosts is
paramount... and on it goes.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12481;
5 Aug 93 14:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12471;
5 Aug 93 14:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17049;
5 Aug 93 14:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12459;
5 Aug 93 14:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12400;
5 Aug 93 14:16 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa16983;
5 Aug 93 14:16 EDT
Received: by ginger.lcs.mit.edu
id AA09812; Thu, 5 Aug 93 14:17:22 -0400
Date: Thu, 5 Aug 93 14:17:22 -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: <9308051817.AA09812 at ginger.lcs.mit.edu>
To: 0003858921 at mcimail.com, ietf at CNRI.Reston.VA.US
Subject: Re: What is 'Openess'?
Cc: jnc at ginger.lcs.mit.edu
fortunately, we have just about eliminated DECNet as a protocol here, one
down and...
See? The free market in protocols in action. And while you were getting rid of
DECNet, you a) didn't have to maintain completely separate DECnet switches and
transmission facilities, b) as you converted hosts, they were already attached
to a switching fabric which supported the new protocol, easing the conversion,
c) to the extent that you were scraping by on application gateways, you didn't
need special communications links to support them, just plugged them in
anywhere in the multi-protocol backbone, etc, etc.
You guys aren't remembering the world *before* multi-protocol routers and
backbones. It was *painful*!
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12513;
5 Aug 93 14:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12503;
5 Aug 93 14:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17069;
5 Aug 93 14:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12490;
5 Aug 93 14:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12425;
5 Aug 93 14:17 EDT
Received: from pooh.cc.iastate.edu by CNRI.Reston.VA.US id aa17013;
5 Aug 93 14:17 EDT
Received: by iastate.edu with sendmail-5.57/4.7
id <AA00488 at iastate.edu>; Thu, 5 Aug 93 13:18:00 -0500
Message-Id: <9308051818.AA00488 at iastate.edu>
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of Thu, 05 Aug 93 13:36:33 -0400.
<9308051736.AA09522 at ginger.lcs.mit.edu>
Date: Thu, 05 Aug 93 13:17:59 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>
>Allowing the market to choose sounds inefficent, but think back: what cost the
>most in the ISO/TCP-IP, SNMP/CMOT, OSPF/IS-IS battles; the political fighting,
>or the marketplace deciding? Multi-protocol support is the most efficient,
>and least painfully political way, of letting the market decide.
Yes, but if you let the market decide you may not like the choice.
Let us imagine that IETF comes forward with three proposals:
IPtng', IPtng'', and IPtng''', and says "let the market decide!".
I have a very strong feeling that the market will decide to
stick with IPtos (ignoring all this "doom saying" about running
out of addresses and routing capacity) right up until the moment
things look really dire.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13642;
5 Aug 93 14:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13632;
5 Aug 93 14:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18416;
5 Aug 93 14:55 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13621;
5 Aug 93 14:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13549;
5 Aug 93 14:54 EDT
Received: from shiva1.cac.washington.edu by CNRI.Reston.VA.US id aa18359;
5 Aug 93 14:54 EDT
Received: by shiva1.cac.washington.edu
(5.65/UW-NDC Revision: 2.28 ) id AA29308; Thu, 5 Aug 93 11:54:36 -0700
Date: Thu, 5 Aug 1993 11:49:46 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Terry Gray <gray at cac.washington.edu>
X-Orig-Sender: Terry Gray <gray at cac.washington.edu>
Reply-To: Terry Gray <gray at cac.washington.edu>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <9308051736.AA09522 at ginger.lcs.mit.edu>
Message-Id: <Pine.3.84.9308051146.E27607-0100000 at shiva1.cac.washington.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
On Thu, 5 Aug 1993, Noel Chiappa wrote:
> "The grass is always greener on the other side." From where you sit, in the
> middle of this confusion, it may seem worse, but I assure you that if you were
> locked into a lobotomized protocol, the multi-protocol model would seem not so
> bad. Would I prefer that the entire network share a single internetworking
> layer? Absolutely. Do I see multi-protocol support as the *least painful way*
> of getting to that future. Also true.
Noel,
I was assuming competition between reasonably competent technical
alternatives... I certainly wouldn't want my single-protocol arguments to
be used in defense of worldwide netbeui or appletalk!
That protocol evolution is necessary, and that such evolution is
inevitably painful, I accept (presumably along with everyone else on this
list).
Where we may differ is that I distinguish between (1) coexistence of two
protocols during a (possibly long) transition period, and (2) defining
multiprotocol support as a *feature* of the Internet.
Case (1) I take as a practical necessity; case (2) is what concerns me...
it tends to encourage the formation of non-interoperable islands that will
ever be thus, with little hope of convergence.
In other words, if we don't make protocol convergence an explict goal of
the Internet, it is less likely to happen --to the detriment of all.
Accordingly, I view decisions (or lack of decisions) that explicitly or
tacitly support Multiprotocolism at layer 3 as a Bad Thing.
> Allowing the market to choose sounds inefficent, but think back: what cost the
> most in the ISO/TCP-IP, SNMP/CMOT, OSPF/IS-IS battles; the political fighting,
> or the marketplace deciding? Multi-protocol support is the most efficient,
> and least painfully political way, of letting the market decide.
I disagree, except for the "least painfully political" part. The
political fighting in the cases you cite affected a relatively small
number people, compared to the number of system managers, much less the
number of users. Whereas, the hidden (and not so hidden) costs of the
marketplace deciding among competing *network* technologies have had
significant negative impact on end-users, EVEN those at sites that made
all the "right" technology decisions. This is because of a basic law of
computer thermodynamics: if a vendor must split resources across multiple
technologies, they won't be able to do as good a job on any one of them,
and the cost to users who need only one will generally be higher.
-teg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13964;
5 Aug 93 15:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13954;
5 Aug 93 15:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18754;
5 Aug 93 15:04 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13942;
5 Aug 93 15:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13903;
5 Aug 93 15:03 EDT
Received: from sadye.emba.uvm.edu by CNRI.Reston.VA.US id aa18717;
5 Aug 93 15:03 EDT
Received: by sadye.emba.uvm.edu id AA13821
(5.65/1.23); Thu, 5 Aug 93 15:02:08 -0400
Date: Thu, 5 Aug 93 15:02:08 -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: <9308051902.AA13821 at sadye.emba.uvm.edu>
To: "Robert G. Moskowitz" <0003858921 at mcimail.com>
Cc: ietf <ietf at CNRI.Reston.VA.US>
Subject: Another requirement for IPng
In-Reply-To: <73930805161537/0003858921NA1EM at mcimail.com>
References: <73930805161537/0003858921NA1EM at mcimail.com>
<<On Thu, 5 Aug 93 16:15 GMT, "Robert G. Moskowitz" <0003858921 at mcimail.com> said:
> I just had a terrible image pass my vision: IPlg or last generation.
Thanks, Robert, for expressing something that I have been concerned
about but haven't figured out how to express.
I believe that the current requirements documents express certain
requirements that are much smaller than what they would be. I believe
that, if IPng makes any significant impact on the marketplace, then we
really need to be developing a protocol that will last not for ten
years, not for twenty years, but more like forth to eighty years.
(Seriously!) If anyone out there things we have an Installed Base
Problem now, imagine what it will be like in twenty years or so at the
end of some of these proposals' design lifetimes. If the ToasterNet
scenario comes even moderately close to reality, then we had better be
designing something that can last as long as the current telephone
system has. (``What do you mean I can't program my microwave from my
TV remote?'')
> Here we are, 'fixing' FTP so it can handle bigger addresses. How big is big
> enough? What other variants on big addresses are possible?
I haven't read the new FTP document, but I hope that it is written in
such a way as to not place /any/ arbitrary limits on the length of an
``address'' for the PORT command. (Quite frankly, I'd be much happier
if it just used a DNS name, so that we wouldn't have to worry about
it.)
-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 aa14115;
5 Aug 93 15:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14103;
5 Aug 93 15:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18958;
5 Aug 93 15:07 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14093;
5 Aug 93 15:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14022;
5 Aug 93 15:06 EDT
Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa18866;
5 Aug 93 15:06 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ag00528;
5 Aug 93 18:57 GMT
Date: Thu, 5 Aug 93 19:01 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
To: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: What is 'Openess'?
Message-Id: <74930805190147/0003858921NA1EM at mcimail.com>
Noel said:
>You guys aren't remembering the world *before* multi-protocol routers and
>backbones. It was *painful*!
WHO SAYS I don't 'remember'?
SNA is its own network. The DECNet was its own network. It was easier to
keep the old stuff running as we converted, rather than get it on a common
backbone then convert.
Our multi-protocol routers hand IP and IPX...
And the handling of IPX is very recent. Just a little over a year ago, it
was going over its own bridged links.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14143;
5 Aug 93 15:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14132;
5 Aug 93 15:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18966;
5 Aug 93 15:07 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14105;
5 Aug 93 15:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14028;
5 Aug 93 15:06 EDT
Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa18871;
5 Aug 93 15:06 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ai00528;
5 Aug 93 18:57 GMT
Date: Thu, 5 Aug 93 19:01 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Another requirement for IPng
Message-Id: <85930805190158/0003858921NA1EM at mcimail.com>
John Hascall Said:
> Just consider it getting even for the b*st*rds who mixed
> U.S. and Metric fasteners on our cars... ;-)
Then consider this. When the Metric standard was introduced, there was no
compeling reason to switch from the English standard. So what evolved was 2
standards 'co-existing', making every mechanic and engineer's life
miserable.
Is that what you want with IPng????
Robert Moskowitz
MIS Tech Support
Chrysler Corp
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14538;
5 Aug 93 15:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14520;
5 Aug 93 15:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19444;
5 Aug 93 15:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14498;
5 Aug 93 15:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14430;
5 Aug 93 15:16 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa19358; 5 Aug 93 15:16 EDT
Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA04906 for ietf at cnri.reston.va.us; Thu, 5 Aug 93 15:17:23 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA22419; Thu, 5 Aug 93 12:15:42 PDT
Message-Id: <9308051915.AA22419 at aland.bbn.com>
To: John Hascall <john at iastate.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
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: Thu, 05 Aug 93 12:15:42 -0700
X-Orig-Sender: craig at aland.bbn.com
> Let us imagine that IETF comes forward with three proposals:
> IPtng', IPtng'', and IPtng''', and says "let the market decide!".
>
> I have a very strong feeling that the market will decide to
> stick with IPtos (ignoring all this "doom saying" about running
> out of addresses and routing capacity) right up until the moment
> things look really dire.
John:
I think you're right, unless the proposed IPtng has new services that
make it appealing.
In general folks don't change products unless the new product has
something important to them that the old product does not. If the only
difference is the new IP works well on bigger networks, well folks won't
change til the network gets big enough that this feature matters.
But if the new IP say, has support for flows, so those MBONE conferences
look nice and internet multicasting and maybe anycasting (so you can say
"telnet archie.net" and get connected to the nearest archie server) then
maybe folks will shift to the new protocol earlier.
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15887;
5 Aug 93 16:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15877;
5 Aug 93 16:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22213;
5 Aug 93 16:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15867;
5 Aug 93 16:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15834;
5 Aug 93 16:22 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa22188;
5 Aug 93 16:22 EDT
Received: by ginger.lcs.mit.edu
id AA14329; Thu, 5 Aug 93 16:23:04 -0400
Date: Thu, 5 Aug 93 16:23: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: <9308052023.AA14329 at ginger.lcs.mit.edu>
To: gray at cac.washington.edu, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: jnc at ginger.lcs.mit.edu
(2) defining multiprotocol support as a *feature* of the Internet. ...
case (2) is what concerns me... it tends to encourage the formation of
non-interoperable islands that will ever be thus, with little hope of
convergence. In other words, if we don't make protocol convergence an
explict goal of the Internet, it is less likely to happen --to the
detriment of all.
The "laws of nature/economics" will inevitably get rid of those islands,
though. They can't communicate as well, so are less efficient at competing
than the ones that can. The stuff they are running has a smaller user base and
market share, so less resources are available to improve it, and it falls
behind technically. Etc, etc.
I seem to recall reading somewhere that one human language is going extinct
every <short-period>, and I note that even though the IETF is a *somewhat*
international body, we all communicate in English...
You don't need to try and *legislate* protocol convergence, and in fact it may
be faster not to. Would English be as prevalent as it is if the UN had to
debate which language to pick for everyone to use in common, and tried to
force its adoption? Can you say "backlash"? Time is mightier than the sword,
and patience will get you things action won't.
> Multi-protocol support is the most efficient, and least painfully
> political way, of letting the market decide.
I disagree, except for the "least painfully political" part. ... the
hidden ... costs of the marketplace deciding among competing *network*
technologies have had significant negative impact on end-users
First, I said that it was "the most efficient way ... of letting the market
decide." Multi-protocol networking assumes that the decision is made by the
market, and tries to minimize pain during that process.
You are really complaining about the costs of having the market make the
decision, and I agree, they are substantial. I cannot prove to you that
letting the market decide is the way to go, and any debate about that could
start a big Poli-Sci debate about anarchy versus the role of government, so
I'll pass!
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17654;
5 Aug 93 17:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17642;
5 Aug 93 17:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24388;
5 Aug 93 17:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17623;
5 Aug 93 17:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17555;
5 Aug 93 17:17 EDT
Received: from munin.fnal.gov by CNRI.Reston.VA.US id aa24299;
5 Aug 93 17:17 EDT
Received: from LOCALHOST.fnal.gov by munin.fnal.gov with SMTP id AA06776
(5.65c+/IDA-1.4.4 for ietf at cnri.reston.va.us); Thu, 5 Aug 1993 16:17:33 -0500
Message-Id: <199308052117.AA06776 at munin.fnal.gov>
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of Thu, 05 Aug 93 16:23:04 EDT.
<9308052023.AA14329 at ginger.lcs.mit.edu>
Date: Thu, 05 Aug 93 16:17:33 -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>
> I seem to recall reading somewhere that one human language is going extinct
> every <short-period>,
On the other hand, there are more native speakers of Mayan today than
there are Esperanto speakers. (Native or otherwise :-). I think
that's a (slightly) relevant analogy.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17720;
5 Aug 93 17:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17710;
5 Aug 93 17:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa24434;
5 Aug 93 17:20 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17700;
5 Aug 93 17:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17604;
5 Aug 93 17:18 EDT
Received: from watson.ibm.com by CNRI.Reston.VA.US id aa24377;
5 Aug 93 17:18 EDT
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2913;
Thu, 05 Aug 93 17:19:28 EDT
Date: Thu, 5 Aug 93 17:19:28 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: yakov at watson.ibm.com
To: craig at aland.bbn.com, john at iastate.edu
cc: ietf at CNRI.Reston.VA.US
Subject: Last Call: Use of ISO CLNP in TUBA
Message-ID: <9308051718.aa24377 at CNRI.Reston.VA.US>
Ref: Your note of Thu, 05 Aug 93 12:15:42 -0700
>But if the new IP say, has support for flows, so those MBONE look
>nice and internet multicasting and maybe anycasting, then may be
>folks will shift to the new protocol earlier.
Craig,
And what would happen if IPv4 would support flows, and multicasting,
and mobility, and autoconfiguration ?
Yakov.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18397;
5 Aug 93 18:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18385;
5 Aug 93 18:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25855;
5 Aug 93 18:01 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18374;
5 Aug 93 18:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18322;
5 Aug 93 18:00 EDT
Received: from sadye.emba.uvm.edu by CNRI.Reston.VA.US id aa25713;
5 Aug 93 18:00 EDT
Received: by sadye.emba.uvm.edu id AA17528
(5.65/1.23); Thu, 5 Aug 93 18:00:12 -0400
Date: Thu, 5 Aug 93 18:00:12 -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: <9308052200.AA17528 at sadye.emba.uvm.edu>
To: yakov at watson.ibm.com
Cc: craig at aland.bbn.com, ietf at CNRI.Reston.VA.US, john at iastate.edu
Subject: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: <9308051718.aa24377 at CNRI.Reston.VA.US>
References: <9308051718.aa24377 at CNRI.Reston.VA.US>
<<On Thu, 5 Aug 93 17:19:28 EDT, yakov at watson.ibm.com said:
> Craig,
> And what would happen if IPv4 would support flows, and multicasting,
> and mobility, and autoconfiguration ?
Yakov,
It doesn't, and I for one don't think it can be reasonably twisted to
make it.
--
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 aa19366;
5 Aug 93 19:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19356;
5 Aug 93 19:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27920;
5 Aug 93 19:12 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19342;
5 Aug 93 19:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19284;
5 Aug 93 19:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27800;
5 Aug 93 19:10 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa19279;
5 Aug 93 19:10 EDT
To: Christian Huitema <Christian.Huitema at sophia.inria.fr>
cc: "Robert G. Moskowitz" <0003858921 at mcimail.com>,
ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-reply-to: Your message of "Wed, 04 Aug 93 14:39:43 +0200."
<199308041239.AA11725 at mitsou.inria.fr>
Date: Thu, 05 Aug 93 19:10:11 -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: <9308051910.aa19279 at IETF.CNRI.Reston.VA.US>
Christian,
uh, not that I am incapable of being pretty stubborn, but phrases
like "over my dead body" are open invitations to predict the future
by, well, making it happen...
In any event, I continue to feel strongly that we still have much to
do to assess our options with regard to IPng and that one wishes to
achieve maximum benefit where possible, considering the wrenching
difficulty of deploying a parallel IP layer protocol for some possibly
protracted period of time.
Vint
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19599;
5 Aug 93 19:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19589;
5 Aug 93 19:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28547;
5 Aug 93 19:28 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19579;
5 Aug 93 19:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19555;
5 Aug 93 19:26 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa28492; 5 Aug 93 19:26 EDT
Received: from port14.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA05929 for ietf at CNRI.Reston.VA.US; Thu, 5 Aug 93 19:27:29 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA23493; Thu, 5 Aug 93 16:25:50 PDT
Message-Id: <9308052325.AA23493 at aland.bbn.com>
To: yakov at watson.ibm.com
Cc: craig at aland.bbn.com, john at iastate.edu
Cc: ietf at CNRI.Reston.VA.US
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: Thu, 05 Aug 93 16:25:50 -0700
X-Orig-Sender: craig at aland.bbn.com
>>But if the new IP say, has support for flows, so those MBONE look
>>nice and internet multicasting and maybe anycasting, then may be
>>folks will shift to the new protocol earlier.
>
> And what would happen if IPv4 would support flows, and multicasting,
> and mobility, and autoconfiguration ?
Then everyone will use IPv4 until it collapses.
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19673;
5 Aug 93 19:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19663;
5 Aug 93 19:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28705;
5 Aug 93 19:31 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19647;
5 Aug 93 19:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19609;
5 Aug 93 19:30 EDT
Received: from gibbs.oit.unc.edu by CNRI.Reston.VA.US id aa28638;
5 Aug 93 19:30 EDT
Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1)
id AA10288; Thu, 5 Aug 93 19:30:42 -0400
Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1)
id AA08454; Thu, 5 Aug 93 19:33:01 EDT
Message-Id: <9308052333.AA08454 at tipper>
X-Really-To: gibbs.oit.unc.edu
To: wollman at uvm-gen.emba.uvm.edu
Cc: "Robert G. Moskowitz" <0003858921 at mcimail.com>,
ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Another requirement for IPng
In-Reply-To: Your message of "Thu, 05 Aug 93 15:02:08 EDT."
<9308051902.AA13821 at sadye.emba.uvm.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 05 Aug 93 19:33:00 -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>
This brings up a question which I've had in my mind for a while; what sort of
resources do each of the IP-TNG contenders require for the simplest hosts
(single point-to-point connection). We're looking to port IP to a small
household computer; how many of the TNG contenders would be happy operating
in a system with only a 64K data space? In this case, code size isn't as
important, but is still a concern.
Still on the subject of IPng (barely)... does anyone have a summary of
what extra demands the contenders will place on the DNS? I'm currently playing
around with the idea of DNS++, and I'd like to work the IPNGs into the design.
Simon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20817;
5 Aug 93 22:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20805;
5 Aug 93 22:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02289;
5 Aug 93 22:20 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20794;
5 Aug 93 22:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20749;
5 Aug 93 22:18 EDT
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa02223;
5 Aug 93 22:18 EDT
Received: by interlock.ans.net id AA10622
(InterLock SMTP Gateway 1.1 for ietf at CNRI.Reston.VA.US);
Thu, 5 Aug 1993 22:14:24 -0400
Received: by interlock.ans.net (Internal Mail Agent-1);
Thu, 5 Aug 1993 22:14:24 -0400
Message-Id: <199308060214.AA12522 at home.ans.net>
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: RFC1498 on On the Naming and Binding of Network Destinations
In-Reply-To: (Your message of Wed, 04 Aug 93 21:55:39 D.)
<9308050155.AA06546 at ginger.lcs.mit.edu>
Date: Thu, 05 Aug 93 22:14:23 -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>
This is the first of (hopefully :-) a series of key networking papers
that I am going to try to make avilable online, as Informational RFC's, for
the benfit of the community.
Noel,
Thank you for taking the trouble to make this important paper available.
(I thought I was caught in a time warp when I read the announcement!)
This is indeed a benefit for the community. Can't wait for the rest of
the Chiappa Memorial Networking Series. :)
Phill
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02754;
6 Aug 93 9:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02744;
6 Aug 93 9:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09141;
6 Aug 93 9:10 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02731;
6 Aug 93 9:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02621;
6 Aug 93 9:01 EDT
Received: from watson.ibm.com by CNRI.Reston.VA.US id aa08835; 6 Aug 93 9:01 EDT
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7341;
Fri, 06 Aug 93 09:02:07 EDT
Date: Fri, 6 Aug 93 09:02:07 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: yakov at watson.ibm.com
To: wollman at uvm-gen.emba.uvm.edu
cc: craig at aland.bbn.com, ietf at CNRI.Reston.VA.US, john at iastate.edu
Subject: Last Call: Use of ISO CLNP in TUBA
Message-ID: <9308060901.aa08835 at CNRI.Reston.VA.US>
Ref: Your note of Thu, 5 Aug 93 18:00:12 -0400
>> And what would happen if IPv4 would support flow, and multicasting,
>> and mobility, and autoconfiguration ?
>
>Yakov,
>It doesn't, and I for one don't think it can be reasonably twisted
>to make it.
Garrett,
To find out whether support for flow can be put in IPv4 I asked
Deborah Estrin (since she is one of the authors of RSVP). She assured
me that RSVP *can* be supported in IPv4.
To find out whether multicast can be supported in IPv4 just look
at the work that IDMR WG is doing now. Also look at MBONE and MOSPF.
All their work is in the context of IPv4.
With respect to mobility, I can assure you that mobility
can be supported in IPv4, In fact, mobile-ip WG has at least half a dozen
of different proposals on how to do this.
With respect to autoconfiguration, look at DHCP. Seems that it will
do the job for IPv4.
To sum things up, I think we have an existence proof that while
may not IPv4 support all the above features *today*, we are in the process
of incorporating all these features in *IPv4*, so that IPv4 *can*
"be twisted to make it". And that brings me to Craig's
reply to my e-mail: "Then everyone will use IPv4 until it collapses."
So, the question is: What constitues IPv4 collapse ?
Yakov.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02956;
6 Aug 93 9:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02946;
6 Aug 93 9:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09420;
6 Aug 93 9:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02936;
6 Aug 93 9:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02887;
6 Aug 93 9:20 EDT
Received: from pooh.cc.iastate.edu by CNRI.Reston.VA.US id aa09320;
6 Aug 93 9:20 EDT
Received: by iastate.edu with sendmail-5.57/4.7
id <AA02230 at iastate.edu>; Fri, 6 Aug 93 08:21:37 -0500
Message-Id: <9308061321.AA02230 at iastate.edu>
To: yakov at watson.ibm.com
Cc: wollman at uvm-gen.emba.uvm.edu, craig at aland.bbn.com,
ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of Fri, 06 Aug 93 09:02:07 -0400.
<9308061302.AA08627 at vs-2.iastate.edu>
Date: Fri, 06 Aug 93 08:21:36 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>
> >> And what would happen if IPv4 would support flow, and multicasting,
> >> and mobility, and autoconfiguration ?
> >Yakov,
> >It doesn't, and I for one don't think it can be reasonably twisted
> >to make it.
> Garrett,
[...RSVP, MBONE, mobile-ip WG, DHCP...]
> To sum things up, I think we have an existence proof that while
> may not IPv4 support all the above features *today*, we are in the process
> of incorporating all these features in *IPv4*, so that IPv4 *can*
> "be twisted to make it". And that brings me to Craig's
> reply to my e-mail: "Then everyone will use IPv4 until it collapses."
> So, the question is: What constitues IPv4 collapse ?
I think there is a vast difference between it being possible for
a bunch of people working very hard to discover a way to do
something in IPv4 and having something be "supported in IPv4".
One important, (IMHO), part of IPtng should be having these
important things (where "important" is suitably defined ;-)
standardized at the start of IPtng so that they actually
get implemented in (most/all) implementations.
Take the telnet options, for example (I happen to be familiar
with these). There are lots of good ideas there, yet look
how many of them are actually implemented widely even many
years after they were defined (even though many of them are
only a handful of lines of code). For example: NAWS and
XDISPLAY_LOC make telnet much nicer in a windowed environment.
Similarly, in my experience, the IP options are sparsely implemented.
John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03845;
6 Aug 93 10:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03835;
6 Aug 93 10:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11396;
6 Aug 93 10:05 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03825;
6 Aug 93 10:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03719;
6 Aug 93 10:02 EDT
Received: from bells.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa11281;
6 Aug 93 10:02 EDT
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.17452-0 at bells.cs.ucl.ac.uk>; Fri, 6 Aug 1993 15:01:39 +0100
To: John Hascall <john at iastate.edu>
cc: yakov at watson.ibm.com, wollman at uvm-gen.emba.uvm.edu, craig at aland.bbn.com,
ietf at CNRI.Reston.VA.US, J.Crowcroft at cs.ucl.ac.uk
Subject: Re: was Last Call: ...what you can and can't do in IPv4
In-reply-to: Your message of "Fri, 06 Aug 93 08:21:36 CDT." <9308061321.AA02230 at iastate.edu>
Date: Fri, 06 Aug 93 15:01:28 +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: <9308061002.aa11281 at CNRI.Reston.VA.US>
> I think there is a vast difference between it being possible for
> a bunch of people working very hard to discover a way to do
> something in IPv4 and having something be "supported in IPv4".
I agree:
how about admitting that you cannot do flows multicast or mobility
_efficiently_ in ipv4.
steve deering might have something to say about the mbone telling us
about what not to do rather than what to do...
i don't buy the stuff about flows (until we've got it working, then
i'll let you know how it scales).
as for mobility, when i see it tried on any scale, i'll believe it...
at the moment, i believe we have trial solutions for the above which
have _less_ scalability that ipv4 itself, so cannot easily technology
transfer into ipng proposals yet...soon, but not quite yet.
[of course, i m not a disinterentested part i nsaying that!)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04383;
6 Aug 93 10:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04377;
6 Aug 93 10:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12124;
6 Aug 93 10:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04363;
6 Aug 93 10:34 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04359;
6 Aug 93 10:34 EDT
To: IETF-Announce: ;
Cc: Jon Postel -- RFC Editor <postel at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: ietf-osi-x400ops at cs.wisc.edu
Cc: The Internet Engineering Steering Group <IESG at IETF.CNRI.Reston.VA.US>
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: Protocol Action: X.400 use of extended character sets to
Proposed Standard
Date: Fri, 06 Aug 93 10:34:46 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308061034.aa04359 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet Draft "X.400 use of extended
character sets" <draft-ietf-x400ops-charactersets-03.txt> as a
Proposed Standard. This document is the product of the X.400
Operations Working Group. The IESG contact persons are John
Klensin and Erik Huizer.
Technical Summary
This document tries to describe the usage of the GeneralText body
part in X.400 (1988), in a way that will make it possible to
implement and deploy user agents for multiple languages and
character sets using this facility.
Working Group Summary
The working groups to which this item has been presented (RARE
WG-MSG, RARE WG-CHAR, IETF X400-OSI-OPS) generally thought that
such a document would be useful to the community, and had no
significant disagreements with the technical details.
Protocol Quality
The work has been reviewed by the Application Area Directorate.
There are no implementations yet.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab05374;
6 Aug 93 11:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05364;
6 Aug 93 11:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13766;
6 Aug 93 11:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05354;
6 Aug 93 11:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05305;
6 Aug 93 11:17 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa13678;
6 Aug 93 11:17 EDT
Received: by ginger.lcs.mit.edu
id AA18455; Fri, 6 Aug 93 11:17:00 -0400
Date: Fri, 6 Aug 93 11:17:00 -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: <9308061517.AA18455 at ginger.lcs.mit.edu>
To: wollman at uvm-gen.emba.uvm.edu, yakov at watson.ibm.com
Subject: IPv4 collapse
Cc: craig at aland.bbn.com, ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
So, the question is: What constitues IPv4 collapse?
I'm not sure there will be a single day when IPv4 breaks. Whenever something
goes wrong, "more thrust" (hi Milo, wherever you are :-) will be applied.
This has happened over and over already: 8-bit network numbers -> A/B/C,
subnets, CIDR; GGP->EGP->BGP; etc.
When we run out of new IPv4 addresses to allocate, there will be a mad
scramble to recycle unused ones. When we've run out of those, we'll switch to
interpreting it as an EID to allow use of all the odd ones lying around. When
we have used all those, we'll figure out how to do NAT. Etc, etc, etc.
Eventually, the thrust/benfit ratio will be so bad, and new things will have
so many new features you can't kludge into IPv4, that individuals will start
to give up and move on to something with a better ratio (while keeping their
toe in the water on the old IPv4 for universal connectivity), but it'll happen
gradually.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05464;
6 Aug 93 11:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05454;
6 Aug 93 11:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13841;
6 Aug 93 11:22 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05443;
6 Aug 93 11:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05399;
6 Aug 93 11:20 EDT
Received: from OERV01.er.doe.gov by CNRI.Reston.VA.US id aa13779;
6 Aug 93 11:20 EDT
Received: by er.doe.gov (5.57/OER-V1.0)
id AA07498; Fri, 6 Aug 93 11:18:03 -0400
Date: Fri, 6 Aug 93 11:18:03 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dan Hitchcock <hitchcoc at oerv01.er.doe.gov>
Message-Id: <9308061518.AA07498 at er.doe.gov>
To: 0003858921 at mcimail.com, deering at parc.xerox.com
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: ietf at CNRI.Reston.VA.US
Interoperability is of course a multi faceted thing...
If the DNS knew for example which hosts spoke IPv4, CLNP,... etc
and if TCP and UDP ran on top of all those stacks, then a smart
multiprotocol host would in principle be able to NFS mount a CLNP
host, send e-mail to SMTP and CLNP hosts, and AFS mount an IPv4 host
without the user caring.
So the TUBA spec could promote interoperability at the applications layer
in an environment which is fragmented at the network layer. This sort
of thing is probably required for transition anyway and having this spec
out there so we could experiment with "smart" multiprotocol hosts might be
valuable even if CLNP were to vanish in a year or two.
DH
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05546;
6 Aug 93 11:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05542;
6 Aug 93 11:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13870;
6 Aug 93 11:24 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05533;
6 Aug 93 11:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05529;
6 Aug 93 11:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13865;
6 Aug 93 11:24 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05524;
6 Aug 93 11:24 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
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: Interactive Mail Access Protocol - Version 3 to
Historic
Date: Fri, 06 Aug 93 11:23:59 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308061124.aa05524 at IETF.CNRI.Reston.VA.US>
The IESG is considering reclassifying RFC1203 ("Interactive Mail
Access Protocol, Version 3") from Experimental to Historic status.
This RFC was one of two proposals created to update and supercede
RFC1064. The other proposal, RFC1176, has been much more widely
implemented, and is being used as the basis for an IETF working
group to further extend and refine IMAP. Some of the extensions
proposed in RFC1203 have already been incorporated into the
evolutionary path of RFC1176.
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 20 August.
John Stewart
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06166;
6 Aug 93 11:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06156;
6 Aug 93 11:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14539;
6 Aug 93 11:43 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06146;
6 Aug 93 11:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05988;
6 Aug 93 11:40 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa14465;
6 Aug 93 11:40 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA11180; Fri, 6 Aug 93 08:41:04 -0700
Message-Id: <9308061541.AA11180 at Mordor.Stanford.EDU>
To: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: was Last Call: ...what you can and can't do in IPv4
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Fri, 06 Aug 93 15:01:28 +0100. <9308061002.aa11281 at CNRI.Reston.VA.US>
Date: Fri, 06 Aug 93 08:41:04 -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
Concerning 'mobility': I consider the continuing rate of proposals being
made to the IP mobility wg to be an indication that we either don't
really know how to solve it or, worse, that we aren't yet sure what we
are solving. Hence, we can't know whether we can use IPv4 (or any of
the contenders) to accomplish the task(s).
The plural on task is in case there really are multiple kinds of
mobility, such as within-building versus across-country.
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06693;
6 Aug 93 12:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06682;
6 Aug 93 12:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15830;
6 Aug 93 12:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06671;
6 Aug 93 12:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06595;
6 Aug 93 12:15 EDT
Received: from sayshell.umd.edu by CNRI.Reston.VA.US id aa15741;
6 Aug 93 12:15 EDT
Received: from localhost by sayshell.umd.edu (NX5.67c/NeXT-1.0)
id AA29232; Fri, 6 Aug 93 12:15:35 -0400
Message-Id: <9308061615.AA29232 at sayshell.umd.edu>
To: Dan Hitchcock <hitchcoc at oerv01.er.doe.gov>
Cc: 0003858921 at mcimail.com, deering at parc.xerox.com, ietf at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Louis A. Mamakos" <louie at ni.umd.edu>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of "Fri, 06 Aug 1993 11:18:03 EDT."
<9308061518.AA07498 at er.doe.gov>
Date: Fri, 06 Aug 1993 12:15:34 -0400
X-Orig-Sender: louie at sayshell.umd.edu
> Interoperability is of course a multi faceted thing...
> If the DNS knew for example which hosts spoke IPv4, CLNP,... etc
> and if TCP and UDP ran on top of all those stacks, then a smart
> multiprotocol host would in principle be able to NFS mount a CLNP
> host, send e-mail to SMTP and CLNP hosts, and AFS mount an IPv4 host
> without the user caring.
Interestingly, the user API on various UNIX boxes have the ability to
return a protocol-type identifier (look at what gethostbyname()
returns and what a struct hostent returns). But no one has bothered
to take advantage of this, likely because of the "universal"
connectivity offered by the IP stack.
> So the TUBA spec could promote interoperability at the applications layer
> in an environment which is fragmented at the network layer. This sort
> of thing is probably required for transition anyway and having this spec
> out there so we could experiment with "smart" multiprotocol hosts might be
> valuable even if CLNP were to vanish in a year or two.
I don't see how this follows. How does my IP-stack-only NeXT
workstation NFS mount a file system off of a CLNP server host? It is
not all all clear to me that similar application level protocols over
incompatible network layer protocols do anything other than confuse
the end-user.
Then again, I've never had any demand for CLNP from my 6000 host
network here at the College Park campus of the University of Maryland,
so perhaps I'm missing something. Sure, to be politically correct a
few years ago, we speced CLNP capability in our router procurement,
but that feature has never been configured. Am I being counted as
part of the "installed CLNP user base?"
Louis Mamakos
Network Infrastructure
University of Maryland at College Park
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07657;
6 Aug 93 13:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07647;
6 Aug 93 13:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00943;
6 Aug 93 13:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id ab07532;
6 Aug 93 13:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07492;
6 Aug 93 13:27 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa17826;
6 Aug 93 13:27 EDT
Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-12)
id <AA19447>; Fri, 6 Aug 1993 10:28:10 -0700
Date: Fri, 6 Aug 1993 10:28:16 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: braden at isi.edu
Posted-Date: Fri, 6 Aug 1993 10:28:16 -0700
Message-Id: <199308061728.AA27550 at can.isi.edu>
Received: by can.isi.edu (5.65c/4.0.3-4)
id <AA27550>; Fri, 6 Aug 1993 10:28:16 -0700
To: yakov at watson.ibm.com, craig at aland.bbn.com
Subject: Internet growth models
Cc: ietf at CNRI.Reston.VA.US
*>
*> Then everyone will use IPv4 until it collapses.
*>
*> Craig
*>
Craig,
I can offer a model of the future that is not so pessimistic. The
question is: what is the nature of the Internet growth process? Is it
homogeneous random additions to the existing population, sort of like
cell growth or nuclear decay? In that case, I agree it may be
difficult to persuage people to convert to avoid gradual collapse.
Another model is that the exponential growth we see is composed of a
relatively small number of distinct populations, each of which takes
off at some time, expands rapidly and exponentially, and then more or
less saturates. In this model, the driving force for the continued
exponential growth that we fear will be entirely new application areas,
e.g., PC's running NT, or home appliances. We may expect that the
purveyors of these major new applications will look at their sales
projections, look at the remaining IPv4 address space, say "No way!",
and switch to IPng from the beginning. Due to the magic of exponential
growth, this will cause a rapid conversion of the Internet in terms of
percentage.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07785;
6 Aug 93 13:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07775;
6 Aug 93 13:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01577;
6 Aug 93 13:43 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07764;
6 Aug 93 13:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07724;
6 Aug 93 13:42 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa01523; 6 Aug 93 13:42 EDT
Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA02937 for ietf at cnri.reston.va.us; Fri, 6 Aug 93 13:42:51 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA27879; Fri, 6 Aug 93 10:41:11 PDT
Message-Id: <9308061741.AA27879 at aland.bbn.com>
To: Dan Hitchcock <hitchcoc at oerv01.er.doe.gov>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
Cc: ietf at CNRI.Reston.VA.US
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: Fri, 06 Aug 93 10:41:11 -0700
X-Orig-Sender: craig at aland.bbn.com
> Interoperability is of course a multi faceted thing...
> If the DNS knew for example which hosts spoke IPv4, CLNP,... etc
> and if TCP and UDP ran on top of all those stacks, then a smart
> multiprotocol host would in principle be able to NFS mount a CLNP
> host, send e-mail to SMTP and CLNP hosts, and AFS mount an IPv4 host
> without the user caring.
Actually, given the way DNS software currently integrates with most
applications, you'd need smart *applications*. The host can be multiprotocol
but unless all the applications are reprogrammed to be multiprotocol
it doesn't do any good. Most TCP/IP applications have hardwired into
them that they're to invoke TCP over IP.
There's a whole application infrastructure that needs to be rebuilt to
be multiprotocol. Now I'm in favor of trying to redo that interface to
be less hardwired to a particular protocol, because I think it eases
transitions to IPng. But I think the work required is large. (I still
remember all the pain of changing the BSD applications to accomodate the
DNS, and teaching them all that a host could have more than one address,
and that it was possible for a host-address routine to have a return value
of "ask again later" rather than just "yes host exists" and "no host doesn't
exist").
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07981;
6 Aug 93 13:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07971;
6 Aug 93 13:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02071;
6 Aug 93 13:53 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07960;
6 Aug 93 13:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07937;
6 Aug 93 13:52 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa02035; 6 Aug 93 13:52 EDT
Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA03827 for ietf at CNRI.Reston.VA.US; Fri, 6 Aug 93 13:52:42 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA28831; Fri, 6 Aug 93 10:51:02 PDT
Message-Id: <9308061751.AA28831 at aland.bbn.com>
To: braden at isi.edu
Cc: ietf at CNRI.Reston.VA.US
Subject: re: Internet growth models
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: Fri, 06 Aug 93 10:51:02 -0700
X-Orig-Sender: craig at aland.bbn.com
Bob:
I'd like to believe your scenario but I'm not convinced, for two reasons:
* a start up with a nifty new application is unlikely to want to develop
for IPng, when if we support what they need in IPv4, they get access
to an existing market several million hosts and users. Easier to
go where IP (the MS-DOS of networking) has gone than buy into something
new.
* I'd expect developers with deeper pockets to think more carefully about
future prospects but recent conversations with folks involved with
implementing the video-on-demand, etc., type services are apparently
going with IPv4 too...
Ain't conservatism wonderful :-(?
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08129;
6 Aug 93 13:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08114;
6 Aug 93 13:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02247;
6 Aug 93 13:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08100;
6 Aug 93 13:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08069;
6 Aug 93 13:55 EDT
Received: from xap.xyplex.com by CNRI.Reston.VA.US id aa02206;
6 Aug 93 13:55 EDT
Received: by xap.xyplex.com id <AA28008 at xap.xyplex.com>; Fri, 6 Aug 93 15:54:58 -0500
Date: Fri, 6 Aug 93 15:54:58 -0500
Message-Id: <9308062054.AA28008 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: "Louis A. Mamakos"'s message of Fri, 06 Aug 1993 12:15:34 -0400 <9308061615.AA29232 at sayshell.umd.edu>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
I'll probably regret this. Please flame me personally, and spare the
bandwidth.
>Sure, to be politically correct a
>few years ago, we speced CLNP capability in our router procurement,
>but that feature has never been configured.
Such political correctness is not without cost. Even if you don't use it,
you, and everyone else who buys routers, pay for the engineering time to
implement it, which might otherwise have been spent on a useful feature.
>Am I being counted as
>part of the "installed CLNP user base?"
Like most areas, government mandates of reality generally make life more
complex and more expensive, and make it harder to see reality. (Referring to
government-sanctioned standards and GOSIP, and their effect on political
correctness.)
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08190;
6 Aug 93 13:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08180;
6 Aug 93 13:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02410;
6 Aug 93 13:58 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08169;
6 Aug 93 13:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08115;
6 Aug 93 13:56 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa02253;
6 Aug 93 13:56 EDT
Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-12)
id <AA20345>; Fri, 6 Aug 1993 10:57:32 -0700
Date: Fri, 6 Aug 1993 10:57:38 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: braden at isi.edu
Posted-Date: Fri, 6 Aug 1993 10:57:38 -0700
Message-Id: <199308061757.AA27602 at can.isi.edu>
Received: by can.isi.edu (5.65c/4.0.3-4)
id <AA27602>; Fri, 6 Aug 1993 10:57:38 -0700
To: braden at isi.edu, craig at aland.bbn.com
Subject: re: Internet growth models
Cc: ietf at CNRI.Reston.VA.US
Craig,
At present, there ISN'T an IPng. I think that when there is an IPng
defined and accepted, self-interest will cause the hypothesized new
application purveyors to adopt it.
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08675;
6 Aug 93 14:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08665;
6 Aug 93 14:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04668;
6 Aug 93 14:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08652;
6 Aug 93 14:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08591;
6 Aug 93 14:16 EDT
Received: from watson.ibm.com by CNRI.Reston.VA.US id aa04454;
6 Aug 93 14:16 EDT
Received: from YKTVMH by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1551;
Fri, 06 Aug 93 14:17:24 EDT
Date: Fri, 6 Aug 93 14:17:11 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: perk at watson.ibm.com
To: dcrocker at mordor.stanford.edu
cc: ietf at CNRI.Reston.VA.US
Subject: Mobile-IP WG: ...what you can and can't do in IPv4
Message-ID: <9308061416.aa04454 at CNRI.Reston.VA.US>
Ref: Your note of Fri, 06 Aug 93 08:41:04 -0700
I actually believe the mobile-IP working group
knows what problem it is trying to solve. The
number of proposals before the group is more an
indication of a lack of true team spirit than
an indication of unfamiliarity with the problem
(my opinion only). Maybe some WG's have team
spirit, and others don't. After all, a lot of
professional career issues can be involved.
Regarding the suitability of IPv4 as a routing
protocol for mobility (again, my opinion only):
On the one hand, we want to use the IP address
as an endpoint identifier (the thing that sessions
use). On the other hand, we want to use the IP
address as a routing directive, and the routing
directive needs to change with time. These two
objectives obviously clash. To put some distance
between them is the job of the Mobile-IP WG.
However, I cannot see how any IPng proposal
could do any better until there is some more
thought given to separating endpoint identifiers
from routing directives.
Charlie P.
PS. Is any more work being done on improving/
revising the requirements for IPng?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09043;
6 Aug 93 14:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09033;
6 Aug 93 14:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05346;
6 Aug 93 14:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09022;
6 Aug 93 14:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08989;
6 Aug 93 14:33 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa05292; 6 Aug 93 14:33 EDT
Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA08455 for ietf at CNRI.Reston.VA.US; Fri, 6 Aug 93 14:34:12 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA28923; Fri, 6 Aug 93 11:32:32 PDT
Message-Id: <9308061832.AA28923 at aland.bbn.com>
To: braden at isi.edu
Subject: re: Internet growth models
Cc: ietf at CNRI.Reston.VA.US
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: Fri, 06 Aug 93 11:32:32 -0700
X-Orig-Sender: craig at aland.bbn.com
> At present, there ISN'T an IPng. I think that when there is an IPng
> defined and accepted, self-interest will cause the hypothesized new
> application purveyors to adopt it.
Bob:
Right, and I'm saying that unless IPng has some nifty features the market
cares deeply about the majority of purveyors won't adopt it.
Look at operating systems -- OS/2 was supposed to be the great successor
to MS-DOS (which most people feel is a toy operating system).
Remember that CMOT was supposed to be the long-term standard. CMOT
worked -- folks could demo it doing the same sorts of things SNMP did with
a MIB.
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09278;
6 Aug 93 14:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09266;
6 Aug 93 14:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05533;
6 Aug 93 14:43 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09252;
6 Aug 93 14:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09179;
6 Aug 93 14:42 EDT
Received: from lager.cisco.com by CNRI.Reston.VA.US id aa05499;
6 Aug 93 14:42 EDT
Received: by lager.cisco.com id AA23538
(5.67a/IDA-1.5 for ietf at CNRI.Reston.VA.US); Fri, 6 Aug 1993 11:43:03 -0700
Date: Fri, 6 Aug 1993 11:43:03 -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: <199308061843.AA23538 at lager.cisco.com>
To: ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: Use of ISO CLNP in TUBA
From: john at iastate.edu (John Hascall)
[...RSVP, MBONE, mobile-ip WG, DHCP...]
I think there is a vast difference between it being possible for
a bunch of people working very hard to discover a way to do
something in IPv4 and having something be "supported in IPv4".
I would appreciate it if you would illuminate me on the difference. I
agree that it would be better to have things designed into the
protocol stack than kludged on. Certainly having the design freedom
of changing the entire protocol stack is convenient when designing
such features, but do you really want to make use of this freedom?
Does the IPng protocol header have to change to support
autoconfiguration?
And you won't have this freedom forever, anyhow. What happens to the
next important feature where we have to "discover" a way to do
something with IPng? Do we go to IPng++ so that it's "supported"?
The point is that _ANY_ IPng contender must be sufficiently flexible
so that we can add to it _in flight_. IPv4 already has demonstrated
this flexibility for all of these additions.
My fear is that we will never be able to come up with an application
that can't be grafted onto IPv4. Thus, we follow Craig's path.
One important, (IMHO), part of IPtng should be having these
important things (where "important" is suitably defined ;-)
standardized at the start of IPtng so that they actually
get implemented in (most/all) implementations.
Standardizing something does not insure that it gets implemented.
Only usefulness does.
From: J.Crowcroft at cs.ucl.ac.uk (Jon Crowcroft)
how about admitting that you cannot do flows multicast or mobility
_efficiently_ in ipv4.
I, for one, will happily admit this. However, I'm not convinced that
all of the IPng contenders make these features more efficient than
IPv4. I'm also not convinced that this should be a criterion for
IPng. Do we know enough now to say that these are THE applications
that we should be optimizing for?
From: dcrocker at mordor.stanford.edu (Dave Crocker)
Concerning 'mobility': I consider the continuing rate of proposals being
made to the IP mobility wg to be an indication that we either don't
really know how to solve it or, worse, that we aren't yet sure what we
are solving. Hence, we can't know whether we can use IPv4 (or any of
the contenders) to accomplish the task(s).
Not at all. It indicates that there are multiple engineering choices
to be made and that we lack the experience to know which choices are
optimal.
Tony
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10342;
6 Aug 93 15:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10332;
6 Aug 93 15:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06597;
6 Aug 93 15:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10317;
6 Aug 93 15:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10274;
6 Aug 93 15:16 EDT
Received: from dsaca5.dsac.dla.mil by CNRI.Reston.VA.US id aa06554;
6 Aug 93 15:16 EDT
Received: by dsaca5.dsac.dla.mil (5.59/25-eef)
id AA15478; Fri, 6 Aug 93 15:12:54 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: James Cassell <nrm1838 at dsaca5.dsac.dla.mil>
Message-Id: <9308061912.AA15478 at dsaca5.dsac.dla.mil>
Subject: Unsubscribe
To: ietf at CNRI.Reston.VA.US
Date: Fri, 6 Aug 93 15:12:29 EDT
X-Mailer: ELM [version 2.2 PL15]
Dear Sir;
At this time I wish to unsubscribe from the IETF listing.
Thank you
Jim Cassell
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11077;
6 Aug 93 15:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11067;
6 Aug 93 15:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07313;
6 Aug 93 15:43 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11057;
6 Aug 93 15:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10981;
6 Aug 93 15:41 EDT
Received: from dsaca5.dsac.dla.mil by CNRI.Reston.VA.US id aa07246;
6 Aug 93 15:41 EDT
Received: by dsaca5.dsac.dla.mil (5.59/25-eef)
id AA15943; Fri, 6 Aug 93 15:37:57 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Chris Fredenburg <nrm1989 at dsaca5.dsac.dla.mil>
Message-Id: <9308061937.AA15943 at dsaca5.dsac.dla.mil>
Subject: Unsubscribe
To: ietf at CNRI.Reston.VA.US
Date: Fri, 6 Aug 93 15:37:31 EDT
X-Mailer: ELM [version 2.2 PL15]
Dear Sir;
At this time I wish to unsubscribe from the IETF listing.
Thank you
Chris Fredenburg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11198;
6 Aug 93 15:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11185;
6 Aug 93 15:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07415;
6 Aug 93 15:45 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11173;
6 Aug 93 15:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11090;
6 Aug 93 15:44 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa07356; 6 Aug 93 15:44 EDT
Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA17196 for ietf at cnri.reston.va.us; Fri, 6 Aug 93 15:44:46 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA00266; Fri, 6 Aug 93 12:43:05 PDT
Message-Id: <9308061943.AA00266 at aland.bbn.com>
To: perk at watson.ibm.com
Cc: dcrocker at mordor.stanford.edu, ietf at CNRI.Reston.VA.US
Subject: improving IPng requirements
In-Reply-To: Your message of Fri, 06 Aug 93 14:17:11 -0400.
<9308061416.aa04454 at CNRI.Reston.VA.US>
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: Fri, 06 Aug 93 12:43:05 -0700
X-Orig-Sender: craig at aland.bbn.com
> PS. Is any more work being done on improving/
> revising the requirements for IPng?
Frank Kastenholz and I were planning to take a crack at revising our
memo this month. Since there's some controversy about which requirements
are more important than others, we thought we might issue the new version
as a personal attempt to clarify the issues rather than try to get it blessed
as an IETF criteria document (especially since it isn't clear what an
IETF criteria document would do for the discussion).
Craig
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11717;
6 Aug 93 15:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07748;
6 Aug 93 15:55 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11695;
6 Aug 93 15:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11618;
6 Aug 93 15:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07647;
6 Aug 93 15:53 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11613;
6 Aug 93 15:53 EDT
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Terry Gray <gray at cac.washington.edu>
Subject: IETF INTERIM MTG: Interactive Mail Access protocol (IMAP)
Date: Fri, 06 Aug 93 15:53:27 -0400
X-Orig-Sender: mwalnut at CNRI.Reston.VA.US
Message-ID: <9308061553.aa11613 at IETF.CNRI.Reston.VA.US>
WHAT: Interactive Mail Access protocol (IMAP) Working Group
- Applications Area -
WHEN: August 30-31, 1993 (Monday-Tuesday)
WHERE: University of Washington, Seattle, WA, USA
WHY: To work on refining the revised IMAP specification
(draft to be released shortly.)
CONTACT: imap-rsvp at cac.washington.edu
Terry Gray, WG Chair
University of Washington
gray at cac.washington.edu
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13146;
6 Aug 93 16:39 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09364;
6 Aug 93 16:39 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13125;
6 Aug 93 16:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13066;
6 Aug 93 16:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09327;
6 Aug 93 16:37 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13061;
6 Aug 93 16:37 EDT
To: IETF-Announce: ;
cc: minutes at CNRI.Reston.VA.US
Subject: July IETF: On-line Minutes
Date: Fri, 06 Aug 93 16:37:25 -0400
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Debra Legare <dlegare at CNRI.Reston.VA.US>
Message-ID: <9308061637.aa13061 at IETF.CNRI.Reston.VA.US>
Below is a list of Minutes from the July IETF which are available
from the IETF remote directories.*
Debra
*They will not be available on ds.internic.net until their files are
updated Friday night/Saturday morning.
========
July IETF Area Reports
----------------------
93jul/area.applications.93jul.txt
93jul/area.internet.93jul.txt
93jul/area.netmanage.93jul.txt
93jul/area.userservices.93jul.txt
July IETF Minutes
-----------------
93jul/emailmgt-minutes-93jul.txt
93jul/giss-minutes-93jul.txt
93jul/iab-minutes-93jul.txt
93jul/imp-minutes-93jul.txt
93jul/ipdecide-minutes-93jul.txt
93jul/mmusic-minutes-93jul.txt
93jul/multiapp-minutes-93jul.txt
93jul/nat-minutes-93jul.txt
93jul/nmdir-minutes-93jul.txt
93jul/osiextnd-minutes-93jul.txt
93jul/st2-minutes-93jul.txt
93jul/tcpmuxp-minutes-93jul.txt
93jul/ucs-minutes-93jul.txt
aac/aac-minutes-93jul.txt
atm/atm-minutes-93jul.txt
atommib/atommib-minutes-93jul.txt
bgp/ipidrp-bgp-minutes-93jul.txt
bgpdepl/bgpdepl-minutes-93jul.txt
cat/cat-minutes-93jul.txt
dns/dns-minutes-93jul.txt
fddimib/fddimib-minutes-93jul.txt
frnetmib/frnetmib-minutes-93jul.txt
idmr/idmr-minutes-93jul.txt
ids/ids-minutes-93jul.txt
iiir/iiir-minutes-93jul.txt
imap/imap-minutes-93jul.txt
ipidrp/ipidrp-bgp-minutes-93jul.txt
iplpdn/pppext-iplpdn-minutes-93jul.txt
isis/isis-minutes-93jul.txt
isn/isn-minutes-93jul.txt
mhsds/mhsds-minutes-93jul.txt
mobileip/mobileip-minutes-93jul.txt
modemmgt/modemmgt-minutes-93jul.txt
nasreq/nasreq-minutes-93jul.txt
nir/nir-minutes-93jul.txt
nisi/nisi-minutes-93jul.txt
noop/tuba-noop-rare-minutes-93jul.txt
opstat/opstat-minutes-93jul.txt
osids/osids-minutes-93jul.txt
pem/pem-minutes-93jul.txt
pip/pip-minutes-93jul.txt
pppext/pppext-iplpdn-minutes-93jul.txt
pppext/pppext-minutes-93jul.txt
ripv2/ripv2-minutes-93jul.txt
sdr/sdr-minutes-93jul.txt
sip/sip-minutes-93jul.txt
snanau/snanau-minutes-93jul.txt
svrloc/svrloc-minutes-93jul.txt
tcplw/tcplw-minutes-93jul.txt
telnet/telnet-minutes-93jul.txt
thinosi/thinosi-minutes-93jul.txt
tpix/tpix-minutes-93jul.txt
trainmat/trainmat-minutes-93jul.txt
trmon/trmon-minutes-93jul.txt
tuba/tuba-minutes-93jul.txt
tuba/tuba-noop-rare-minutes-93jul.txt
upsmib/upsmib-minutes-93jul.txt
uri/uri-minutes-93jul.txt
userdoc2/userdoc2-minutes-93jul.txt
uswg/uswg-minutes-93jul.txt
wnils/wnils-minutes-93jul.txt
x400ops/x400ops-minutes-93jul.txt
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13907;
6 Aug 93 17:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10477;
6 Aug 93 17:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13897;
6 Aug 93 17:08 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13803;
6 Aug 93 17:06 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-cameron-tmux-00.txt
Date: Fri, 06 Aug 93 17:06:43 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308061706.aa13803 at IETF.CNRI.Reston.VA.US>
--NextPart
A New Internet Draft is available from the on-line Internet-Drafts
directories.
Title : Transport Multiplexing Protocol (TMux)
Author(s) : P. Cameron, D. Crocker
Filename : draft-cameron-tmux-00.txt
Pages : 6
One of the problems with the use of terminal servers is the large number of
small packets they can generate. Frequently, most of these packets are
destined for only one or two hosts. TMux is a protocol which allows
multiple short transport segments, independent of application type, to be
combined between a server and host pair.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-cameron-tmux-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-cameron-tmux-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-cameron-tmux-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-cameron-tmux-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 aa14842;
6 Aug 93 17:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14838;
6 Aug 93 17:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11802;
6 Aug 93 17:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14827;
6 Aug 93 17:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14823;
6 Aug 93 17:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11797;
6 Aug 93 17:51 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14818;
6 Aug 93 17:51 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: The PPP Internetwork Packet Exchange Control Protocol
(IPXCP) to Proposed Standard
Date: Fri, 06 Aug 93 17:51:18 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308061751.aa14818 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Point-to-Point Protocol
Extensions Working Group to consider "The PPP Internetwork Packet
Exchange Control Protocol (IPXCP)" <draft-ietf-pppext-ipxcp-04.txt>
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
20 August.
John Stewart
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15005;
6 Aug 93 17:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14999;
6 Aug 93 17:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11934;
6 Aug 93 17:55 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14990;
6 Aug 93 17:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14986;
6 Aug 93 17:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11929;
6 Aug 93 17:55 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14981;
6 Aug 93 17:55 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: host-conf at sol.bucknell.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 Call2: Dynamic Host Configuration
Date: Fri, 06 Aug 93 17:55:13 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308061755.aa14981 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Dynamic Host Configuration
Working Group to consider the following Internet-Drafts, which have
been updated to incorporate changes suggested during the first Last
Call Period, for the status of Proposed Standard:
o "Interoperation Between DHCP and BOOTP"
<draft-ietf-dhc-between-bootp-03.txt>
o "Clarifications and Extensions for the Bootstrap Protocol"
<draft-ietf-dhc-bootp-02.txt>
o "DHCP Options and BOOTP Vendor Extensions"
<draft-ietf-dhc-options-04.txt>
o "Dynamic Host Configuration Protocol"
<draft-ietf-dhc-protocol-07.txt>
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 20 August.
John Stewart
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15694;
6 Aug 93 18:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12836;
6 Aug 93 18:25 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15680;
6 Aug 93 18:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15635;
6 Aug 93 18:23 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa12751;
6 Aug 93 18:23 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA18520>; Fri, 6 Aug 1993 15:24:22 -0700
Message-Id: <199308062224.AA18520 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1501 on OSI/2 User Group
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 06 Aug 93 15:24:16 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 1501:
Title: OSI/2 User Group
Author: E. Brunsen
Mailbox: BRUNSENE at EMAIL.ENMU.EDU
Pages: 2
Characters: 3,636
Updates/Obsoletes: none
This RFC is being distributed to members of the Internet community in
order to solicit their reactions to the proposals contained in it.
While the issues discussed may not be directly relevant to the
research problems of the Internet, they may be interesting to a number
of researchers and implementers.
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 rfc1501.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1501.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 aa15727;
6 Aug 93 18:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12852;
6 Aug 93 18:26 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15717;
6 Aug 93 18:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15656;
6 Aug 93 18:24 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa12797;
6 Aug 93 18:24 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA18538>; Fri, 6 Aug 1993 15:25:33 -0700
Message-Id: <199308062225.AA18538 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC1467 on Status of CIDR Deployment in the Internet
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 06 Aug 93 15:25:27 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 1467:
Title: Status of CIDR Deployment in the Internet
Author: C. Topolcic
Mailbox: topolcic at CNRI.Reston.VA.US
Pages: 9
Characters: 20,720
Obsoletes: 1367
This document describes the current status of the development and
deployment of CIDR technology into the Internet. This document
replaces RFC 1367, which was a schedule for the deployment of IP
address space management procedures to support route aggregation.
Since all the milestones proposed in RFC 1367 except for the delivery
and installation of CIDR software were met, it does not seem
appropriate to issue an updated schedule. Rather, this document is
intended to provide information about how this effort is proceeding,
which may be of interest to the community.
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 rfc1467.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1467.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 aa15774;
6 Aug 93 18:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15770;
6 Aug 93 18:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12890;
6 Aug 93 18:27 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15759;
6 Aug 93 18:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15755;
6 Aug 93 18:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12885;
6 Aug 93 18:27 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15750;
6 Aug 93 18:27 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
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: CIDR Documents to Proposed Standard
Date: Fri, 06 Aug 93 18:27:34 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308061827.aa15750 at IETF.CNRI.Reston.VA.US>
The IESG has received requests from members of the Internet community
to consider:
o "An Architecture for IP Address Allocation with CIDR"
<draft-rekhter-ipaddress-guide-08.txt>
o "Classless Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy" <draft-fuller-cidr-strategy-02.txt>
o "Applicability Statement for the Implementation of Classless
Inter-Domain Routing (CIDR)" <draft-ietf-iesg-cidr-01.txt>
for the status of Proposed Standard.
The IESG also received requests from members of the Internet
community to consider:
o "Exchanging Routing Information Across Provider/Subscriber
Boundaries in the CIDR Environment
<draft-rekhter-cidr-environment-00.txt>
as an Informational RFC.
This set of documents defines Classless Inter-Domain Routing (CIDR)
and it's applicability for implementation in the Internet. CIDR
defines an architecture and a plan for allocating IP addresses in
the Internet. This architecture and plan is intended to play an
important role in steering the Internet towards the Address
Assignment and Aggregation Strategy.
The CIDR architecture is applicable to any group of connected
domains that supports IP version 4. The CIDR Applicability
Statement requires Internet domains providing backbone and/or
transit service to fully implement CIDR in order to ensure that the
growth of the resources required by routers to provide Internet-wide
connectivity will be significantly slower than the growth of the
number of assigned networks. The CIDR Applicability Statement also
recommends that all non-backbone/transit Internet domains implement
CIDR because it will reduce the amount of routing information inside
of these domains.
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 20 August.
John Stewart
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15896;
6 Aug 93 18:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15886;
6 Aug 93 18:31 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12994;
6 Aug 93 18:31 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15876;
6 Aug 93 18:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15850;
6 Aug 93 18:29 EDT
Received: from mocha.bunyip.com by CNRI.Reston.VA.US id aa12931;
6 Aug 93 18:29 EDT
Received: from expresso.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA25848 (mail destined for ietf at CNRI.Reston.VA.US) on Fri, 6 Aug 93 18:30:05 -0400
Received: by expresso.bunyip.com (NX5.67c/NeXT-1.0)
id AA24309; Fri, 6 Aug 93 18:21:54 -0400
Message-Id: <9308062221.AA24309 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: Fri, 6 Aug 1993 18:21:52 -0400
In-Reply-To: braden at isi.edu's message as of Aug 6, 10:28
X-Mailer: Mail User's Shell (7.2.4 2/2/92)
To: ietf at CNRI.Reston.VA.US, Richard W Wiggins <WIGGINS at msu.edu>
Subject: Re: Internet growth models
[ You wrote: ]
> It has occurred to me that a huge amount of the growth we see
> on the Internet is in fact the workstation revolution, not the
> Internet revolution. To take my campus alone, we must have gone
> from a few dozen IP addresses in 1983 or so to a few thousand
> in 1993. . . .
This is a good point, although it may not tell the whole
story. Machine counts, although rough approximations, are
probably "correct within an order of magnitude" and at
least can be measured consistently from period to period.
On the other hand, I for one have never been happy with
any of the published estimates of the number of users on
the Internet since all such counts seem to be based upon an
extrapolation out from the number of machines, using some
vague multipler which seems pretty hard to justify beyond
"that seems to be what we see at our site".
Such vagueness makes me nervious since I'm not sure that
such extrapolations can be performed consistently over
time. We too saw hundreds of people move off the campus
mainframe onto their own boxes in the past couple of
years. If this is an Internet-wide trend it does argue for
slower growth in the number of users. The question is
whether this is a local phenomenon or a global one.
One counterbalancing trend is that large numbers of
students graduate each year and are banished to the non-IP
wilderness. To prevent serious Internet withdrawal they
are allowing a fair number of dialin providers to make
money selling them a connected box and a UNIX command line
prompt.
The traditional online services are also starting to
arrive on the net in quantity. Delphi claims hundreds of
thousands of users. I think Prodigy currently has only
email access but that's millions of accounts poised on the
brink. I also know connectivity providers who are working
to bring local BBSs to the net in quantity, thus
connecting hundreds of people at a time. All of this I
think results in a set of trends that perhaps cancel out
that drift off the mainframes we are seeing back at
academia.
The picture is of course more complicated than that, since
there are also large corporations bringing their clusters
of workstations and PCs onto the net too, which argues for
more single user access and a dilution in the number of
bodies per machine compared to the growth in dialin
provider traffic and who knows how all the comparative
numbers cancel and reinforce? I would just be a little
cautious about extrapolating trends from the academic to
non-academic sector of the Internet at this point, given
the disparity in growth rates the differing trends in the
two areas and the relative decline in importance of the
academic sector over time.
. . .
> The point is that in one sense the number of *people* with Internet
> access may not be expanding quite as dramatically as some estimates
> show. At our site we had thousands of people with mainframe access
> in 1985, and now some of those thousands come in via workstations.
Well, at McGill we nominally had thousands of people with
access from '87 or so onwards, but in reality students were
discouraged from even sending email, few courses use the
computer for anything more than text processing of assignments
and the entire campus was reaching the Internet through a
9600 baud leased line. Today, there are workstation and PC
labs for most faculties and departments, the admin staff
are all on IP-literate Novell networks and even Deans send email.
Although we can't measure it exactly, the trend is for
more people to really use the network for day to day tasks.
Even if in academia we are not nominally adding more people
than we had a few years ago, in reality each such user is
also generating far more traffic. Where five years ago
Gopher, archie and its friends were still only a gleem in
a few techo-dweebs' eyes, today there are now almost thirty
archie server sites, most networks offer at least one
Gopher server, and at my old alma mater line speeds are up
almost two orders of magnitude. There are even people on
campus whose job description specifically call for them to
administer networks!
Meanwhile, out in the commercial world, I remember the
consternation that resulted a few months ago when one of
the newly arrived dialin service providers set up a gopher
menu to point to some useful service at a remote
university and their tens of thousands of customers all
pounded on it the same day. By any measure, the trend in
traffic seems to be up.
I think this all points to the fact that the growth is
real enough, although the actual metrics quoted may not be
the right ones to measure. The growth in number of users
_may_ be not quite as dramatic in your neck of the woods
as some are saying, but by any measure the trends indicate
that more people are doing more things and this is true
whether you look at total traffic count, number of
connected hosts or the number of dialin provider customers.
These are all things that can be measured with fair
precision (as opposed to guesstimate multiplers of the
number of users on hosts). They all still point up at a
dizzying pace.
> On a campus or corporate network it's relatively easy to move
> Internet access to the desktop. It seems to me a big part of
> the question of growth beyond traditional communities is when
> will dialup PPP (or ISDN) access become stable, usable, common
> means of access? When will Sprint or AT&T offer an Internet dialtone?
> It seems to me that when those hurdles are crossed, that's when we're
> poised for a true explosion of new user populations.
I think that at least for the near term, a large number of
the "naive" new users, and many of those ex-students
banished to the wilderness of non-connectivity, will return
to a state of connected grace through an IP-connected
dialin machine, not by installing their own IP network in
their house, so the immediate future for sites like the
World, Delphi and their friends looks pretty rosey. I
think that in the longer term (a couple of years or more)
we're looking at IP dialtone to every house, and I
certainly hope the gang over on big-internet get it right
soon, but in the short term there's certainly viable
alternatives to IP toasters...
- 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 CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16368;
6 Aug 93 19:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14808;
6 Aug 93 19:29 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16358;
6 Aug 93 19:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16332;
6 Aug 93 19:27 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa14784;
6 Aug 93 19:27 EDT
Received: from akamai.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA20058>; Fri, 6 Aug 1993 16:27:53 -0700
Message-Id: <199308062327.AA20058 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RESEND - RFC1501 on OS/2 User Group
Cc: jkrey at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Date: Fri, 06 Aug 93 16:27:48 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: "Joyce K. Reynolds" <jkrey at isi.edu>
--NextPart
A REVISED Request for Comments of the document below will be available
in online RFC libraries by Monday. Sorry for the inconvenience!
RFC 1501:
Title: OS/2 User Group
Author: E. Brunsen
Mailbox: BRUNSENE at EMAIL.ENMU.EDU
Pages: 2
Characters: 3,636
Updates/Obsoletes: none
This RFC is being distributed to members of the Internet community in
order to solicit their reactions to the proposals contained in it.
While the issues discussed may not be directly relevant to the
research problems of the Internet, they may be interesting to a number
of researchers and implementers.
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 rfc1501.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc1501.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 aa16810;
6 Aug 93 20:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16800;
6 Aug 93 20:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15568;
6 Aug 93 20:09 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16790;
6 Aug 93 20:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16759;
6 Aug 93 20:07 EDT
Received: from endo.wide.ad.jp by CNRI.Reston.VA.US id aa15516;
6 Aug 93 20:07 EDT
Received: by endo.sfc.wide.ad.jp (5.67+1.6W/2.7W)
id AA12092; Sat, 7 Aug 93 09:07:58 +0900
Return-Path: <tomy at endo.sfc.wide.ad.jp>
Message-Id: <9308070007.AA12092 at endo.sfc.wide.ad.jp>
To: ietf at CNRI.Reston.VA.US
Subject: usage of secs field [draft-ietf-dhc-protocol-07]
Date: Sat, 07 Aug 1993 09:07:57 +0900
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Akihiro Tominaga <tomy at endo.sfc.wide.ad.jp>
I have some suggestions and questions about retransmission of DHCP
messages. Firstly, question about retransmission of DHCPDISCOVER.
When retransmit DHCPDISCOVER message, does the client have to add some
number ? If the client follows the "bootp clarification and
extensions (draft-ietf-dhc-bootp-02)", the client must add seconds
since first DHCPDISCOVER. Then in the draft-ietf-dhc-protocol-07,
> DHCPREQUEST message must use the same value in the DHCP message
> header's 'secs' field and be sent to the same IP broadcast address as
> the original DHCPDISCOVER message.
the client must use the same 'secs' value as DHCPDISCOVER 'secs'.
But, how can the client choose which 'secs' between the previous
DHCPDISCOVER messages ?
So, in the table 3:
> Field_________DHCPOFFER____________DHCPACK_____________DHCPNAK______________
> 'op' BOOTREPLY BOOTREPLY BOOTREPLY
> 'xid' 'xid' from client 'xid' from client 'xid' from client
> DHCPDISCOVER DHCPREQUEST DHCPREQUEST
> message message message
> 'secs' 0 0 0
^^ ^^ ^^
Is it better to change them to " 'secs' from client DHCP**** " ?
So, the client can use appropriate 'secs'.
Secondly, question about retransmission of DHCPREQUEST, especailly
when the client reacquiring the previously allocated IP address.
When T1 has expired, the client unicast DHCPREQUEST to the server. In
that case, the client must reset 'secs' field ? ('reset' means 'set
0'.) So, when retransmit the DHCPREQUEST, set seconds elapsed from
first (reacquiring) DHCPREQUEST ?
When T2 has expired, 'secs' are seconds from the first (reacquiring
unicast) DHCPREQUEST ? Or, from the first broadcast DHCPREQUEST ?
If server returns 'secs' from client DHCP message, the client can compute
lease expiration time as follows:
lease = local_time + lease_duration + secs
then, the client can use reacquiring lease without loss time which
comes from retransmission.
--
Keio Univ.
WIDE Project.
Akihiro Tominaga tomy at sfc.wide.ad.jp
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17209;
6 Aug 93 21:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17199;
6 Aug 93 21:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17099;
6 Aug 93 21:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17189;
6 Aug 93 21:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17156;
6 Aug 93 21:05 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa17080;
6 Aug 93 21:05 EDT
Received: from itd.nrl.navy.mil by venera.isi.edu (5.65c/5.61+local-12)
id <AA04343>; Fri, 6 Aug 1993 18:06:18 -0700
Received: by itd.nrl.navy.mil (4.1/SMI-4.1)
id AA08414; Fri, 6 Aug 93 21:06:11 EDT
Date: Fri, 6 Aug 93 21:06:11 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: <9308070106.AA08414 at itd.nrl.navy.mil>
To: ietf at isi.edu
Subject: imminent demise of the net predicted...
Actually, not so much death as division. I'm about to buy a new
router for use to decouple my building from the rest of my division
here at NRL. Why ?
The recent growth in IP traffic has put us over the limit of what
our poor old Ethernet can handle. So we're moving half of 128.60.2.x
into a new Class C equivalent subnet. The number of installed machines
hasn't changed significantly. However traffic is much higher because
of new applications, namely:
Gopher traffic
Mosaic/WWW traffic
MIME email messages are larger than the old '822 style
MBONE traffic (this was the last straw because it has become
so popular locally for folks to communicate
with each other. :-)
It isn't very clear to me that the address space problem is really
the only issue to worry about. Traffic growth and in particular
multicast traffic growth are also significant issues. The support for
good multicast and for real-time flows is much much more important in
an IPng proposal than some folks appear to realise.
Ran
atkinson at itd.nrl.navy.mil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17505;
6 Aug 93 21:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17495;
6 Aug 93 21:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18250;
6 Aug 93 21:50 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17481;
6 Aug 93 21:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17450;
6 Aug 93 21:48 EDT
Received: from gibbs.oit.unc.edu by CNRI.Reston.VA.US id aa18172;
6 Aug 93 21:48 EDT
Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1)
id AA23786; Fri, 6 Aug 93 21:49:23 -0400
Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1)
id AA10688; Fri, 6 Aug 93 21:51:43 EDT
Message-Id: <9308070151.AA10688 at tipper>
X-Really-To: gibbs.oit.unc.edu
To: ietf at CNRI.Reston.VA.US
Subject: Re: RFC1501 on OSI/2 User Group
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 06 Aug 93 21:51:42 -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>
When I looked at the name of this RFC, I thought 'great'; anything that
reduces OSI has to be good news- the only only concern I had was that the
denominator seemed to be way too small, and that this document had been issued
without being discussed in the thin-osi working group.
Might I suggest the formation of a new working group to focus on creating
a scaleable version of this concept - OSI/2^n?
Simon
----
Hackers Local 42- National Union of Computer Operatives, Chapel Hill section
------------------------------------------------------------------------------
Tar Heel Information Services - Nothing but net! | WAIS/Z39.50 spoken here
CLNP - The C is for Clue | DoD #612 | Tel: +1-919-962-9107
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17780;
6 Aug 93 22:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17770;
6 Aug 93 22:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18854;
6 Aug 93 22:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17760;
6 Aug 93 22:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17731;
6 Aug 93 22:17 EDT
Received: from sayshell.umd.edu by CNRI.Reston.VA.US id aa18802;
6 Aug 93 22:17 EDT
Received: from localhost by sayshell.umd.edu (NX5.67c/NeXT-1.0)
id AA00576; Fri, 6 Aug 93 22:18:33 -0400
Message-Id: <9308070218.AA00576 at sayshell.umd.edu>
To: Bob Stewart <rlstewart at eng.xyplex.com>
Cc: ietf at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Louis A. Mamakos" <louie at ni.umd.edu>
Subject: Re: Last Call: Use of ISO CLNP in TUBA
In-Reply-To: Your message of "Fri, 06 Aug 1993 15:54:58 CDT."
<9308062054.AA28008 at xap.xyplex.com>
Date: Fri, 06 Aug 1993 22:18:33 -0400
X-Orig-Sender: louie at sayshell.umd.edu
I said,
> >Sure, to be politically correct a
> >few years ago, we speced CLNP capability in our router procurement,
> >but that feature has never been configured.
and Bob replied,
> Such political correctness is not without cost. Even if you don't use it,
> you, and everyone else who buys routers, pay for the engineering time to
> implement it, which might otherwise have been spent on a useful feature.
I agree 100% here. CLNP capability was not a feature that I
personally wanted, or expected to enable over the lifetime of the
equipment in question. I was a case where "everyone" was certain we
would "transition" from to the holy grail that was CLNP and OSI.
This is, of course, my personal opinion.
Louis A. Mamakos
University of Maryland, College Park
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24653;
6 Aug 93 23:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24643;
6 Aug 93 23:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21118;
6 Aug 93 23:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24630;
6 Aug 93 23:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24204;
6 Aug 93 23:47 EDT
Received: from uu6.psi.com by CNRI.Reston.VA.US id aa21101; 6 Aug 93 23:47 EDT
Received: from factory.UUCP by uu6.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP;
id AA14463 for ; Fri, 6 Aug 93 23:33:51 -0400
To: ietf at CNRI.Reston.VA.US
Subject: Unsubscribe
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jonathon Spiers <jonathon.spiers at factory.com>
Message-Id: <12562.500.uupcb at factory.com>
Date: Fri, 6 Aug 93 21:08:00
Organization: Invention Factory's BBS - New York City, NY - 212-274-8298v.32bis
Reply-To: Jonathon Spiers <jonathon.spiers at factory.com>
Please unsubscribe me from the IETF listings
FROM: jonathon.spiers at factory.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00916;
7 Aug 93 3:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00906;
7 Aug 93 3:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02320;
7 Aug 93 3:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00895;
7 Aug 93 3:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00850;
7 Aug 93 3:41 EDT
Received: from sun4nl.nluug.nl by CNRI.Reston.VA.US id aa02131;
7 Aug 93 3:41 EDT
Received: from vicnl by sun4nl.nluug.nl via EUnet
id AA03483 (5.65b/CWI-3.3); Sat, 7 Aug 1993 09:42:31 +0200
Received: from vic1 by vicnl.victron.nl id aa07095; 7 Aug 93 9:13 CEST
Received: from VICTRON_ONE/TEMPQ by vic1.victron.nl (Mercury 1.0);
Sat, 7 Aug 93 9:17:13 GMT+0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mail Delivery System <postmaster at vic1.victron.nl>
To: ietf at CNRI.Reston.VA.US
Date: Sat, 7 Aug 93 9:16:43 GMT+0200
Subject: Delivery failure notification
Message-Id: <A06D6383D68 at vic1.victron.nl>
With reference to your message with the subject:
"usage of secs field [draft-ietf-dhc-protocol-07]"
One or more addresses in your message have failed with the following
responses from the mail transport system:
554 [ No such file or directory ] Message has travelled too many hops
For assistance, please mail postmaster at vic1.victron.nl.
-------------------- Returned message follows ---------------------
Received: from vicnl.victron.nl by vic1.victron.nl (Mercury 1.0);
Sat, 7 Aug 93 9:16:07 GMT+0200
Received: from vic1 by vicnl.victron.nl id aa07088; 7 Aug 93 9:12 CEST
Received: from VICTRON_ONE/TEMPQ by vic1.victron.nl (Mercury 1.0);
Sat, 7 Aug 93 9:16:01 GMT+0200
Received: from vicnl.victron.nl by vic1.victron.nl (Mercury 1.0);
Sat, 7 Aug 93 9:15:31 GMT+0200
Received: from vic1 by vicnl.victron.nl id aa07083; 7 Aug 93 9:11 CEST
Received: from VICTRON_ONE/TEMPQ by vic1.victron.nl (Mercury 1.0);
Sat, 7 Aug 93 9:15:25 GMT+0200
Received: from vicnl.victron.nl by vic1.victron.nl (Mercury 1.0);
Sat, 7 Aug 93 9:14:56 GMT+0200
Received: from vic1 by vicnl.victron.nl id aa07078; 7 Aug 93 9:11 CEST
Received: from VICTRON_ONE/TEMPQ by vic1.victron.nl (Mercury 1.0);
Sat, 7 Aug 93 9:14:50 GMT+0200
Received: from vicnl.victron.nl by vic1.victron.nl (Mercury 1.0);
Sat, 7 Aug 93 9:14:20 GMT+0200
Received: from vic1 by vicnl.victron.nl id aa07073; 7 Aug 93 9:10 CEST
Received: from VICTRON_ONE/TEMPQ by vic1.victron.nl (Mercury 1.0);
Sat, 7 Aug 93 9:14:15 GMT+0200
Received: from vicnl.victron.nl by vic1.victron.nl (Mercury 1.0);
Sat, 7 Aug 93 9:13:45 GMT+0200
Received: from vic1 by vicnl.victron.nl id aa07067; 7 Aug 93 9:10 CEST
Received: from VICTRON_ONE/TEMPQ by vic1.victron.nl (Mercury 1.0);
Sat, 7 Aug 93 9:13:40 GMT+0200
Received: from vicnl.victron.nl by vic1.victron.nl (Mercury 1.0);
Sat, 7 Aug 93 9:13:10 GMT+0200
Received: from vic1 by vicnl.victron.nl id aa07054; 7 Aug 93 9:09 CEST
Received: from VICTRON_ONE/TEMPQ by vic1.victron.nl (Mercury 1.0);
Sat, 7 Aug 93 9:13:05 GMT+0200
Received: from vicnl.victron.nl by vic1.victron.nl (Mercury 1.0);
Sat, 7 Aug 93 9:12:27 GMT+0200
Received: from vic1 by vicnl.victron.nl id af07001; 7 Aug 93 9:08 CEST
Received: from VICTRON_ONE/TEMPQ by vic1.victron.nl (Mercury 1.0);
Sat, 7 Aug 93 9:12:23 GMT+0200
To: tomy at endo.sfc.wide.ad.jp
MMDF-Warning: Parse error in original version of preceding line at vicnl.victron.nl
From: ietf at cnri.reston.va.us
Date: Sat, 7 Aug 93 9:11:43 GMT+0200
Subject: usage of secs field [draft-ietf-dhc-protocol-07]
Message-ID: <A06C2CA70B1 at vic1.victron.nl>
Your mail has savely arrived in my mailbox.
I will respond to you as soon as I am back in the office.
For urgent matters, please contact:
theo at victron.nl (++31 50 446285)
(If you have addressed me via a mailing list, the appropriate
people will have received your mail as well, please ignore this
message in that case.)
Kind regards,
Jack
+----------------------------------------------------+
| Victron bv POB 31 9700 AA Groningen Holland |
| phone: +31 50 446222 fax: +31 50 424107 |
+----------------------------------------------------+
| No intelligent life down here.. Beam me up Scotty! |
+----------------------------------------------------+
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01489;
7 Aug 93 6:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01479;
7 Aug 93 6:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04692;
7 Aug 93 6:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01469;
7 Aug 93 6:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01445;
7 Aug 93 6:12 EDT
Received: from sun4nl.nluug.nl by CNRI.Reston.VA.US id aa04681;
7 Aug 93 6:12 EDT
Received: from vicnl by sun4nl.nluug.nl via EUnet
id AA05789 (5.65b/CWI-3.3); Sat, 7 Aug 1993 12:12:46 +0200
Received: from vic1 by vicnl.victron.nl id ad07261; 7 Aug 93 12:02 CEST
Received: from VICTRON_ONE/TEMPQ by vic1.victron.nl (Mercury 1.0);
Sat, 7 Aug 93 12:06:08 GMT+0200
To: ietf at CNRI.Reston.VA.US
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: postmaster at vic1.victron.nl
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Date: Sat, 7 Aug 93 12:05:44 GMT+0200
Subject: Delivery failure notification
Message-Id: <A09A79C68D9 at vic1.victron.nl>
Your mail has savely arrived in my mailbox.
I will respond to you as soon as I am back in the office.
For urgent matters, please contact:
theo at victron.nl (++31 50 446285)
(If you have addressed me via a mailing list, the appropriate
people will have received your mail as well, please ignore this
message in that case.)
Kind regards,
Jack
+----------------------------------------------------+
| Victron bv POB 31 9700 AA Groningen Holland |
| phone: +31 50 446222 fax: +31 50 424107 |
+----------------------------------------------------+
| No intelligent life down here.. Beam me up Scotty! |
+----------------------------------------------------+
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03881;
7 Aug 93 14:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03871;
7 Aug 93 14:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14022;
7 Aug 93 14:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03861;
7 Aug 93 14:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03831;
7 Aug 93 14:49 EDT
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa13981;
7 Aug 93 14:49 EDT
Received: by interlock.ans.net id AA21701
(InterLock SMTP Gateway 1.1 for ietf at CNRI.Reston.VA.US);
Sat, 7 Aug 1993 14:45:26 -0400
Received: by interlock.ans.net (Internal Mail Agent-2);
Sat, 7 Aug 1993 14:45:26 -0400
Received: by interlock.ans.net (Internal Mail Agent-1);
Sat, 7 Aug 1993 14:45:26 -0400
Date: Sat, 7 Aug 1993 14:47:25 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ittai Hershman <ittai at ans.net>
Message-Id: <199308071847.AA19535 at shemesh.ans.net>
To: ietf at CNRI.Reston.VA.US
Subject: Protocols and Markets (was: Re: Last Call: Use of ISO CLNP in TUBA)
Cc:
In-Reply-To: <9308051818.AA00488 at iastate.edu>
Allowing the market to choose sounds inefficent, but think back:
what cost the most in the ISO/TCP-IP, SNMP/CMOT, OSPF/IS-IS
battles; the political fighting, or the marketplace deciding?
Multi-protocol support is the most efficient, and least painfully
political way, of letting the market decide.
Yes, but if you let the market decide you may not like the choice.
Let us imagine that IETF comes forward with three proposals:
IPtng', IPtng'', and IPtng''', and says "let the market decide!".
I have a very strong feeling that the market will decide to
stick with IPtos (ignoring all this "doom saying" about running
out of addresses and routing capacity) right up until the moment
things look really dire.
Which market do you think will decide? It seems to me that there
are many different markets that are affected and will be involved
in determining "what the market place decides".
To be clearer, some of these markets are:
- The desktop personal workstation (PC/Mac/Sun/etc) market
- The layer 3 network device (router, gateway, firewall, etc) market
- The commercial Internet network connectivity services market
- The Internet applications and information services market
All of these are markets from which you and I -- as Internet users --
purchase goods. All are markets that are affected by IPng and to one
extent or another will have competing interests and values.
Noel makes the point nicely and I hope he doesn't mind my using his
recent message in a context with which he may not agree:
I'm not sure there will be a single day when IPv4 breaks. Whenever
something goes wrong, "more thrust" (hi Milo, wherever you are :-)
will be applied. This has happened over and over already: 8-bit
network numbers -> A/B/C, subnets, CIDR; GGP->EGP->BGP; etc.
When we run out of new IPv4 addresses to allocate, there will be a
mad scramble to recycle unused ones. When we've run out of those,
we'll switch to interpreting it as an EID to allow use of all the
odd ones lying around. When we have used all those, we'll figure
out how to do NAT. Etc, etc, etc.
Eventually, the thrust/benfit ratio will be so bad, and new things
will have so many new features you can't kludge into IPv4, that
individuals will start to give up and move on to something with a
better ratio (while keeping their toe in the water on the old IPv4
for universal connectivity), but it'll happen gradually.
My translation of this into the marketplace context is:
Initially, end-users will resist migrating from IPv4 (this will
actually happen regardless of the IPtng decision, if one is ever
reached).
Suppliers of network services (and probably TCP/IP infrastructure
vendors) will find low-cost workarounds to IPv4's scaling limits as
long as they can. (e.g. ANS's investment in developing BGP4/CIDR
to be given away in GateD).
Eventually, we will run out of inexpensive workarounds, and we will
need to start spending real dollars on much more complicated router
technology and/or the creation of new gateway router markets.
At some point the cost of continuing to workaround IPv4 will become so
obviously greater than the cost of (finally) migrating to some new
protocol that only the diehards (and legacy systems) are willing to
pay to continue to use IPv4.
The more I think about this, the more this reminds me of the
cancellation of the PDP-10 line by DEC. Our initial reaction was
"what idiots -- how could they do this to us (and to themselves),"
"you gotta be kidding - 'upgrade' to a VAX? Not on your life". Well,
with the passage of time, those of you who lived through that and
objectively look at where we are today, after the desktop computer
revolution, wonder how those people who kept their 10's and 20's in
production could afford to do so. Is this not the same cycle?
Well, this is longer than I anticipated. Pardon the additional noise...
-Ittai
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01767;
9 Aug 93 8:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01759;
9 Aug 93 8:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14898;
9 Aug 93 8:25 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01712;
9 Aug 93 8:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id cm00886;
9 Aug 93 8:25 EDT
Received: from nec-gw.nec.com by CNRI.Reston.VA.US id aa07016; 9 Aug 93 0:48 EDT
Received: by nec-gw.nec.com (5.65/YDL1.7-911107.16)
id AA03282(nec-gw.nec.com ); Sun, 8 Aug 93 21:49:00 -0700
Received: by nwk.cl.nec.co.jp (5.65c/6.4JAIN-nwk-gw+2.1)
id AA07951; Mon, 9 Aug 1993 13:48:58 +0900
Received: by localhost in nwk (4.1/6.4J.6-nwk_slave_1.4)
id AA24278; Mon, 9 Aug 93 13:49:59 JST
Return-Path: <taniguti at nwk.cl.nec.co.jp>
Message-Id: <9308090449.AA24278 at lager.nwk.cl.nec.co.jp>
To: iesg at CNRI.Reston.VA.US, ietf at CNRI.Reston.VA.US
Subject: Re: Last Call: CIDR Documents to Proposed Standard
No-Return-Receipt-To: taniguti at nwk.cl.nec.co.jp
Date: Mon, 09 Aug 93 13:49:58 +0900
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Kunihiro Taniguchi <taniguti at nwk.cl.nec.co.jp>
Dear Interneters,
I have a question concerning CIDR especially
draft-rekhter-ipaddress-guide-08.txt and draft-fuller-cidr-strategy-02.txt.
In case that a router receives a ICMP NETWORK REDIRECT packet, what should
the router do? If not in CIDR environment, it is very easy. The router
should change a route to the network which the packet indicates with
suitable netmask. The netmask is subnetmask if the destination address
and the router interface address is in same network, else the netmask
depends on class. If in CIDR environment, the router may not know
supernet-mask (not subnet-mask) and make a mistake. So I beleive that
router must have a method to get supernet-mask.
Though ICMP has NETMASK REQUEST function to get netmask, it does not
resolve this problem because of two reasons.
1. NETMASK REQUEST is for subnet-mask, not for supernet-mask.
2. NETMASK REPLY is not clarified to return netmask of the ICMP NETMASK
REQUEST packet incoming interface or its destination address interface.
(I think Unix implementation is former.)
So we should modify ICMP slightly, should not?
# I don't join in these mailing-lists. Would you inform me if any
# discussion?
Thank you.
Kunihiro Taniguchi
Network Res. Lab., C&C System Res. Lab. NEC Corp.
Telephone +81-44-856-2312 Facsimile +81-44-856-2229
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02530;
9 Aug 93 8:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab02511;
9 Aug 93 8:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15255;
9 Aug 93 8:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02397;
9 Aug 93 8:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id cv00886;
9 Aug 93 8:25 EDT
Received: from vnet.ibm.com by CNRI.Reston.VA.US id aa12424; 9 Aug 93 6:40 EDT
Received: from VIEVMA by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 5883;
Mon, 09 Aug 93 06:40:15 EDT
Date: Mon, 9 Aug 93 12:40:06 CET
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Dr. Karl Sallinger (xx43-1-21145-2434)" <sallinger at vnet.ibm.com>
To: ietf at CNRI.Reston.VA.US
Subject: Unsubscribe
Message-ID: <9308090640.aa12424 at CNRI.Reston.VA.US>
Please unsubscribe me from the IETF listings
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02553;
9 Aug 93 8:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02520;
9 Aug 93 8:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15263;
9 Aug 93 8:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02400;
9 Aug 93 8:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id bx00886;
9 Aug 93 8:24 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa21970;
8 Aug 93 13:36 EDT
Received: from rodan.UU.NET by venera.isi.edu (5.65c/5.61+local-12)
id <AA07515>; Sun, 8 Aug 1993 10:36:56 -0700
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA02100; Sun, 8 Aug 93 13:36:51 -0400
Received: from slab.mtholyoke.edu.mtholyoke.edu (via slab.mtholyoke.edu) by relay1.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA13335; Sun, 8 Aug 93 13:36:50 -0400
Received: by slab.mtholyoke.edu.mtholyoke.edu (5.65/Ultrix4.2_risc_920301.01)
id AA11821; Sun, 8 Aug 1993 11:37:57 -0400
To: info-ietf at uunet.uu.net
Path: jbotz
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jurgen Botz <jbotz at mtholyoke.edu>
Newsgroups: info.ietf
Subject: Re: Internet BYPASS makes its debut - for transmission of FAX's
Date: 8 Aug 1993 15:37:56 GMT
Organization: Mount Holyoke College, South Hadley, MA, USA
Lines: 26
Message-Id: <2436kk$bhb at slab.mtholyoke.edu>
References: <9307212014.AA20569 at radiomail>
Nntp-Posting-Host: orixa.mtholyoke.edu
In article <9307212014.AA20569 at radiomail>,
the terminal of Geoff Goodfellow <geoff at radiomail.net> wrote:
>Today's SAN JOSE MERCURY NEWS Business Section had the following
>front page story (From the New York Times - by John Markoff):
>[...]
>Rose noted that the blurring of fax
>and electronic mail would raise thorny questions.
> ``Is this global and local bypass of the telephone companies
>using the Internet?'' he asked rhetorically. ``Is this legal? We
>need to think about this.''
Was Rose quoted properly here? This doesn't make any sense... of
course it's legal. And it's not exactly a bypass of the phone
companies, either, it's more like a different choice of long-distance
carriers. (Also... some parts of the net /are/ the telephone
companies. In those cases all we're doing here is encoding the
information more efficiently.)
Sure if this becomes big the telcos lose, since the way fax is
currently used is one of the most inefficient (and thus profitable
for the telcos) ways of transmitting information electronically
imaginable. But I still don't see why that's a "thorny issue"...
--
Jurgen Botz, jbotz at mtholyoke.edu | ``Accountability is the price of openness''
South Hadley, MA, USA | - Daniel Geer
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02564;
9 Aug 93 8:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02525;
9 Aug 93 8:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15265;
9 Aug 93 8:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02398;
9 Aug 93 8:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id bv00886;
9 Aug 93 8:24 EDT
Received: from darpa.mil by CNRI.Reston.VA.US id aa21521; 8 Aug 93 13:11 EDT
Received: from sun4.darpa.mil by vax.darpa.mil (5.65c/5.61+local-5)
id <AA24241>; Sun, 8 Aug 1993 13:12:00 -0400
Posted-Date: Sun, 08 Aug 93 13:06:48 EDT
Message-Id: <9308081706.AA01727 at sun4.darpa.mil>
Received: by sun4.darpa.mil (4.0/4.0.3-3)
id <AA01727>; Sun, 8 Aug 93 13:06:50 EDT
To: Dave Crocker <dcrocker at mordor.stanford.edu>
Cc: ietf at CNRI.Reston.VA.US
Reply-To: pvm at arpa.mil
Subject: Re: TUBA w/out IPng (was: Re: Last Call: Use of ISO CLNP in TUBA)
In-Reply-To: Your message of Tue, 03 Aug 93 22:04:53 -0700.
<9308040504.AA26975 at Mordor.Stanford.EDU>
Date: Sun, 08 Aug 93 13:06:48 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Paul Mockapetris <pvm at arpa.mil>
Dave, et al.
I'm afraid a darker version also tracks:
We have a bunch of competing groups.
Competition will take place in the ring (technical) as well as
out of the ring (who has the most friends in the press).
The TUBA cause will be advanced by more august status (a
standard since ...) and both those who love TUBA and hate it
know that.
There are few rules in the competition, otherwise we could set
decision criteria.
There are big ego bucks (for sure) and hard currency (perhaps) at stake.
Single standards in the IETF? Hmmm. Perhaps you could point
me at the single standard for mail or information services.
Oh, they offer different features so that's OK? Aren't the IPng
different as well?
The good news may be that all of these debates might become
irrelevant. Just ask soembody over 40 about the great EBCDIC vs ASCII
debate. A uniform IP was the last good idea, the next good idea may
be different.
In any case, a process with N-1 losers and 1 winner needs constant
refereeing to make sure it doesn't get out of hand. I guess that's
the IETF's function?
paul
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08214;
9 Aug 93 11:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21062;
9 Aug 93 11:18 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08202;
9 Aug 93 11:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08011;
9 Aug 93 11:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20956;
9 Aug 93 11:13 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08001;
9 Aug 93 11:13 EDT
To: IETF-Announce: ;
Subject: JvNCnet Internet Information Services Seminar, Sept. 9
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Rochelle Hammer <hammer at r2d2.jvnc.net>
Date: Mon, 09 Aug 93 11:13:18 -0400
X-Orig-Sender: scoya at CNRI.Reston.VA.US
Message-ID: <9308091113.aa08001 at IETF.CNRI.Reston.VA.US>
GES presents the next JvNCnet Symposium in the Series
Title: Internet Information Services and Implementation Procedures
Date: Thursday, September 9, 1993
Time: 8:00am (continental breakfast) to 4:15pm
Location: Princeton Marriott Forrestal Village, Plainsboro, NJ
The Internet Information Services symposium is designed to
provide description of the functions and capabilities of very
popular network applications used to produce easier navigation of
the growing electronic highway that is filled with a continually-expanding
supply of digital data, i.e., searchable and retrievable resources. Correct
implementation instructions to establish and administer each information
service will also be presented. Speakers will present an overview,
describe how their network tool fits in with other information services,
and will detail any plans for future enhancement or any development for
new applications.
Who should attend
Network information systems specialists and computer consultants,
network technical staff including system managers of TCP/IP-based
networks responsible for managing an Internet connection, installing
and maintaining network services. People who will manage a new Internet
system or anyone new to Internet who is interested in learning about
Internet information services will benefit from attendance.
What you will learn
Participants will be able to understand the concepts of how each
application works, the extent of the application's capabilities,
and be able to properly install and maintain the service at his/her
organization using explicit instructions.
Instructors
Alan Emtage is Vice-President, R&D of Bunyip Information Systems in
Montreal, Canada. He holds Bachelor's and Master's degrees from McGill
University in Computer Science and while there was co-creator of the
service "archie". Mr. Emtage, who co-chairs two IETF working groups:
Internet Anonymous FTP Archives and Uniform Resource Identifiers, is
currently working on integration of several Internet information
systems such as WAIS, Gopher and WWW into the archie system and works
works closely with several groups in the library community on facilitating
the interoperation of Internet and library information systems.
Paul Lindner is an Application Programmer from the University of
Minnesota. As a member of "Team Gopher" he writes Unix Gopher servers
and clients and developed the first Xwindow client for Gopher. Currently
heOB is developing a suite of extensions to Gopher called "Gopher+".
Jim Fullton is Technical Director of Clearinghouse for Networked
Information Discovery and Retrieval (CNIDR), Research Triangle Park,
NC. He is involved in the development, implementation, and extension
of various networked information systems and is active in the development
of both current and new networked information standards. The CNIDR
group received a grant to maintain and continue the WAIS freeware.
AGENDA
8:00 Continental breakfast/registration
8:45 Internet Archive Server Listing (archie)
Alan Emtage, VP for R&D, Bunyip Information
Systems Inc., Dorval, Quebec, Canada
10:15 Break
10:30 Wide Area Information Server (WAIS)
Jim Fullton, Technical Dir., CNIDR,
Research Triangle Park, NC
12:00 Lunch
1:00 The Internet Gopher Protocol (gopher)
Paul Lindner, Application Programmer,
University of Minnesota, Minneapolis, MN
2:30 Break
2:45 to be announced
4:15 Adjourn
REGISTRATION
Pre-registration preferred. Check or money order payable to
Global Enterprise Services, Inc. Mastercard/Visa accepted or
fax registration to: 609-897-7310
Mail to: GES, Inc., 3 Independence Way, Princeton, NJ 08540
Email to: hammer at jvnc.net or call 609-897-7315
Early bird registration by September 3, 1993
JvNCnet members $250
Non-members $275
After September 3, 1993
JvNCnet members $295
Non-members $325
Continental breakfast, lunch, course documentation will be provided
to each attendee.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08459;
9 Aug 93 11:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08449;
9 Aug 93 11:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21310;
9 Aug 93 11:27 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08436;
9 Aug 93 11:26 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08407;
9 Aug 93 11:25 EDT
Received: from sun4nl.nluug.nl by CNRI.Reston.VA.US id aa21274;
9 Aug 93 11:25 EDT
Received: from baltzer.nl by sun4nl.nluug.nl with SMTP
id AA25346 (5.65b/CWI-3.3); Mon, 9 Aug 1993 17:25:45 +0200
Date: Mon, 9 Aug 1993 17:25:45 +0200
Message-Id: <9308091525.AA25346 at sun4nl.nluug.nl>
To: ietf at CNRI.Reston.VA.US
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Laurenz Baltzer <publish at baltzer.nl>
X-Sender: publish at baltzer.nl (Unverified)
Subject: Wireless Networks, call for papers
-------------------------------------------------------
CALL FOR PAPERS (finalized scope and editorial board)
Wireless Networks
The journal of mobile communication, computation and information
Editor-in-Chief: Professor I. Chlamtac, Department of Electrical and
Computer Engineering,
University of Massachusetts, Amherst MA 01003, USA
Aims & Scope:
The wireless communication revolution is bringing fundamental changes to
data networking, telecommunication, and is making integrated networks a
reality. By freeing the user from the cord, personal communications
networks, wireless LAN's, mobile radio networks and cellular systems,
harbor the promise of fully distributed mobile computing and
communications, any time, anywhere. Numerous wireless services are also
maturing and are poised to change the way and scope of communication. The
journal will fill an existing gap by focusing on the networking and user
aspects of this field. It will provide a single common and global forum for
archival value contributions documenting these fast growing areas of
interest.
The journal will publish refereed articles dealing with research,
experience and management issues of wireless networks. Its aim will be to
allow the reader to benefit from experience, problems and solutions
described. Regularly addressed issues will include: Network architectures
for Personal Communications Systems, wireless LAN's, radio, tactical and
other wireless networks, design and analysis of protocols, network
management and network performance, network services and service
integration, nomadic computing, internetworking with cable and other
wireless networks, standardization and regulatory issues, specific system
descriptions, applications and user interface, and enabling technologies
for wireless networks. The journal will also publish special issues devoted
to topics of particular interest to the readers. Proposals for special
issues can be submitted to the Editor-in-Chief.
Article submission:
Manuscripts must be submitted in five copies to the Editor-In-Chief:
Professor I. Chlamtac,
Department of Electrical and Computer Engineering,
University of Massachusetts,
Amherst MA 01003,
USA
All manuscripts will be refereed. The final decision of publication will be
taken by the Editor-In-Chief. Manuscripts for publication must be written
in English and typed double-spaced on one side of the page only with wide
margin. They must begin with the title, the authors' names and addresses,
and a self-contained abstract. The same manuscript must not be submitted,
in any language, for publication elsewhere. The copyright of a paper
accepted for publication transfers automatically to the Publisher. 25
reprints will be made available free of charge to authors. After acceptance
of their paper, authors are invited to send a diskette with the TEX (or
LATEX or AMS-TEX) source of their paper together with a hard copy including
the letter of acceptance to the Editor-in-Chief.
Editorial Board
Anthony S. Acampora ( Columbia University, New York, USA)
Hamid Ahmadi (IBM, Watson Research Center, Yorktown Heights NY, USA)
Ian Akyildiz (Georgia Inst. of Technology, Atlanta GA, USA)
Robert R. Boorstyn (Polytechnic Inst. of NY, New York, USA)
Magda El Zarki (Univ. of Pennsylvania, Philadelphia PA, USA)
Anthony Ephremides (Univ. of Maryland, College Park MD, USA)
Luigi Fratta (Polytecnico di Milano, Milano, Italy)
Robert Gallager (MIT, Cambridge MA, USA)
Bezalel Gavish (Vanderbilt University, Nashville TN, USA)
Zygmunt Haas (AT&T, Holmdel NJ, USA)
Pierre Humblet (Eurocom Institute, Sophia Antipolis, France)
Chih-Lin-I (AT&T, Holmdel NJ, USA)
Leonid Kazovsky (Stanford, Stanford CA, USA)
Shay Kutten (IBM, Yorktown Heights NY , USA)
Leonard Kleinrock (UCLA, Los Angeles CA, USA)
Hisashi Kobayashi (Princeton University, Princeton NJ, USA)
Victor Li (USC, Los Angeles CA, USA)
Jon Mark (Univ. of Waterloo, Waterloo ONT, Canada)
Laszlo Pap (Tech. U. Budapest, Budapest, Hungary)
P. Papantoni-Kazakos (University of Ottawa, Ontario, Canada)
Harry Perros (North Carolina State Univ., Raleigh NC, USA)
Raymond Pickholtz (George Washington Univ., Washington DC, USA)
Stephen S. Rappaport (SUNY, Stony Brook NY, USA)
Tom Robertazzi (SUNY, Stony Brook NY, USA
Raphael Rom (Technion, Haifa, Israel)
Izhak Rubin (UCLA, Los Angeles, USA)
Krishan Sabnani (AT&T, Murray Hill NJ, USA)
M. Schwartz (Columbia Univ, New York NY, USA)
Nachum Shacham (SRI Intnl, Menlo Park CA, USA)
Moshe Sidi (Technion, Haifa, Israel)
Khosrow Sohraby (IBM, Yorktown Heights NY, USA)
F.A. Tobagi (Stanford Univ., Stanford CA, USA)
Andrew J. Viterbi (Qualcomm Inc., San Diego CA, USA)
Subscription information:
Please note that the first issue of the journal will not be published
before january 1994.
Wireless Networks: Volume 1, 1994, Institutional subscription: Sfr.
370.00/US$ 274.5 together incl. postage. (The first issue will be
published in January 1994)
A personal subscription to Wireless Networks, Volume I, 1994 is available
at Sfr. 165.00/ US$ 118.00 per volume including postage. The personal
subscription is meant for private use only and may not be made available to
institutes and libraries. It must be prepaid privately and ordered directly
from J.C. Baltzer AG, Science Publishers, Wettsteinplatz 10, CH 4058 Basel,
Switzerland.
How to subscribe:
In the United States please send your order to J.C. Baltzer AG, Science
Publishers, P.O. Box 8577, Red Bank, NJ 07701-8577, USA.
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.
