[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
IPng is being driven by scaling and political pressures.
In otherwords the Rational Anarchy that is the INTERNET has become its
weakness. These issues only directly effect a few support people on the
INTERNET with a large number of other support people the victims of any
decision process.
TCP and UDP application conversion to IPng is viewed as a hack process.
When we should have learned from this process that applications must be
FULLY decoupled from the network, there is no pressure by the IPng groups
and the IETF to cause this to happen across the board. This is seen an an
IPng problem and not an Ipv4 problem. In otherwords, for example, one
person's reworking of FTP should be valid for all IPng proposals.
There is no carrot with the stick for the network endpoints.
Without a 'sell mechanism', the network endpoint support personnel will ahve
tremendous problems coming up with the dollars to convert to IPng. Their
slowness to do so could contribute further balkanization of the INTERNET.
Yes, DEC got their users to move from DEC 10s to VMS. But IBM is STILL
having to support VSE, all these years after MVT made its depute.
There has been little vision of what the Next Generation of the INTERNET
will be.
There is little sense of destiny in the INTERNET community expressed in the
IPng process. If you are building the next generation of the network
protocol, you MUST have a vision of the network it will need to support. If
you truely envision an IP connection for each Nintendo and Gensis out there,
are you designing for it? Are you moving as fast as they are on virtual
realities? What is the vision?
Now before this soapbox breaks under the weight of all of this dreaming.
I again what to see a clear plan and issues for the NEXT GENERATION of the
INTERNET!
Robert Moskowitz
MIS Tech Support
Chrysler Corporation
(313) 758-8212
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13620;
9 Aug 93 15:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13610;
9 Aug 93 15:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29087;
9 Aug 93 15:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13583;
9 Aug 93 15:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13463;
9 Aug 93 15:26 EDT
Received: from gibbs.oit.unc.edu by CNRI.Reston.VA.US id aa28984;
9 Aug 93 15:26 EDT
Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1)
id AA26358; Mon, 9 Aug 93 15:27:38 -0400
Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1)
id AA14666; Mon, 9 Aug 93 15:29:58 EDT
Message-Id: <9308091929.AA14666 at tipper>
X-Really-To: gibbs.oit.unc.edu
To: "Robert G. Moskowitz" <0003858921 at mcimail.com>
Cc: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Now is the time for radical thinking...
In-Reply-To: Your message of "Mon, 09 Aug 93 18:20:00 GMT."
<54930809182045/0003858921NA2EM at mcimail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 09 Aug 93 15:29:57 -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>
"Robert G. Moskowitz" <0003858921 at mcimail.com> writes:
>you truely envision an IP connection for each Nintendo and Gensis out there,
>are you designing for it? Are you moving as fast as they are on virtual
>realities? What is the vision?
Actually, we're just looking to put IP on the Genesis, not the Nintento. Does
that help the scaling?
Simon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13873;
9 Aug 93 15:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13862;
9 Aug 93 15:34 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29354;
9 Aug 93 15:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13849;
9 Aug 93 15:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13741;
9 Aug 93 15:32 EDT
Received: from ssd.intel.com by CNRI.Reston.VA.US id aa29219; 9 Aug 93 15:32 EDT
Received: from sv002.scic.intel.com by SSD.intel.com (4.1/SMI-4.1)
id AA26523; Mon, 9 Aug 93 12:32:55 PDT
Received: from rs042.scic.intel.com by sv002.scic.intel.com (4.1/sun41.1); Mon, 9 Aug 93 12:32:51 PDT
Received: from mc024.scic.intel.com by rs042.scic.intel.com (AIX 3.2/UCB 5.64/rs32.1); Mon, 9 Aug 1993 12:32:45 -0700
Message-Id: <9308091932.AA23103 at rs042.scic.intel.com>
Date: Mon, 9 Aug 1993 12:30:45 -0800
To: ietf at CNRI.Reston.VA.US, Peter Deutsch <peterd at bunyip.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Kevin Altis <kevin at scic.intel.com>
X-Sender: kevin at rs042.scic.intel.com
Subject: Re: Internet growth models
At 6:21 PM 8/6/93 -0400, Peter Deutsch wrote:
>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.
Peter nailed a lot of the growth issues! I have several growth issues to
comment on.
In fact, at our site rather than having a single machine serve multiple
people, each person often has multiple machines, each with its own IP
address (workstation, portable, home PC dialin, etc.). While the
workstations remain connected and communicating 24 hours a day, the
portables and home PCs could share the same "pool" of IP addresses, though
today they typically have static addresses since the machines are usually
connected to the net most of the time. Even at many academic institutions,
the model of one machine-one user or one user-many machines is becoming
common. This definitely is putting a burden on the IP address allocations.
More important though to the growth of the Internet is the usability of the
applications on the Internet. Better and more powerful interfaces to old
standards such as electronic mail and FTP has opened the Internet world to
a large percent of the PC literate population that wouldn't have touched
the Internet before. Even more profound are the graphical front ends for
gopher, USENET, and WWW. The amount a new Internet user uses the Internet
through the newer graphical tools with IP to their desktop versus running
line oriented tools on a shared Unix box or such is dramatic. So, it would
appear to me that we have an increased load from existing users spawned by
better front end tools in addition to many new users that will never see
Berkeley mail, mh, or line oriented gopher and www. Though I look forward
to real time audio, video, and other rich data types on the Internet, I
don't know if the bandwidth exists to handle these real world data types
along with the increased usage.
Once applications such as electronic mail become mission critical at a
given corporation, university, government, etc., growth will be exponential
and those mission critical tasks will not tolerate reduced usage to
accommodate a protocol transition; if necessary, the sites will disconnect
from the larger net in order to continue business as usual until a solution
exists that won't halt or slow daily business. Rather than disconnecting, I
hope sites will run multiple protocol stacks and actively encourage the use
of applications utilizing the new protocols.
I know of at least one state in the U.S.A. that plans on providing Internet
connectivity to each university, secondary school, and major library in
every city in the state. In addition, those schools and libraries will
provide dial-up access to home and business users through SLIP and PPP, so
if you have a PC at home or work, you can be connected. There are even
rumblings of real time interaction with state government committee hearings
and town hall style discussions. Whatever compromises need to be made to
support more address space, those compromises need to be made soon!
The issue of mobile growth is interesting since one of the biggest battery
drainers on notebooks, handhelds, etc. is the communications port. Mobile
connectivity today is brief for those without an AC outlet nearby and the
situation doesn't appear to be getting better. Thus for my true mobile
communications it doesn't really matter if I run a Novell, AppleTalk, IP or
any protocol stack because all I'll practically be able to do is get and
send electronic mail, synchronize my calendar, and maybe pick up a small
file or two; these store and forward operations will be part of every major
desktop OS independent of a specific protocol stack and the applications
will interact through an OS API not direct IP, Novell, etc. I'm not going
sit and read news or work with ftp, gopher, www, etc. online. Mobility then
turns into moving workstations around without having to change addresses or
taking portables (with Ethernet and AC hookups) to different sites across
town or across continents and still be able to use all the Internet
services; today I do that by dialing into my "home" site rather than
hooking into the local network.
Kevin Altis
Intel Corporation
SuperComputer Systems Division
Beaverton, Oregon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14430;
9 Aug 93 15:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14420;
9 Aug 93 15:46 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29992;
9 Aug 93 15:46 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14396;
9 Aug 93 15:46 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14208;
9 Aug 93 15:44 EDT
Received: from Valinor.Stanford.EDU by CNRI.Reston.VA.US id aa29833;
9 Aug 93 15:44 EDT
Received: by Valinor.Stanford.EDU (5.65/inc-1.0)
id AA08929; Mon, 9 Aug 93 12:45:07 -0700
Date: Mon, 9 Aug 93 12:45:06 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Vince Fuller <vaf at valinor.stanford.edu>
To: "Robert G. Moskowitz" <0003858921 at mcimail.com>
Cc: ietf <ietf at CNRI.Reston.VA.US>
Office: Spruce Hall F15, (415) 723-6860
Usmail: Pine Hall 115, Stanford, CA, 94305-4122
Subject: Re: Now is the time for radical thinking...
In-Reply-To: Your message of Mon, 9 Aug 93 18:20 GMT
Message-Id: <CMM.0.90.2.744925506.vaf at Valinor.Stanford.EDU>
Without a 'sell mechanism', the network endpoint support personnel will
have tremendous problems coming up with the dollars to convert to IPng.
Their slowness to do so could contribute further balkanization of the
INTERNET. Yes, DEC got their users to move from DEC 10s to VMS. But IBM
is STILL having to support VSE, all these years after MVT made its depute.
This is one of the major problems I have with a CLNP-based solution. If I'm
not mistaken, host (aka "end-system") CLNP software costs substantial $$$ -
compare this with TCP/IP, which comes bundled-in on all workstations built and
sold today, and you'll find one likely reason why CLNP represents not even a
minescule fraction of traffic on the Internet, even on the portion which can
be claimed to be capable of routing CLNP.
I would hope that any IPng solution is bundled with workstation system software
much the same as TCP/IP is now.
As an aside: DEC did get *some* of their users to move from DEC-10s (and '20s)
to VMS, but probably a lot more of them moved to Suns instead (speaking as a
former TOPS-20 systems person, aka dinosaur keeper...)
--Vince
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15430;
9 Aug 93 16:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15419;
9 Aug 93 16:16 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01191;
9 Aug 93 16:16 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15406;
9 Aug 93 16:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15313;
9 Aug 93 16:14 EDT
Received: from black-ice.cc.vt.edu by CNRI.Reston.VA.US id aa01099;
9 Aug 93 16:14 EDT
Received: by black-ice.cc.vt.edu (AIX 3.2/UCB 5.64/4.03)
id AA18731; Mon, 9 Aug 1993 16:15:11 -0400
Message-Id: <9308092015.AA18731 at black-ice.cc.vt.edu>
To: "Robert G. Moskowitz" <0003858921 at mcimail.com>
Cc: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Now is the time for radical thinking...
In-Reply-To: Your message of "Mon, 09 Aug 1993 18:20:00 EST."
<54930809182045/0003858921NA2EM at mcimail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 09 Aug 1993 16:15:10 +22312049
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Valdis Kletnieks <valdis at black-ice.cc.vt.edu>
On Mon, 09 Aug 1993 18:20:00 EST, you said:
> TCP and UDP application conversion to IPng is viewed as a hack process.
>
> When we should have learned from this process that applications must be
> FULLY decoupled from the network, there is no pressure by the IPng groups
> and the IETF to cause this to happen across the board. This is seen an an
> IPng problem and not an Ipv4 problem. In otherwords, for example, one
> person's reworking of FTP should be valid for all IPng proposals.
Robert: I tend to agree with most of the other points you make,
but there's a slight logic flaw here. The problem is that it's
very difficult to 'fully decouple'. Consider - what would
happen to everything if VTAM/SNA were selected as the IPng?
Part of the reason why conversion to IPng is seen as a "hack process"
is because it's so damned difficult to devise a networking protocol
that doesn't have any impact on what the API looks like. For instance,
if you're using VTAM, you have LUs in your BIND requests. If you're
using IP, you have 32-bit IP addresses.. and so on.
Now, if somebody had an API that was protocol-transparent.....
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18173;
9 Aug 93 18:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18163;
9 Aug 93 18:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07068;
9 Aug 93 18:52 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18153;
9 Aug 93 18:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18126;
9 Aug 93 18:50 EDT
Received: from KOREA-EMH1.ARMY.MIL by CNRI.Reston.VA.US id aa06944;
9 Aug 93 18:50 EDT
Date: Mon, 9 Aug 93 21:41:28 GMT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Staggsd at korea-emh1.army.mil
To: ietf at CNRI.Reston.VA.US
Subject: Unsubscribe
Message-ID: <9308092141.aa04193 at host.korea-emh1.army.mil>
Please unsubscribe from IETF list.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18644;
9 Aug 93 19:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18634;
9 Aug 93 19:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08568;
9 Aug 93 19:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18624;
9 Aug 93 19:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18596;
9 Aug 93 19:49 EDT
Received: from worldlink.com by CNRI.Reston.VA.US id aa08527; 9 Aug 93 19:49 EDT
Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink)
id AA15996; Mon, 9 Aug 93 19:50:48 -0400
Date: Mon, 9 Aug 93 19:50:48 -0400
Message-Id: <9308092350.AA15996 at worldlink.worldlink.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Bachmann <wk01200 at worldlink.com>
To: Valdis Kletnieks <valdis at black-ice.cc.vt.edu>
Cc: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Now is the time for radical thinking...
> Now, if somebody had an API that was protocol-transparent.....
DCE?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19568;
9 Aug 93 20:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19558;
9 Aug 93 20:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa10756;
9 Aug 93 20:58 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19548;
9 Aug 93 20:58 EDT
Received: from eagle.nersc.gov by IETF.CNRI.Reston.VA.US id aa19512;
9 Aug 93 20:56 EDT
Date: Mon, 9 Aug 1993 17:57:44 -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: <930809175744.6a at EAGLE.ES.NET>
Subject: Re: Now is the time for radical thinking...
To: ietf at IETF.CNRI.Reston.VA.US
X-Vmsmail-To: SMTP%"ietf at ietf.nri.reston.va.us"
Vince,
Pricing tactics have no basis on reality. As soon as the IPng (whatever it is)
is "standardized", it will be bundled and continued IPv4 support will cost extra.
Vendors are providing a box that is "ready to run" and anything more will cost.
As I reflected on the IPng discussions this past weekend it occurred to me that
there is a great irony here. We have a vocal group wanting to pick the one true
IPng based on demonstrated deployment and use (as opposed to the ISO way of
picking then defining). At the same time this vocal group wants to pick something
that it can define (while ignoring the demonstrated deployment and use of an
existing protocol).
Mixing and pouring over a ton of cement gives one lots of time to reflect....
Tony
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20349;
9 Aug 93 22:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20339;
9 Aug 93 22:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13687;
9 Aug 93 22:11 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20326;
9 Aug 93 22:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20296;
9 Aug 93 22:09 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa13656;
9 Aug 93 22:10 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA01635; Mon, 9 Aug 93 19:10:38 -0700
Message-Id: <9308100210.AA01635 at Mordor.Stanford.EDU>
To: Dave Bachmann <wk01200 at worldlink.com>
Cc: Valdis Kletnieks <valdis at black-ice.cc.vt.edu>,
ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Now is the time for radical thinking...
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Mon, 09 Aug 93 19:50:48 -0400. <9308092350.AA15996 at worldlink.worldlink.com>
Date: Mon, 09 Aug 93 19:10:38 -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
---- Included message:
> Now, if somebody had an API that was protocol-transparent.....
DCE?
Not!
d/
P.S. The term 'protocol independent' is mostly a mis-reference. We can
probably define an abstraction layer for any given service level, so that
"TRANSPORT" independence might be obtained. But DCE, for example, hides
the transport layer by giving you a DCE-specific remote procedural call
protocol interface. And that interface, of course, is not idependent of
the procedure call protocol being used...
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24025;
9 Aug 93 23:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24015;
9 Aug 93 23:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14859;
9 Aug 93 23:11 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24001;
9 Aug 93 23:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23946;
9 Aug 93 23:10 EDT
Received: from OPAL.ACC.COM by CNRI.Reston.VA.US id aa14832; 9 Aug 93 23:10 EDT
Received: by opal.acc.com (4.1/SMI-4.0)
id AA29159; Mon, 9 Aug 93 19:06:24 PDT
Date: Mon, 9 Aug 93 19:06:24 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Art Berggreen <art at opal.acc.com>
Message-Id: <9308100206.AA29159 at opal.acc.com>
To: 0003858921 at mcimail.com, vaf at valinor.stanford.edu
Subject: Re: Now is the time for radical thinking...
Cc: ietf at CNRI.Reston.VA.US
>
>This is one of the major problems I have with a CLNP-based solution. If I'm
>not mistaken, host (aka "end-system") CLNP software costs substantial $$$ -
>compare this with TCP/IP, which comes bundled-in on all workstations built and
>sold today, and you'll find one likely reason why CLNP represents not even a
>minescule fraction of traffic on the Internet, even on the portion which can
>be claimed to be capable of routing CLNP.
>
>I would hope that any IPng solution is bundled with workstation system software
>much the same as TCP/IP is now.
This will be an interesting story to watch. With the death of the Berkeley
Unix Group and the establishment of TCP/IP networking as BIG BUSINESS, it
will be interesting to see if history repeats itself with respect to IPng.
Just as easy to believe, is that each vendor will attempt to implement by
themselves (for several reasons) and charge the same level of $$$ that
CLNS solutions cost today.
Art
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28861;
10 Aug 93 1:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28851;
10 Aug 93 1:56 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18026;
10 Aug 93 1:56 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28840;
10 Aug 93 1:56 EDT
Received: from uicvm.uic.edu by IETF.CNRI.Reston.VA.US id aa28815;
10 Aug 93 1:55 EDT
Received: from UICVM by UICVM.UIC.EDU (IBM VM SMTP V2R1) with BSMTP id 4752;
Tue, 10 Aug 93 00:55:34 CDT
Received: from UICVM (U54136) by UICVM (Mailer R2.07) with BSMTP id 6018; Tue,
10 Aug 93 00:55:34 CDT
Date: Tue, 10 Aug 93 00:54:15 CDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Charles Southern <U54136 at uicvm.uic.edu>
Subject: UNSUBSCRIBE
To: ietf at IETF.CNRI.Reston.VA.US
Message-ID: <9308100155.aa28815 at IETF.CNRI.Reston.VA.US>
Please remove from all distribution lists of IETF.
Thank you, Charles Southern U54136 at UICVM.UIC.EDU
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08554;
10 Aug 93 8:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08544;
10 Aug 93 8:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02046;
10 Aug 93 8:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08504;
10 Aug 93 8:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab08430;
10 Aug 93 8:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ai01886;
10 Aug 93 8:00 EDT
Received: from mcigateway.mcimail.com by IETF.CNRI.Reston.VA.US id ab06139;
10 Aug 93 7:24 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ag21058;
10 Aug 93 11:18 GMT
Date: Tue, 10 Aug 93 11:23 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: Simon E Spero <ses at tipper.oit.unc.edu>
Cc: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Now is the time for radical thinking...
Message-Id: <64930810112346/0003858921NA2EM at mcimail.com>
I said:
>Forget about toaster-net. We're going to have Hedgehog-net! Then
>networked virtual reality... This is the Next Generation that I see.
>And I had another set of thoughts about the Next Generation. MIME is well
>suited for more mail-enabled ablications. Now it SHOULD be easy for any
>Tom, Dick, or Mary Doe programmer to add the functionality. What whould it
>be like to play Battle Chess across the Net?
I left out that lots of homes that have Genesis systems tend to have cable
TV. If those CAT people got smart and worked out a way to use that
broadband network to every home for IP traffic, oh boy, do we have network
sizing problems.
Just visualize it:
"For an extra $10 a month you too can get USENET news feeds on any subject
you want! Or play battle chess with a friend across the country! All you
need in your home computer, is this nifty $299 interface card that you MUST
buy from us to insure compatiblity and a low $100 installation and hookup
fee. This is a one time offer, so hurry. Be the first on your block to get
ALL the news." BTW, I do not own a TV, let alone Cable TV, juck.
Bob Moskowitz
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08570;
10 Aug 93 8:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08560;
10 Aug 93 8:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02054;
10 Aug 93 8:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08506;
10 Aug 93 8:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08422;
10 Aug 93 8:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ah01886;
10 Aug 93 8:00 EDT
Received: from mcigateway.mcimail.com by IETF.CNRI.Reston.VA.US id aa06139;
10 Aug 93 7:24 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ac21058;
10 Aug 93 11:18 GMT
Date: Tue, 10 Aug 93 11:23 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: Now is the time for radical thinking...
Message-Id: <52930810112325/0003858921NA2EM at mcimail.com>
Valdis Kletnieks said:
>Robert: I tend to agree with most of the other points you make,
>but there's a slight logic flaw here. The problem is that it's
>very difficult to 'fully decouple'. Consider - what would
>happen to everything if VTAM/SNA were selected as the IPng?
Ugh, do you forget my environment ;->
Oh did you read:
"A Plea For Internet Peace", in CONNEXIONS: The
Interoperability Report, Advanced Computing Environments,
Volume 1, No, 5, September 1987 pp. 13-15.
It was sent on this list on April 8, 1993...
If you did, you would see an opinion that would show why VTAM/SNA is not an
IPng canidate. Now APPN on the other hand...
>Part of the reason why conversion to IPng is seen as a "hack process"
>is because it's so damned difficult to devise a networking protocol
>that doesn't have any impact on what the API looks like. For instance,
>if you're using VTAM, you have LUs in your BIND requests. If you're
>using IP, you have 32-bit IP addresses.. and so on.
Tell me about it. I have the joy of sticking my neck out and becoming the
chair of the TN3270 Enhancements working group. This is one of the items
that we have to address in the rework of TN3270...
>Now, if somebody had an API that was protocol-transparent.....
Rather, I think it will be a transport API spec that each transport can
develop libraries for. So if some smart engineer would start out defining
what an application needs to know about the transport layer, then define the
calls in a spec, each of the IPng groups could develop their API
implementation. Each application group could change their app to use the
API. Then we could REALLY test deployment of each of these proposals.
Look at the GSSAPI that the security groups did. It seems like a good
start. Their intention (based on the INTEROP course that I took at Spring
'92 INTEROP) was to allow apps to be unaware of which security technology
was used (out of a small group of such, of course).
Robert Moskowitz
MIS Tech Services
Chrysler Corporation
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08598;
10 Aug 93 8:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08576;
10 Aug 93 8:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02058;
10 Aug 93 8:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08510;
10 Aug 93 8:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08252;
10 Aug 93 7:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id ac01660;
10 Aug 93 7:59 EDT
Received: from mcigateway.mcimail.com by IETF.CNRI.Reston.VA.US id aa00836;
10 Aug 93 6:20 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id aa19361;
10 Aug 93 10:11 GMT
Date: Tue, 10 Aug 93 10:16 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: Simon E Spero <ses at tipper.oit.unc.edu>
Cc: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Now is the time for radical thinking...
Message-Id: <54930810101645/0003858921NA4EM at mcimail.com>
I said:
>>you truely envision an IP connection for each Nintendo and Gensis out
>>there, are you designing for it? Are you moving as fast as they are on
>>virtual realities? What is the vision?
Simon Spero replied:
>Actually, we're just looking to put IP on the Genesis, not the Nintento.
>Does that help the scaling?
See?
Forget about toaster-net. We're going to have Hedgehog-net! Then networked
virtual reality... This is the Next Generation that I see.
And I had another set of thoughts about the Next Generation. MIME is well
suited for more mail-enabled ablications. Now it SHOULD be easy for any
Tom, Dick, or Mary Doe programmer to add the functionality. What whould it
be like to play Battle Chess across the Net?
Bob Moskowitz
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08597;
10 Aug 93 8:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08577;
10 Aug 93 8:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02057;
10 Aug 93 8:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08509;
10 Aug 93 8:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08437;
10 Aug 93 8:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aj01886;
10 Aug 93 8:00 EDT
Received: from mcigateway.mcimail.com by IETF.CNRI.Reston.VA.US id aa06322;
10 Aug 93 7:25 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id af21058;
10 Aug 93 11:18 GMT
Date: Tue, 10 Aug 93 11:23 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: Now is the time for radical thinking...
Message-Id: <53930810112335/0003858921NA2EM at mcimail.com>
>>> Now, if somebody had an API that was protocol-transparent.....
>>DCE?
Dave Crocker said:
>Not!
>P.S. The term 'protocol independent' is mostly a mis-reference. We can
>probably define an abstraction layer for any given service level, so that
>"TRANSPORT" independence might be obtained. But DCE, for example, hides
>the transport layer by giving you a DCE-specific remote procedural call
>protocol interface. And that interface, of course, is not idependent of
>the procedure call protocol being used...
But is the DCE spec RPC general enough that it can be implemented for other
transports? Is it a good working model for the transport API spec that we
need?
As Tony Hain pinted out. We want demonstratable deployments. Is DCE's
deployment demonstarting that a transport API spec can be defined?
Robert Moskowitz
MIS Tech Support
Chrysler Corp
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10119;
10 Aug 93 8:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10109;
10 Aug 93 8:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03753;
10 Aug 93 8:44 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10096;
10 Aug 93 8:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10029;
10 Aug 93 8:42 EDT
Received: from PIGPEN.AUSTIN.NAM.SLB.COM by CNRI.Reston.VA.US id aa03614;
10 Aug 93 8:42 EDT
Received: from fugu (FUGU.AUSTIN.NAM.SLB.COM) by austin.nam.slb.com (4.1/relay.930728)
id AA04714; Tue, 10 Aug 93 07:41:34 CDT
Received: by fugu (AIX 3.2/UCB 5.64/client.nfs.930802)
id AA16907; Tue, 10 Aug 1993 07:39:37 -0500
Date: Tue, 10 Aug 1993 07:39:37 -0500
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: guthery at austin.slcs.slb.com
Message-Id: <9308101239.AA16907 at fugu>
To: ietf at CNRI.Reston.VA.US, com-priv at psi.com
Subject: Commodity Communication
Toasters! Nintendos! Why such MIP macho? How about electric meters?
Metricom, the meter reading people, will sell you a 56Kbps connection for
$19.95/month. To rich for your blood? How about 2.4Kbps for $2.95/month?
Now we're starting to talk commodity communication.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11787;
10 Aug 93 9:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11777;
10 Aug 93 9:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06460;
10 Aug 93 9:50 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11765;
10 Aug 93 9:50 EDT
Received: from GINGER.LCS.MIT.EDU by IETF.CNRI.Reston.VA.US id aa11734;
10 Aug 93 9:48 EDT
Received: by ginger.lcs.mit.edu
id AA08725; Tue, 10 Aug 93 09:49:00 -0400
Date: Tue, 10 Aug 93 09:49: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: <9308101349.AA08725 at ginger.lcs.mit.edu>
To: ALH at eagle.es.net, ietf at IETF.CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
Cc: jnc at ginger.lcs.mit.edu
As I reflected on the IPng discussions this past weekend it occurred to me
I too, had a (short :-) thought, and your message provided a reasonably good
hook for it, so here goes...
wanting to pick the one true IPng based on demonstrated deployment and
use... while ignoring the demonstrated deployment and use of an existing
protocol
My thought had to do with the value of "deployed base". This is an essentially
short-term reason to prefer one option; in 15 years it will be irrelevant (in
terms of how well it works, and meets users' needs at that point) how large the
deployed base of the preferred option was now.
I'm a long-term person; I acknowledge that short-term issues cannot be ignored,
but in my decision making the long-term factors weigh much heavier. I don't
know how everyone else comes down on this, but differences here are probably
one more reason people come up with varying choices for IPng.
In this context, the apparent contradiction you point out makes a little more
sense. People want to design something new, since a new thing, with the benfit
of current thinking on things like flows, resource allocation, mobility, header
processing, etc, is a little more likely to wear better in the long run;
however, they don't trust such a new thing without some demonstrated usage, to
make sure it works. The existing deployment, on the other hand, counts for
less, since in the long run it won't be very important.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13329;
10 Aug 93 10:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13316;
10 Aug 93 10:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08712;
10 Aug 93 10:52 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13297;
10 Aug 93 10:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13232;
10 Aug 93 10:50 EDT
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa08606;
10 Aug 93 10:50 EDT
Received: from goshawk.lanl.gov by mailhost.lanl.gov (5.65/1.14)
id AA12269; Tue, 10 Aug 93 08:50:48 -0600
Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17)
id AA05129; Tue, 10 Aug 93 08:50:57 MDT
Message-Id: <9308101450.AA05129 at goshawk.lanl.gov>
To: ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
Date: Tue, 10 Aug 93 08:50:57 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
It would be interesting to see how much IP network product is directly
paid for (FTP software, Intercon, Versaterm w/IPetc.) vrs. how much is
bundled in to delivered platforms. Here at Los Alamos, I would say it is
about even when counted in terms of the number of hosts.
It is probably safe to say that the cost of an IPng software package will
be fairly inexpensive if it is going to be sold into a market of
10's (100's?) of millions of units. Even CLNP will probably be
cheap, or even bundled in, at that point.
cheers,
peter
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14011;
10 Aug 93 11:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14002;
10 Aug 93 11:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09870;
10 Aug 93 11:21 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13974;
10 Aug 93 11:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13968;
10 Aug 93 11:21 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa09853;
10 Aug 93 11:21 EDT
Received: by ginger.lcs.mit.edu
id AA10468; Tue, 10 Aug 93 11:21:59 -0400
Date: Tue, 10 Aug 93 11:21:59 -0400
X-Orig-Sender:iesg-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Message-Id: <9308101521.AA10468 at ginger.lcs.mit.edu>
To: iesg at CNRI.Reston.VA.US, ietf at CNRI.Reston.VA.US,
taniguti at nwk.cl.nec.co.jp
Subject: Re: Last Call: CIDR Documents to Proposed Standard
Cc: jnc at ginger.lcs.mit.edu
In case that a router receives a ICMP NETWORK REDIRECT packet, what should
the router do? ... If in CIDR environment, the router may not know
supernet-mask (not subnet-mask) and make a mistake. ... 1. NETMASK REQUEST
is for subnet-mask, not for supernet-mask.
First, as Tony Li points out, routers should not be using ICMP Redirects for
getting routing information.
Second, to your implicit question "how do we deal with ICMP Network Redirects
in the CIDR environment", the answer is "we do not, because they are
obsolescent". In the evolving IP routing model, hosts are less and less
involved in the routing, and all the "Network" ICMP messages (as opposed to
"Host" messages, be they Redirects, Unreachables, or whatever) are
obsolescent, since we want to lessen the amount hosts know about what
addresses mean, and simply think of them as 32-bit quantities; hosts deal
with everything on a host-by-host basis, not as aggregates of any kind.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15323;
10 Aug 93 12:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15303;
10 Aug 93 12:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12268;
10 Aug 93 12:07 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15280;
10 Aug 93 12:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15204;
10 Aug 93 12:04 EDT
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa12142;
10 Aug 93 12:04 EDT
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12871>; Tue, 10 Aug 1993 09:05:05 PDT
Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 10 Aug 1993 09:04:55 -0700
To: ietf <ietf at CNRI.Reston.VA.US>
Cc: deering at parc.xerox.com
Subject: Re: Now is the time for radical thinking...
In-reply-to: Your message of "Tue, 10 Aug 93 04:23:00 PDT."
<64930810112346/0003858921NA2EM at mcimail.com>
Date: Tue, 10 Aug 1993 09:04:39 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: <93Aug10.090455pdt.12171 at skylark.parc.xerox.com>
Hooking up all the toasters, Nintendos, and electical meters in the world to
the Internet should not present any particular scaling problem for any of
the IPng candidates. As far as routing scaling goes, those devices will
be allocated addresses within larger aggregates (e.g., service-provider
aggregates or sub-aggregates) and will have no impact on wide-area routing.
As far as address-space scaling goes, a 64-bit hierarchical address space
can comfortably accommodate tens of thousands of globally-addressable devices
in every household in the world (see my article in the May/93 issue of IEEE
Network for a simple analysis). I'm interested in hearing of potential
applications that might exceed that limit. For example, if nanotechnology
really takes off, maybe every person will have millions of IPng-addressable
nano-devices floating around in his or her bloodstream. (But then, would
he or she want all of those devices to be reachable from anywhere in the
Internet?)
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15322;
10 Aug 93 12:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15302;
10 Aug 93 12:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12267;
10 Aug 93 12:07 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15283;
10 Aug 93 12:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15217;
10 Aug 93 12:05 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa12201;
10 Aug 93 12:05 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA17511; Tue, 10 Aug 93 09:05:47 -0700
Message-Id: <9308101605.AA17511 at Mordor.Stanford.EDU>
To: "Robert G. Moskowitz" <0003858921 at mcimail.com>
Cc: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Now is the time for radical thinking...
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Tue, 10 Aug 93 11:23:00 +0000. <64930810112346/0003858921NA2EM at mcimail.com>
Date: Tue, 10 Aug 93 09:05:46 -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
At the Open IAB meeting, during the discussion about IPng, I commented
that
a) Microsoft NT is shipping with TCP. I don't know the exact
number of millions of machines this makes, but 60 sounds about
right;
b) At the Amsterdam IETF meeting, a member of a consumer
electronics consortium was present. One assumes this was not a
social visit. Consumer electronic people view sales of 100K
units/month to be low;
c) Interactive Cable experiments -- such as the Time-Warner
Orlando project with which I have some contact -- seem obvious
candidates for IP connectivity. The bandwidth is, if anything,
the trivial factor.
In other words, hundreds of millions IP nodes and tens of millions (or
maybe even hundreds of millions) of IP nets is a highly reasonable
projection over the next 5-10 years. Images like toasternet should no
longer be treated as fantasies.
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15679;
10 Aug 93 12:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15669;
10 Aug 93 12:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13029;
10 Aug 93 12:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15644;
10 Aug 93 12:16 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15602;
10 Aug 93 12:15 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa12970;
10 Aug 93 12:15 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA17793; Tue, 10 Aug 93 09:15:51 -0700
Message-Id: <9308101615.AA17793 at Mordor.Stanford.EDU>
To: "Robert G. Moskowitz" <0003858921 at mcimail.com>
Cc: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Now is the time for radical thinking...
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Tue, 10 Aug 93 11:23:00 +0000. <53930810112335/0003858921NA2EM at mcimail.com>
Date: Tue, 10 Aug 93 09:15:50 -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
---- Included message:
But is the DCE spec RPC general enough that it can be implemented for other
I believe that it can/has run over transports other than TCP. But I
don't believe that is an interesting demonstration, since it still locks you
in to the DCE RPC. Sun's RPC is derived from Xerox's XNS and it used to
run over a connection protocol. There now is a running Sun RPC over TCP.
This is useful, but has nothing to do with application independence. The
application is still tied to the protocol that it is talking directly to.
transports? Is it a good working model for the transport API spec that we
need?
It is NOT a model for a transport API spec. It is a concete spec for working
with ONE (not more) RPC protocols. There was no effort to make it be
suitable for other RPC protocols. Application independence of all
underlying protocols wasn't a goal. Just independence from specific transport
protocols. But this was accomplished by adding another protocol layer.
sigh.
As Tony Hain pinted out. We want demonstratable deployments. Is DCE's
deployment demonstarting that a transport API spec can be defined?
Nope. It has nothing to do with such a goal.
D/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15774;
10 Aug 93 12:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15764;
10 Aug 93 12:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13088;
10 Aug 93 12:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15753;
10 Aug 93 12:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15685;
10 Aug 93 12:17 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa13042;
10 Aug 93 12:17 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA17829; Tue, 10 Aug 93 09:17:51 -0700
Message-Id: <9308101617.AA17829 at Mordor.Stanford.EDU>
To: peter at goshawk.lanl.gov
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Tue, 10 Aug 93 08:50:57 -0700. <9308101450.AA05129 at goshawk.lanl.gov>
Date: Tue, 10 Aug 93 09:17:51 -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
Peter,
---- Included message:
Even CLNP will probably be
cheap, or even bundled in, at that point.
To my knowledge, this has not been the pattern of pricing for OSI products
at any time so far. What will make that change?
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16812;
10 Aug 93 12:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16802;
10 Aug 93 12:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14973;
10 Aug 93 12:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16786;
10 Aug 93 12:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16762;
10 Aug 93 12:50 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa14907; 10 Aug 93 12:50 EDT
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA12210; Tue, 10 Aug 93 09:51:09 PDT
Received: from pepper.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA25700; Tue, 10 Aug 93 09:51:08 PDT
Received: from yikes.Eng.Sun.COM by pepper.Eng.Sun.COM (4.1/SMI-4.1)
id AA18779; Tue, 10 Aug 93 09:55:24 PDT
Date: Tue, 10 Aug 93 09:55:23 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Chuck McManis <Chuck.McManis at eng.sun.com>
Message-Id: <9308101655.AA18779 at pepper.Eng.Sun.COM>
To: ietf at CNRI.Reston.VA.US, 0003858921 at mcimail.com
Subject: Re: Now is the time for radical thinking...
X-Sun-Charset: US-ASCII
>But is the DCE spec RPC general enough that it can be implemented for other
>transports? Is it a good working model for the transport API spec that we
>need?
Hmm, well I work for Sun so understand that I'm biased but I don't believe
the DCE spec is anywhere close to allowing you to run it over anything but
IP underlayers. Now the Source for Sun's RPC implementation is available
from various archive sites (ask archie) and the "TI-RPC" version (transport
independent) is in fact designed to work over other stacks. AT&T was
running it over starlan, datakit?, and OSI. Novell runs it over their
protocols, and of course it still runs over TCP and UDP. Haven't tried
running it over uucp though :-).
--Chuck
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17176;
10 Aug 93 13:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17166;
10 Aug 93 13:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15454;
10 Aug 93 13:07 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17150;
10 Aug 93 13:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17121;
10 Aug 93 13:06 EDT
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa15426;
10 Aug 93 13:06 EDT
Received: from goshawk.lanl.gov by mailhost.lanl.gov (5.65/1.14)
id AA01288; Tue, 10 Aug 93 11:06:40 -0600
Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17)
id AA07127; Tue, 10 Aug 93 11:06:49 MDT
Message-Id: <9308101706.AA07127 at goshawk.lanl.gov>
To: Dave Crocker <dcrocker at mordor.stanford.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
In-Reply-To: Your message of Tue, 10 Aug 93 09:17:51 -0700.
<9308101617.AA17829 at Mordor.Stanford.EDU>
Date: Tue, 10 Aug 93 11:06:48 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
>>> To my knowledge, this has not been the pattern of pricing for OSI products
>>> at any time so far. What will make that change?
d/,
(Please excuse me, while I get onto my herring fishing vessel and tune
the detectors for red.)
When I took microecon I don't remember them mentioning standards bodies
as part of price equilibria. Pricing is not a function of what an
object is (or where it came from), it is a function of value within a
market. I suspect if CLNP were as important to workstation vendors in
the delivery of their software tools as IP is today, you would see
them bundle it in.
As we see today, many workstation vendors no longer see much value in
bundling a C compiler as part of their delivered software product and now sell
it as a value added product. Does this imply that C is going the way
of OSI?
I suspect if one looked hard enough one might see a relationship
between end system pricing of OSI products and total volume of sales.
Let's not forget that over one half of the routers sold today have
CLNP support bundled in.
putting on my waders,
peter
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17319;
10 Aug 93 13:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17309;
10 Aug 93 13:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15655;
10 Aug 93 13:12 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17298;
10 Aug 93 13:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17255;
10 Aug 93 13:11 EDT
Received: from gw.atria.com by CNRI.Reston.VA.US id aa15579; 10 Aug 93 13:11 EDT
Received: from pluto ([192.88.237.52]) by gw.atria.com id <AA12824 at gw.atria.com> Tue, 10 Aug 93 13:11:59 EDT
Received: by pluto (1.37.109.4/920526.BPD)
(for 0003858921 at mcimail.com) id AA01850; Tue, 10 Aug 93 13:10:06 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Nathaniel Mishkin <mishkin at atria.com>
Message-Id: <9308101710.AA01850 at pluto>
Date: Tue, 10 Aug 93 13:10:06 EDT
Subject: Re: Now is the time for radical thinking...
To: Dave Crocker <dcrocker at mordor.stanford.edu>
Cc: "Robert G. Moskowitz" <0003858921 at mcimail.com>,
ietf <ietf at CNRI.Reston.VA.US>
In-Reply-To: Dave Crocker <dcrocker at mordor.stanford.edu>, Tue, 10 Aug 93 09:15:50 -0700
It is NOT a model for a transport API spec. It is a concete spec for working
with ONE (not more) RPC protocols. There was no effort to make it be
suitable for other RPC protocols. Application independence of all
underlying protocols wasn't a goal. Just independence from specific transport
protocols. But this was accomplished by adding another protocol layer.
Actually, a fair bit of effort was made to make DCE RPC's service
definition be independent of both particular RPC and transport level
protocols. In fact, DCE RPC service interface currently runs over two
RPC protocols and several transport protocols. (One RPC protocol is
for running over CLTPs and one for running over COTPs; the RPC service
definition--the RPC call semantics--are the same for both RPC
protocols.) Of course the two RPC protocols and the service
definition were created by the same group of people at roughly the
same time, so clearly it's not as if this is strong proof that the
definition is independent of all RPC protocols. In fact, almost
certainly it is not since the characteristics of what people consider
to be an RPC service definition vary quite widely. For example, DCE
RPC's service definition includes a feature called "context handles"
for allowing servers to easily maintain state on behalf of clients in
between calls from that client to that server. Realizing this feature
requires some degree of RPC-level protocol support. Thus, DCE RPC's
service definition is not a layer that hides all the differences
across all RPC protocols.
Probably the best way to think about what we were trying to achieve in
the DCE RPC service definition was (a) to make it not _impossible_ to
use some other "appropriate" RPC protocol under the the DCE RPC
service interface, and (b) to make it possible and relatively easy to
define new RPC protocols that took into consideration the DCE RPC
service definition.
-- Nat Mishkin
Atria Software, Inc.
mishkin at atria.com
-------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17770;
10 Aug 93 13:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17760;
10 Aug 93 13:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16277;
10 Aug 93 13:27 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17746;
10 Aug 93 13:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17692;
10 Aug 93 13:26 EDT
Received: from optics.wc.novell.com by CNRI.Reston.VA.US id aa16121;
10 Aug 93 13:26 EDT
Received: from by wc.novell.com (4.1/smi4.1.1.v91190)
id AB07481; Tue, 10 Aug 93 10:18:10 PDT
Date: Tue, 10 Aug 93 10:18:10 PDT
Message-Id: <9308101718.AB07481 at wc.novell.com>
To: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: minshall at wc.novell.com
X-Sender: minshall at optics.wc.novell.com
Subject: Re: was Last Call: ...what you can and can't do in IPv4
Cc: ietf at CNRI.Reston.VA.US
Jon,
>how about admitting that you cannot do flows multicast or mobility
>_efficiently_ in ipv4.
Or in any other place as well, with our current knowledge (so claim i)!
I don't see this stuff as being IPvX dependent. I think we just don't know
how to do it yet. We are, presumably, learning (there are signs).
(And, i for one would be quite happy to delay IPtng until we actually know
how to do these, either in IPv4 or what it would take to do them in IPtng
and had an IPtng that did them right.)
>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.
I think that using IPv4 as a mark with which to measure the scalability of
these new "things" is exactly right on! Thank you!
Greg Minshall
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17919;
10 Aug 93 13:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17904;
10 Aug 93 13:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16474;
10 Aug 93 13:30 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17885;
10 Aug 93 13:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17791;
10 Aug 93 13:28 EDT
Received: from gw.atria.com by CNRI.Reston.VA.US id aa16356; 10 Aug 93 13:28 EDT
Received: from pluto ([192.88.237.52]) by gw.atria.com id <AA13002 at gw.atria.com> Tue, 10 Aug 93 13:29:59 EDT
Received: by pluto (1.37.109.4/920526.BPD)
(for ietf at CNRI.Reston.VA.US) id AA01908; Tue, 10 Aug 93 13:28:06 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Nathaniel Mishkin <mishkin at atria.com>
Message-Id: <9308101728.AA01908 at pluto>
Date: Tue, 10 Aug 93 13:28:06 EDT
Subject: Re: Now is the time for radical thinking...
To: Chuck McManis <Chuck.McManis at eng.sun.com>
Cc: ietf at CNRI.Reston.VA.US, 0003858921 at mcimail.com
In-Reply-To: Chuck McManis <Chuck.McManis at eng.sun.com>, Tue, 10 Aug 93 09:55:23 PDT
Hmm, well I work for Sun so understand that I'm biased but I don't believe
the DCE spec is anywhere close to allowing you to run it over anything but
IP underlayers.
Absolutely false. DCE RPC has run over DECnet as well as IP and we
took extreme care to avoid building IP dependencies into both the API
and the implementation. (At a point when it still mattered, DCE RPC
ran over Apollo's private CLTP as well. I don't know if DEC's
shipping product actually runs over DECnet, but it certainly did all
during DCE RPC's development.)
-- Nat Mishkin
Atria Software, Inc.
mishkin at atria.com
-------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18287;
10 Aug 93 13:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18277;
10 Aug 93 13:40 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16860;
10 Aug 93 13:40 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18257;
10 Aug 93 13:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18229;
10 Aug 93 13:38 EDT
Received: from optics.wc.novell.com by CNRI.Reston.VA.US id aa16751;
10 Aug 93 13:36 EDT
Received: from Untitled ([130.57.64.146]) by wc.novell.com (4.1/smi4.1.1.v91190)
id AA07543; Tue, 10 Aug 93 10:30:18 PDT
Date: Tue, 10 Aug 93 10:30:17 PDT
Message-Id: <9308101730.AA07543 at wc.novell.com>
To: Dave Crocker <dcrocker at mordor.stanford.edu>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: minshall at wc.novell.com
X-Sender: minshall at optics.wc.novell.com
Subject: Re: Now is the time for radical thinking...
Cc: ietf at CNRI.Reston.VA.US
Dave,
> Even CLNP will probably be
> cheap, or even bundled in, at that point.
>
>To my knowledge, this has not been the pattern of pricing for OSI products
>at any time so far. What will make that change?
In fairness to TUBA, isn't it the case that OSI products have included a
lot more OSI than TUBA requires? I.e., a TUBA host will need CLNP, but not
TP4, nor ASN.1-full-featured, nor ROSE, nor...
Presumably, this would help reduce the price a bit? (Plus, then, as Peter
was suggesting, increasing the number of units shipped would reduce the
price at some point possibly.)
Greg
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18658;
10 Aug 93 13:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18648;
10 Aug 93 13:51 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17307;
10 Aug 93 13:51 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18634;
10 Aug 93 13:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18556;
10 Aug 93 13:49 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa17180;
10 Aug 93 13:49 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA21004; Tue, 10 Aug 93 10:50:29 -0700
Message-Id: <9308101750.AA21004 at Mordor.Stanford.EDU>
To: minshall at wc.novell.com
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Tue, 10 Aug 93 10:30:17 -0700. <9308101730.AA07543 at wc.novell.com>
Date: Tue, 10 Aug 93 10:50:25 -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
Greg,
Making the product "smaller" by limiting it to CLNP is an interesting
point. I note, however, that your language implies a charge. This
is different from most vendors' current offering, except when the
vendor is not the platform provider. (I guess Windows NT will be
changing that model, too.)
Perhaps I'm confusing Tuba-as-independent-protocol from TUBA as
IPng alternative. My guess is that the economics of these two
roles is quite different.
My guess also is that the the pricing choices will be far less
simplistic than any of us is believing.
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18948;
10 Aug 93 13:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18937;
10 Aug 93 13:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17625;
10 Aug 93 13:59 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18924;
10 Aug 93 13:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18854;
10 Aug 93 13:57 EDT
Received: from eagle.nersc.gov by CNRI.Reston.VA.US id aa17582;
10 Aug 93 13:57 EDT
Date: Tue, 10 Aug 1993 10:58:24 -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: <930810105824.6a at EAGLE.ES.NET>
Subject: Re: Now is the time for radical thinking...
To: ietf at CNRI.Reston.VA.US
X-Vmsmail-To: smtp%"ietf at cnri.reston.va.us"
Noel,
Yes there is value in the installed base, but why are you looking out 15 years?
If we are doubling in size every 6 months at the end of 2 years the installed
base represents slightly over 6%. Add to that the likelyhood that many of those
systems will be replaced at the end of 2 years and you are looking at a
community of less than 5%. The total number of systems is still large, but will
the community as a whole care about the concerns of the 5%? Not likely.
Yes a part of the community needs to always be looking out N years and
desinging 'the next protocol'. But a part needs to also be looking at what it
will take to get us there and being pragmatic about delivering services.
A quiz...how long has it been since the great transition TO IPv4???
Those who have not burned out their brain cells may know the real answer, but
RFC 801 put a target for completion of Jan. 1, 1983 to have all 250 hosts
converted. Given that this was just 10 years ago it is hard to believe that
we will be any better at predicting our needs for a longer period now. Making
that even more difficult are the trade-rag predictions that Microsoft will
soon be shipping more systems per month than todays installed base, and the
potential that some form of national initiative may bring the network to each
doorstep.
Developments like these always take longer than planned, but we need a 5 year
plan that can absorb an order of magnitude growth. A group should be working
on the IPngNG (the one after the one after IPv4), without fighting about the
short term means to get us there.
Tony
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19707;
10 Aug 93 14:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19695;
10 Aug 93 14:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18795;
10 Aug 93 14:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19677;
10 Aug 93 14:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19583;
10 Aug 93 14:21 EDT
Received: from xap.xyplex.com by CNRI.Reston.VA.US id aa18632;
10 Aug 93 14:21 EDT
Received: by xap.xyplex.com id <AA04638 at xap.xyplex.com>; Tue, 10 Aug 93 16:21:08 -0500
Date: Tue, 10 Aug 93 16:21:08 -0500
Message-Id: <9308102121.AA04638 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: peter at goshawk.lanl.gov's message of Tue, 10 Aug 93 11:06:48 MST <9308101706.AA07127 at goshawk.lanl.gov>
Subject: Re: Now is the time for radical thinking...
Maybe I'm naive, but my humble opinion, which I value quite highly, is that
the major reason TCP/IP is so pervasive is that it was attached to Unix for
free, and Unix got attached to lots of hardware because it's relatively
portable, and free. If there was in fact a plan, it was at the level of a
deep conspiracy between the BSD folks and Vint, Jon, Bob, Dave and the rest of
the old network boys. Or maybe they had this all figured out ahead.
That pervasive availability, at no extra cost, and all the cool stuff you get
by being attached to the Internet, helped make TCP/IP the default for
interoperable network management. Given that there were always some silly
people around who wanted something other than Unix, and some of them are
die-hard, work-all-night computer hackers (in the best, old-fashioned sense of
the word), TCP/IP got put on other things, like Macintoshes and PeeCees and
Ataris, without Unix.
What I'm trying to say is that TCP/IP succeeded beyond most people's wild
imaginings because of intense, grassroots desire for interoperability, and the
free, portable availability via BSD Unix. Workstation vendors didn't bundle
it because they were smart or had an economic plan. They bundled it because
it was already there, it was more trouble to take it out, and besides, all
those Unix people expect it.
What I believe Dave Crocker is trying to say is that OSI has little to none of
that going for it, with the implication that Government Mandate will not
accomplish the same thing.
Thus his question, and now mine, too: What's going to make OSI cheap,
available, and desirable?
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21203;
10 Aug 93 15:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21193;
10 Aug 93 15:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21571;
10 Aug 93 15:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21179;
10 Aug 93 15:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21108;
10 Aug 93 15:21 EDT
Received: from SGI.COM by CNRI.Reston.VA.US id aa21477; 10 Aug 93 15:21 EDT
Received: by sgi.sgi.com (920330.SGI/910110.SGI)
id AA07746; Tue, 10 Aug 93 12:15:00 -0700
To: ietf at nri.reston.va.us
Reply-To: Vernon Schryver <vjs at rhyolite.wpd.sgi.com>
X-Approved: newsmail at sgi.sgi.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Vernon Schryver <vjs at rhyolite.wpd.sgi.com>
Subject: Re: Now is the time for radical thinking...
Message-Id: <jnbhvt4 at rhyolite.wpd.sgi.com>
Date: Tue, 10 Aug 1993 19:09:50 GMT
Dave Crocker <dcrocker at mordor.stanford.edu> writes:
> ...
> Sun's RPC is derived from Xerox's XNS and it used to
> run over a connection protocol. There now is a running Sun RPC over TCP.
> ...
Sun's RPC had "block mode" for running over TCP/IP since at least
1985. Silicon Graphics has used it for 5 or 6 years for "DGL", the old
over-the-wire version of the "GL" or "graphics library" (not to be
confused with the new, "open standard," "OpenGL"). People with big
compute-servers like Crays and Convex's used DGL to render on SGI boxes.
Each SUn RPC transaction was actually a block of hundreds of primitive
graphics function calls, because the standard marshalling and
unmarshalling was 10X or 100X too slow for the zillions of function
calls that you need for drawing stuff at reasonable (i.e. wire) speed.
There was no way to use XDR more than pro forma. (E.g byte swapping
during marshalling in little endian machines would have been
catastrophically slow, and there were no interesting little endian
machines). Since no standards committees were involved, the guy who
wrote the code didn't bother to be political correct and follow the
forms.
I'm not sure, but more recent versions (eg. the 1st one shipped 5-6
years ago) may have dispensed with the Sun RPC wrapping, which, because
of the speed contraints, was finally used mostly to handle IP port
number assigning via the portmapper.
RPC transport independence is boring and relatively easy. What's hard
and messy is in the layers above. Transport independence requires only
that you isolate the connection setup stuff, and that the actual data
moving functions for all transports are the same (e.g. read() and
write()) or can be made to look the same with wrappers that are fast
enough.
The important stuff in RPC seems to be in the compiler for the
marshalling and unmarshalling. Apollo's (and so DCE) had some nice
things. But rpcgen (for Sun's) has been improved in recent yeras.
This stuff is hard and messy, and not a good candidate for industry
consortia, not to mention standards committees. Transport independence
is no more a magic bullet for real applications than the resurrected
notion of "object oriented".
Vernon Schryver, vjs at sgi.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22126;
10 Aug 93 16:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22116;
10 Aug 93 16:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23197;
10 Aug 93 16:05 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22101;
10 Aug 93 16:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa22025;
10 Aug 93 16:03 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa23138;
10 Aug 93 16:03 EDT
Received: by ginger.lcs.mit.edu
id AA13730; Tue, 10 Aug 93 16:03:48 -0400
Date: Tue, 10 Aug 93 16:03:48 -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: <9308102003.AA13730 at ginger.lcs.mit.edu>
To: dcrocker at mordor.stanford.edu, minshall at wc.novell.com
Subject: Re: Now is the time for radical thinking...
Cc: ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
Even CLNP will probably be cheap, or even bundled in, at that point.
> To my knowledge, this has not been the pattern of pricing for OSI
> products at any time so far. What will make that change?
In fairness to TUBA, isn't it the case that OSI products have included a
lot more OSI than TUBA requires?
This is a civil (thank you everyone), and mildly informative, debate, but I'd
like to just say a few words about what I think is really going on here.
Everyone is trying to get the IETF to make a choice, the IPng choice, that is
not "competent", in the medieval English sense of "competent" (i.e. has the
ability and the power) to make. The IETF is simply a reflection of the larger
community out there, and has neither the mechanisms to make tough choices, nor
the ability to enforce them. We can do certain limited things, like create
particular specs in an open forum, and distribute them, but that's it.
This debate seems to be proceeding on the idea that it will i) change people's
minds, and ii) lead to an IPng choice. Nothing is further from likely. It may
bring out a few new bits of info, but if more than 1% of those listening change
their minds because of this (or any other :-) discussion held on this topic,
I'll eat a Lotus.
Any attempt to get the IETF to make these tough choices is going to i) cause a
lot of heat, and ii) fail. The IETF simply cannot do that. Now, as long as
this debate is just an infomative thing, with no expectation on anyone's part
that it is anything but educational, that's fine, and nobody needs to get
worked up, since it's not very important. Just nobody get any false illusions
about what is going on here...
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23171;
10 Aug 93 17:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23161;
10 Aug 93 17:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26600;
10 Aug 93 17:01 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23148;
10 Aug 93 17:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23108;
10 Aug 93 16:59 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa26544; 10 Aug 93 16:59 EDT
Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA19710 for ietf at cnri.reston.va.us; Tue, 10 Aug 93 17:00:21 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA00579; Tue, 10 Aug 93 13:58:30 PDT
Message-Id: <9308102058.AA00579 at aland.bbn.com>
To: ietf at CNRI.Reston.VA.US
Subject: RPC scaling (was Re: Now is the time for radical thinking...)
Reply-To: Craig Partridge <craig at aland.bbn.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Tue, 10 Aug 93 13:58:29 -0700
X-Orig-Sender: craig at aland.bbn.com
Hi folks:
Before we go much farther down this subject line, a cautionary word.
We've been talking about scaling IPng to higher speeds and more sites.
I want to point out that there are a number of considerable problems
in scaling RPC to higher speeds. In brief, the problem is inefficient use
of bandwidth. RPC, with its request-response pattern of interaction,
has real performance problems on gigabit LANs (yes LANs -- WANs are even
worse). Getting data over a gigabit network via RPC will feel sort of like
moving the contents of your house across a continent, piece by piece in the
backseat of a sports car.
Now, before I get beat up by folks mentioning parallel RPC, etc. Yes,
solutions have been proposed (indeed, I even proposed one in my doctoral
dissertation). But none of them are mainstream yet... So standardizing
on one of today's RPC interfaces risks the serious possibility of scaling on
an API that doesn't scale to high speeds.
Craig
E-mail: craig at aland.bbn.com or craig at bbn.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23933;
10 Aug 93 17:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23923;
10 Aug 93 17:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28482;
10 Aug 93 17:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23903;
10 Aug 93 17:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23880;
10 Aug 93 17:36 EDT
Received: from ftp.com by CNRI.Reston.VA.US id aa28415; 10 Aug 93 17:36 EDT
Received: by ftp.com
id AA10226; Tue, 10 Aug 93 17:37:18 -0400
Date: Tue, 10 Aug 93 17:37:18 -0400
Message-Id: <9308102137.AA10226 at ftp.com>
To: jnc at ginger.lcs.mit.edu
Subject: Re: Now is the time for radical thinking...
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
>Everyone is trying to get the IETF to make a choice, the IPng choice, that is
>not "competent", in the medieval English sense of "competent" (i.e. has the
>ability and the power) to make. The IETF is simply a reflection of the larger
>community out there, and has neither the mechanisms to make tough choices, nor
>the ability to enforce them. We can do certain limited things, like create
>particular specs in an open forum, and distribute them, but that's it.
I got the distinct feeling in Amsterdam that there is a fairly large
part of the community-at-large that wishes, in effect, to give the power
to make these decisions to the IETF. I am not convinced that this
sentiment is any more thought out than that:
1. I have no idea what percentage of the entire community this is.
It could be 10% or 90%...
2. It is not clear what part of this portion of the community are in
fact people who strongly (or not-so strongly) back one proposal or
the other, and will accept an IETF decision only so long as the IETF
choses their own pet proposal.
3. It is not clear whether "IETF makes the choice" means the whole IETF,
which is <well, what is it?> or the IESG or the IAB or the ISOC or
some specially chartered group of people, and so on.
>I'll eat a Lotus.
Yummy.
>Any attempt to get the IETF to make these tough choices is going to i) cause a
>lot of heat, and ii) fail. The IETF simply cannot do that. Now, as long as
>this debate is just an infomative thing, with no expectation on anyone's part
>that it is anything but educational, that's fine, and nobody needs to get
>worked up, since it's not very important. Just nobody get any false illusions
>about what is going on here...
--
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 aa24220;
10 Aug 93 18:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24210;
10 Aug 93 18:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29308;
10 Aug 93 18:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24197;
10 Aug 93 18:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24173;
10 Aug 93 18:05 EDT
Received: from aerospace.aero.org by CNRI.Reston.VA.US id aa29277;
10 Aug 93 18:05 EDT
Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT)
id AA13607 for ietf at cnri.reston.va.us; Tue, 10 Aug 1993 15:06:04 -0700
Posted-Date: Tue, 10 Aug 1993 15:06:01 -0700
Message-Id: <199308102206.AA13607 at aerospace.aero.org>
Received: from anpiel.aero.org by antares.aero.org (4.1/AMS-1.0)
id AA00634 for rlstewart at eng.xyplex.com; Tue, 10 Aug 93 15:06:03 PDT
To: Bob Stewart <rlstewart at eng.xyplex.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
In-Reply-To: Your message of "Tue, 10 Aug 1993 16:21:08 CDT."
<9308102121.AA04638 at xap.xyplex.com>
Date: Tue, 10 Aug 1993 15:06:01 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mike O'Brien <obrien at aero.org>
>Thus his question, and now mine, too: What's going to make OSI cheap,
>available, and desirable?
Given the earlier part of this message, the expected right answer is
so obvious I hesitate to bite, but OK: If Microsoft bundled a full
OSI stack with Windows NT and Novell did the same thing.
Mike O'Brien
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24336;
10 Aug 93 18:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24326;
10 Aug 93 18:20 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29672;
10 Aug 93 18:20 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24314;
10 Aug 93 18:20 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24287;
10 Aug 93 18:19 EDT
Received: from bulkrate.cc.bellcore.com by CNRI.Reston.VA.US id aa29636;
10 Aug 93 18:19 EDT
Received: from hera.UUCP by bulkrate.cc.bellcore.com id AA16816
(5.65c/IDA-1.4.4 for CNRI.Reston.VA.US!ietf); Tue, 10 Aug 1993 18:21:28 -0400
Message-Id: <199308102221.AA16816 at bulkrate.cc.bellcore.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "venezia,frank b" <fbv at cc.bellcore.com>
To: ietf at CNRI.Reston.VA.US
Date: 10 Aug 1993 18:15 EDT
Subject: Unsubscribe
Please unsubscribe me form IETF.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24561;
10 Aug 93 18:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24551;
10 Aug 93 18:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa00189;
10 Aug 93 18:36 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24539;
10 Aug 93 18:36 EDT
Received: from meg.uncg.edu by IETF.CNRI.Reston.VA.US id aa24511;
10 Aug 93 18:34 EDT
Received: by meg.uncg.edu (5.65/DEC-Ultrix/4.3)
id AA03030; Tue, 10 Aug 1993 18:35:43 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: MattMan <tuttlem at meg.uncg.edu>
Message-Id: <9308102235.AA03030 at meg.uncg.edu>
Subject: unsubscribe
To: ietf at IETF.CNRI.Reston.VA.US
Date: Tue, 10 Aug 93 18:35:41 EDT
X-Mailer: ELM [version 2.3 PL11]
Please unsubscribe me from all lists.
Thank You,
Matthew Tuttle
tuttlem at meg.uncg.edu, tuttlem at alice.uncg.edu tuttlem at hamlet.uncg.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25010;
10 Aug 93 19:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24999;
10 Aug 93 19:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01543;
10 Aug 93 19:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24987;
10 Aug 93 19:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24958;
10 Aug 93 19:36 EDT
Received: from mocha.bunyip.com by CNRI.Reston.VA.US id aa01493;
10 Aug 93 19:36 EDT
Received: from expresso.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA00470 (mail destined for ietf at CNRI.Reston.VA.US) on Tue, 10 Aug 93 19:36:54 -0400
Received: by expresso.bunyip.com (NX5.67c/NeXT-1.0)
id AA28288; Tue, 10 Aug 93 19:28:41 -0400
Message-Id: <9308102328.AA28288 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: Tue, 10 Aug 1993 19:28:40 -0400
In-Reply-To: Mike O'Brien's message as of Aug 10, 15:06
X-Mailer: Mail User's Shell (7.2.4 2/2/92)
To: Mike O'Brien <obrien at aero.org>, Bob Stewart <rlstewart at eng.xyplex.com>
Subject: Re: Now is the time for radical thinking...
Cc: ietf at CNRI.Reston.VA.US
[ You wrote: ]
> >Thus his question, and now mine, too: What's going to make OSI cheap,
> >available, and desirable?
>
> Given the earlier part of this message, the expected right answer is
> so obvious I hesitate to bite, but OK: If Microsoft bundled a full
> OSI stack with Windows NT and Novell did the same thing.
That might make it cheap, it might make it available. Does
it necessarily make it desirable??? :-)
- peterd
--
------------------------------------------------------------------------------
Peter Deutsch, (514) 875-8611 (phone)
Bunyip Information Systems Inc. (514) 875-8134 (fax)
<peterd at bunyip.com>
Those are not guesses in my growth estimates. They're extrapolations out from
current trends. Of course, some are extrapolated out from the empty trend....
------------------------------------------------------------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25211;
10 Aug 93 20:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25201;
10 Aug 93 20:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02461;
10 Aug 93 20:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25188;
10 Aug 93 20:13 EDT
Received: from garam.kreonet.re.kr by IETF.CNRI.Reston.VA.US id aa25162;
10 Aug 93 20:11 EDT
Received: from halla.dacom.co.kr by garam.kreonet.re.kr (4.1/GARAM-MX-1.0)
id AA24611; Wed, 11 Aug 93 09:13:13 KDT
Received: by halla.dacom.co.kr (4.1/SMI-4.1)
id AA25448; Wed, 11 Aug 93 09:10:18 KDT
Date: Wed, 11 Aug 93 09:10:18 KDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Lee Seung-min <lsm at halla.dacom.co.kr>
Message-Id: <9308102310.AA25448 at halla.dacom.co.kr>
To: ietf at IETF.CNRI.Reston.VA.US
Subject: UNSUBSCRIBE
Please unsubscribe me from all lists.
Thank You,
Seung M. Lee
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25455;
10 Aug 93 20:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25445;
10 Aug 93 20:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03077;
10 Aug 93 20:44 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25433;
10 Aug 93 20:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25409;
10 Aug 93 20:42 EDT
Received: from brazos.is.rice.edu by CNRI.Reston.VA.US id aa03062;
10 Aug 93 20:42 EDT
Received: by brazos.is.rice.edu (AA02609); Tue, 10 Aug 93 19:42:40 CDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: William Manning <bmanning at is.rice.edu>
Message-Id: <9308110042.AA02609 at brazos.is.rice.edu>
Subject: Re: Now is the time for radical thinking...
To: Peter Deutsch <peterd at bunyip.com>
Date: Tue, 10 Aug 1993 19:42:40 -0500 (CDT)
Cc: obrien at aero.org, rlstewart at eng.xyplex.com, ietf at CNRI.Reston.VA.US
In-Reply-To: <9308102328.AA28288 at expresso.bunyip.com> from "Peter Deutsch" at Aug 10, 93 07:28:40 pm
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 508
Peter Deutsch
>
> [ You wrote: ]
>
>> If Microsoft bundled a full
>> OSI
SIP
PIP
IPv7
IPX
NETBIOS
SNA
>> stack with Windows NT and Novell did the same thing.
>
> That might make it cheap, it might make it available. Does
> it necessarily make it desirable??? :-)
>
> - peterd
extrapolations are my own...
--
Regards,
Bill Manning bmanning at rice.edu PO Box 1892
713-285-5415 713-527-6099 Houston, Texas
R.U. (o-kome) 77251-1892
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25523;
10 Aug 93 20:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25513;
10 Aug 93 20:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03148;
10 Aug 93 20:47 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25498;
10 Aug 93 20:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25470;
10 Aug 93 20:46 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa03124; 10 Aug 93 20:46 EDT
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA00298; Tue, 10 Aug 93 17:46:49 PDT
Received: from pepper.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA28941; Tue, 10 Aug 93 17:46:54 PDT
Received: from yikes.Eng.Sun.COM by pepper.Eng.Sun.COM (4.1/SMI-4.1)
id AA19116; Tue, 10 Aug 93 17:51:07 PDT
Date: Tue, 10 Aug 93 17:51:07 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Chuck McManis <Chuck.McManis at eng.sun.com>
Message-Id: <9308110051.AA19116 at pepper.Eng.Sun.COM>
To: ietf at CNRI.Reston.VA.US, craig at aland.bbn.com
Subject: Re: RPC scaling (was Re: Now is the time for radical thinking...)
X-Sun-Charset: US-ASCII
Craig raises a good point, RPC isn't a good paradigm for networking when the
assumption of infinite bandwidth and zero latency begins to crumble. In
fact "procedure calls" aren't a good paradigm for something like multicast
(who ever heard of a language where one function call caused 'n' threads to
be created into 'n' copies of the procedure.) There use is primarily in
providing services on local area networks. This doesn't mean that RPC isn't
useful, it is. It does mean that it isn't a panacea, but anyone who has
written a few network services realized that a long time ago.
--Chuck
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25791;
10 Aug 93 21:10 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25781;
10 Aug 93 21:10 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03918;
10 Aug 93 21:10 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25766;
10 Aug 93 21:10 EDT
Received: from garam.kreonet.re.kr by IETF.CNRI.Reston.VA.US id aa25743;
10 Aug 93 21:08 EDT
Received: from halla.dacom.co.kr by garam.kreonet.re.kr (4.1/GARAM-MX-1.0)
id AA26271; Wed, 11 Aug 93 10:10:26 KDT
Received: by halla.dacom.co.kr (4.1/SMI-4.1)
id AA25427; Wed, 11 Aug 93 09:09:16 KDT
Date: Wed, 11 Aug 93 09:09:16 KDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Lee Seung-min <lsm at halla.dacom.co.kr>
Message-Id: <9308102309.AA25427 at halla.dacom.co.kr>
To: ietf at IETF.CNRI.Reston.VA.US
Subject: UNSUBSCRIBE
Please unsubscribe me from all lists.
Thank You,
Seung M. Lee
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26746;
10 Aug 93 22:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26732;
10 Aug 93 22:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06000;
10 Aug 93 22:25 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa26669;
10 Aug 93 22:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa26385;
10 Aug 93 22:24 EDT
Received: from uu.psi.com by CNRI.Reston.VA.US id aa05894; 10 Aug 93 22:24 EDT
Received: by uu.psi.com (5.65b/4.1.031792-PSI/PSINet) via UUCP;
id AA05574 for ; Tue, 10 Aug 93 22:20:56 -0400
Date: Tue, 10 Aug 93 17:46:50 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ed Reeder <ed at osi.com>
Received: from osi.osi.COM (osi.ARPA) by sparc2.osi.com (4.1/3.2.083191-Objective Systems Integrators)
id AA10588; Tue, 10 Aug 93 17:46:50 PDT
Message-Id: <9308110046.AA10588 at sparc2.osi.com>
To: rlstewart at eng.xyplex.com, obrien at aero.org
Subject: Re: Now is the time for radical thinking...
Cc: ietf at CNRI.Reston.VA.US
At least one of the implementations would work!
(I couldn't resist :-)
/Ed
> From ietf-request at ietf.nri.reston.va.us Tue Aug 10 17:18:49 1993
> To: Bob Stewart <rlstewart at eng.xyplex.com>
> Cc: ietf at CNRI.Reston.VA.US
> Subject: Re: Now is the time for radical thinking...
> Date: Tue, 10 Aug 1993 15:06:01 -0700
> From: Mike O'Brien <obrien at aero.org>
>
> >Thus his question, and now mine, too: What's going to make OSI cheap,
> >available, and desirable?
>
> Given the earlier part of this message, the expected right answer is
> so obvious I hesitate to bite, but OK: If Microsoft bundled a full
> OSI stack with Windows NT and Novell did the same thing.
>
> Mike O'Brien
>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27655;
10 Aug 93 22:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27645;
10 Aug 93 22:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06464;
10 Aug 93 22:36 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa27632;
10 Aug 93 22:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa27607;
10 Aug 93 22:35 EDT
Received: from umbc4.umbc.edu by CNRI.Reston.VA.US id aa06427;
10 Aug 93 22:35 EDT
Received: by umbc4.umbc.edu id AA16636
(5.65c/IDA-1.4.4 for ietf at CNRI.Reston.VA.US); Tue, 10 Aug 1993 22:35:45 -0400
Date: Tue, 10 Aug 1993 22:35:45 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Dr. Deepinder Sidhu (CMSC)" <sidhu at umbc.edu>
Message-Id: <199308110235.AA16636 at umbc4.umbc.edu>
To: ietf at CNRI.Reston.VA.US
Subject: Jour. of High Speed Neworks, Special Issue on QOS
Cc: parekh at watson.ibm.com, sidhu at umbc.edu
-------------------------------------------------------------------------
SPECIAL ISSUE ON QUALITY OF SERVICE
JOURNAL OF HIGH SPEED NETWORKS
GUEST EDITOR: DR. ABHAY K. PAREKH
-------------------------------------------------------------------------
The Journal of High Speed Networks (JHSN) announces a forthcoming issue
in early 1994 on Quality of Service (QOS) in Integrated Services Networks.
JHSN publishes high quality papers on a number of topics ranging from
design to practical experience with operational high speed networks.
An important benefit of high speed networking technology is its ability
to support a wide range of applications. However, the extent to which
the resources of a store-and-forward network are shared may compromise
Quality of Service in a number of different ways. While there has been
considerable research in the area, there remain many fundamental issues
that need to be better understood. We solicit high quality papers that
address these issues either through analytical or experimental techniques.
Representative areas of interest include:
-- Appropriate metrics for QOS;
-- Application requirements in terms of network performance;
-- Experimental results on human perception of network performance
degradation through loss and delay;
-- Network Services to better support distributed multiuser applications.
-- Evaluating current proposals for QOS against specific application
requirements;
-- Performance models for analyzing QOS;
-- The nature of QOS guarantees offered by the network i.e., firm,
best-effort or something in between;
-- Preserving QOS across heterogenous network domains;
-- Network Control strategies to facilitate QOS.
-- The tradeoff between supporting diverse applications and simplifying
network control mechanisms;
-- The tradeoff between supporting diverse applications and enabling
efficient use of network resources
Send 5 copies of the submission to
Dr. Abhay K. Parekh
Guest Editor
IBM T. J. Watson Research Center
P.O. Box 704
Yorktown Heights NY 10598
Email: parekh at watson.ibm.com
Voice: 914-784-7888
Deadline for submission:
November 30, 1993
-------------------------------------------------------------
JOURNAL OF HIGH SPEED NETWORKS
-------------------------------------------------------------
>>>>> AIMS & SCOPE
The aim of this international journal is to publish original
and significant results on the research and development of high
speed data and telecommunication networks. All contributions to
the journal are refereed consistent with the review process
of leading technical journals. The main goal is to provide
timely dissemination of information. The journal publishes
papers on a number of topics ranging from design to practical
experiences with operational high speed networks. The topics
covered include but not be limited to: design and analysis
of high speed networks; protocols for high speed communications;
high speed LANs, MANs and WANs; broadband ISDN and services;
optical networks and applications; control and management of high
speed networks; high speed switches, interfaces and controllers;
applications of high speed networks; routing, flow control and
congestion control in high speed networks; experiences with
operational high speed networks.
>>>>> EDITORIAL BOARD
Editor-in-Chief:
Prof. Deepinder Sidhu Email: sidhu at umbc.edu
Maryland Center for
Telecommunications Research Voice: 410-455-3028
University of Maryland - BC Fax: 410-455-3969
Baltimore, MD 21228-5398
Members:
A. Acampora, S. Budkowski, I. Chlamtac, J. Crowcroft, B. Doshi,
D. Farber, W. Franta, I. Gopal, M. Hluchyj, D. Hogrefe, R. Jain,
L. Kleinrock, L. Landweber, M. Ajmone-Marson, N. Maxemchuk,
D. Mitra, H. Motteler, K. Ono, N. Ransom, B. Pehrson, J. Roberts,
K. Sabnani, S. Shenker, N. Shiratori, D. Sincoskie, M. Skov,
J. Smith, O. Spaniol, J. Swenson, F. Tobagi, S. Wakid, R. Watson,
G. Wetzel, L. Zhang.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00161;
10 Aug 93 23:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00151;
10 Aug 93 23:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07609;
10 Aug 93 23:24 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00139;
10 Aug 93 23:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00114;
10 Aug 93 23:22 EDT
Received: from worldlink.com by CNRI.Reston.VA.US id aa07592;
10 Aug 93 23:22 EDT
Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink)
id AA15100; Tue, 10 Aug 93 23:23:44 -0400
Date: Tue, 10 Aug 93 23:23:44 -0400
Message-Id: <9308110323.AA15100 at worldlink.worldlink.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dave Bachmann <wk01200 at worldlink.com>
To: Chuck McManis <Chuck.McManis at eng.sun.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: RPC scaling (was Re: Now is the time for radical thinking...)
>
> Craig raises a good point, RPC isn't a good paradigm for networking when the
> assumption of infinite bandwidth and zero latency begins to crumble. In
> fact "procedure calls" aren't a good paradigm for something like multicast
> (who ever heard of a language where one function call caused 'n' threads to
> be created into 'n' copies of the procedure.) There use is primarily in
> providing services on local area networks. This doesn't mean that RPC isn't
> useful, it is. It does mean that it isn't a panacea, but anyone who has
> written a few network services realized that a long time ago.
>
> --Chuck
I disagree (although I agree it's not a panacea). Obviously there is a time
and a place for RPCs. The old way of running NFS over UDP one 8K RPC at a
time was grossly unsuitable for non-LAN file systems (although to be fair,
the new ONC RPC allows for batching - hopefully the new NFS uses it).
However AFS makes effective use of streaming RPCs. I haven't heard people
complaining about it being unsuitable for long fat pipes. But I wouldn't try
to implement telnet over RPC.
With respect to your point about multicast, I think there are good uses for
multicast RPCs. And in fact I wouldn't be surprised if one of the language
folk hasn't already designed a language "where one function call caused 'n'
threads to be created into 'n' copies of the procedure." As a simplistic
case, I've been playing around with a toy application that is a game server
(specifically a chess game server). Two people can connect to it to play a
chess game, either in real time or asynchronously, using RPCs to make the
next play, and using callback RPC to notify the client when your opponent
makes her play (at which point the client updates the screen image of the
chess board). One of the things I'm going to support is for multiple
observers to register with the chess server to watch a game. So when a play
is made the server will multicast RPC the move to all the observers, as well
as the two players.
OK, it's a toy. But it's just as applicable for shared editing sessions, or
maybe for conferencing (although RPC may not be appropriate for streamed
audio or video).
I'm not advocating DCE RPC as a candidate for IPng, although its success at
transport protocol independence is worth looking at to see if there's some
useful ideas worth borrowing. It really is the case that an application can
be written by someone today, and be run tomorrow over a transport that didn't
even exist when that app was written, as long as the DCE runtime has had
support added for that transport, without recompiling that app.
My bias: these days I'm working on improving the performance of DCE, so it
works efficiently over any pipe, short or long, fat or skinny.
dave
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00370;
10 Aug 93 23:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00360;
10 Aug 93 23:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08075;
10 Aug 93 23:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00339;
10 Aug 93 23:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00275;
10 Aug 93 23:36 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa07984; 10 Aug 93 23:36 EDT
Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA03671 for ietf at cnri.reston.va.us; Tue, 10 Aug 93 23:36:46 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA03303; Tue, 10 Aug 93 20:35:00 PDT
Message-Id: <9308110335.AA03303 at aland.bbn.com>
To: Dave Bachmann <wk01200 at worldlink.com>
Cc: Chuck McManis <Chuck.McManis at eng.sun.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: RPC scaling (was Re: Now is the time for radical thinking...)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Tue, 10 Aug 93 20:35:00 -0700
X-Orig-Sender: craig at aland.bbn.com
> However AFS makes effective use of streaming RPCs. I haven't heard people
> complaining about it being unsuitable for long fat pipes. But I wouldn't try
> to implement telnet over RPC.
Well, there's some question about whether streaming RPCs is the right solution
to long delay bandwidth products.
For instance, I can prove under certain fairly general conditions that
exporting the procedure call (ala REV -- Stamos' work) always results in
better performance than pulling data to its consumer. (E.g., moving code
to data is better).
Some file system folks argue that caching will work, but if you compute
out the cost-benefit analysis of how much data to retrieve per call over
gigabit networks, there are many situations in which one discovers that a
single read from one file is a hint to retrieve the entire filesystem...
(an amusing and startling result).
At any rate, the initial point was classic RPC (the stock of the trade
these days) is *not* the interface you'd want in the future.
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01029;
10 Aug 93 23:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01019;
10 Aug 93 23:41 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa08156;
10 Aug 93 23:41 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00949;
10 Aug 93 23:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00382;
10 Aug 93 23:39 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa08124; 10 Aug 93 23:40 EDT
Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA03924 for ietf at cnri.reston.va.us; Tue, 10 Aug 93 23:40:38 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA03318; Tue, 10 Aug 93 20:38:52 PDT
Message-Id: <9308110338.AA03318 at aland.bbn.com>
To: ietf at CNRI.Reston.VA.US
Subject: BSD lovers -- 4.4BSD T-shirt alert
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Tue, 10 Aug 93 20:38:52 -0700
X-Orig-Sender: craig at aland.bbn.com
Pardon the message which is only very very marginally IETF-related.
I just happen to know a lot of BSD fans hang out at IETF and figured
they might not want to miss their chance at a T-shirt.
------- Forwarded Message
Sorry if this is too commercial, but I am getting tired of answering
inquiries one by one.
The new 4.4BSD T-shirts are just now hot off the presses. The new
art has the BSD Daemon standing in Birkenstocks on top of the world
skewering a deflated deathstar on his trident. Under the picture
is the text ``Free the Berkeley 4.4!''. The shirts are available
only in ash, as that color is designed to integrate with the six
color half tone artwork. The shirts are Hanes ``Beefy-T'' preshrunk
100% cotton; they are generously cut, so after their first washing
will fit similarly to a polyester shirt of the same size. The
available sizes are M, L, and XL; the cost is $15 each (shipments to
California are $13.86 plus $1.14 sales tax). In quantities of ten or
more, the price is $12.50 each (shipments to California are $11.55 plus
$0.95 sales tax). There is a mailing fee of $4.00 independent of order
size (for orders outside the United States, the mailing fee is $4.00 if
you want your order sent by surface mail or $8.00 if you want your
order sent via airmail). To order, send me your postal address and
mail your check or money order (payable in US dollars) to:
Kirk McKusick
1614 Oxford St
Berkeley, CA 94709-1608
USA
As they say on the cereal boxes, offer good while supplies last!
Kirk McKusick
------- End of Forwarded Message
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03634;
11 Aug 93 6:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03623;
11 Aug 93 6:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02407;
11 Aug 93 6:33 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03609;
11 Aug 93 6:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03555;
11 Aug 93 6:24 EDT
Received: from world.std.com by CNRI.Reston.VA.US id aa02262; 11 Aug 93 6:24 EDT
Received: by world.std.com (5.65c/Spike-2.0)
id AA13112; Wed, 11 Aug 1993 06:24:38 -0400
Date: Wed, 11 Aug 1993 06:23:20 -0400 (EDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Skip MacAskill <smacaski at world.std.com>
Subject: Unsubscribe
To: ietf at CNRI.Reston.VA.US
Message-Id: <Pine.3.07.9308110620.A12993-7100000 at world.std.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Please unsubscribe me from all lists.
Thank you,
Skip MacAskill
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04229;
11 Aug 93 7:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04219;
11 Aug 93 7:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03457;
11 Aug 93 7:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04206;
11 Aug 93 7:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04168;
11 Aug 93 7:21 EDT
Received: from relay.philips.nl by CNRI.Reston.VA.US id aa03427;
11 Aug 93 7:21 EDT
Return-Path: <geertj at ica.philips.nl>
Received: from philica.ica.philips.nl ([130.144.131.1]) by relay.philips.nl with SMTP (5.65c/smail2.5/05-10-87);
id AA22493; Wed, 11 Aug 1993 13:22:17 +0200
Received: by philica.ica.philips.nl;
id AA05393; Wed, 11 Aug 93 13:22:15 +0200
Message-Id: <9308111122.AA05393 at philica.ica.philips.nl>
To: ietf at CNRI.Reston.VA.US
Subject: To all unsubscribers
Date: Wed, 11 Aug 1993 13:22:14 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Geert Jan de Groot <geertj at ica.philips.nl>
Numerous people have written:
>Please unsubscribe me from all lists.
Please stop abusing the ietf list for this and use
ietf-request at IETF.CNRI.Reston.VA.US instead!
This probably has been told when you subscribed.
Thank you,
Geert Jan
[I apologize to pollute the list for this..]
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05953;
11 Aug 93 8:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05948;
11 Aug 93 8:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06956;
11 Aug 93 8:58 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05937;
11 Aug 93 8:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05933;
11 Aug 93 8:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06951;
11 Aug 93 8:58 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05919;
11 Aug 93 8:58 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: hubmib at synoptics.com
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: Definitions of Managed Objects for IEEE 802.3 Medium
Attachment Units (MAUs) to Proposed Standard
Date: Wed, 11 Aug 93 08:58:15 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308110858.aa05919 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the IEEE 802.3 Hub MIB Working
Group to consider "Definitions of Managed Objects for IEEE 802.3
Medium Attachment Units (MAUs)" <draft-ietf-hubmib-mau-02.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 25 August.
John Stewart
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06033;
11 Aug 93 9:00 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06028;
11 Aug 93 9:00 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06994;
11 Aug 93 8:59 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05997;
11 Aug 93 8:59 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05993;
11 Aug 93 8:59 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06987;
11 Aug 93 8:59 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05984;
11 Aug 93 8:59 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: rmonmib at jarthur.claremont.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: Token Ring Extensions to the Remote Network Monitoring
MIB to Proposed Standard
Date: Wed, 11 Aug 93 08:59:45 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308110859.aa05984 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Remote LAN Monitoring
Working Group to consider "Token Ring Extensions to the Remote
Network Monitoring MIB" <draft-ietf-rmonmib-trmib-01.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 25 August.
John Stewart
IESG Secretary
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06153;
11 Aug 93 9:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06149;
11 Aug 93 9:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07125;
11 Aug 93 9:01 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06136;
11 Aug 93 9:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06132;
11 Aug 93 9:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07113;
11 Aug 93 9:01 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06123;
11 Aug 93 9:01 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: hubmib at synoptics.com
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: Definitions of Managed Objects for IEEE 802.3 Repeater
Devices to Draft Standard
Date: Wed, 11 Aug 93 09:01:27 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308110901.aa06123 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the IEEE 802.3 Hub MIB Working
Group to consider "Definitions of Managed Objects for IEEE 802.3
Repeater Devices" <draft-ietf-hubmib-objects-00.txt> for the status
of Draft 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 25 August.
John Stewart
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07629;
11 Aug 93 9:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09473;
11 Aug 93 9:54 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07615;
11 Aug 93 9:54 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07565;
11 Aug 93 9:52 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: isis at merit.edu
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-isis-multilevel-routing-00.txt
Date: Wed, 11 Aug 93 09:52:45 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308110952.aa07565 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 ISIS for IP Internets Working
Group of the IETF.
Title : Multiple Levels of Hierarchy with IS-IS
Author(s) : R. Perlman, C. Gunner
Filename : draft-ietf-isis-multilevel-routing-00.txt
Pages : 10
This paper describes the management, algorithms, and control packet
structures necessary to support arbitrary levels of routing hierarchy
in IS-IS.
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-isis-multilevel-routing-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-isis-multilevel-routing-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-isis-multilevel-routing-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-isis-multilevel-routing-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 aa10156;
11 Aug 93 11:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10146;
11 Aug 93 11:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13055;
11 Aug 93 11:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10122;
11 Aug 93 11:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10048;
11 Aug 93 11:16 EDT
Received: from SGI.COM by CNRI.Reston.VA.US id aa12865; 11 Aug 93 11:16 EDT
Received: by sgi.sgi.com (920330.SGI/910110.SGI)
id AA01661; Wed, 11 Aug 93 08:13:08 -0700
To: ietf at nri.reston.va.us
Reply-To: Vernon Schryver <vjs at rhyolite.wpd.sgi.com>
X-Approved: newsmail at sgi.sgi.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Vernon Schryver <vjs at rhyolite.wpd.sgi.com>
Subject: Re: RPC scaling (was Re: Now is the time for radical thinking...)
Message-Id: <jnt2q8e at rhyolite.wpd.sgi.com>
Date: Wed, 11 Aug 1993 15:06:16 GMT
Dave Bachmann <wk01200 at worldlink.com> writes:
> ...
> (although to be fair,
> the new ONC RPC allows for batching - hopefully the new NFS uses it).
As I wrote before, Sun's RPC had batching/bulk facilities in 1985,
and some Sun RPC applications have been using it for years.
Does no one remember the heated debates in the NCS/NCF/NCA "core"
meetings in about 1988 about allowing stream transports below the RPC?
On the grounds that Sun's RPC had it and that some people (e.g. certain
graphics computer vendors) wanted to use it? Remember that NCF was the
consortium founded by Apollo with most of the industry participating
(including Sun), chartered to start with the Apollo RPC and replace
Sun's RPC? Remember that Apollo's RPC is the basis of DCE's?
> However AFS makes effective use of streaming RPCs.
For what it's worth, NFS often runs over TCP.
Peter Honeyman has written about fixing the old AFS to work over long,
slow pipes.
In my estimation, streaming RPC's are wrong for network file systems
over long pipes. Their saving grace is that they are not as wrong as
non-streaming RPC's. The trouble with RPC's and streaming for file
systems is that it is very hard to get the read-ahead/write-behind
correct from down in the bowels of the RPC. The decisions on what to
read-ahead must be informed by what the current application mix is
doing. What you stream needs to be driven by the RPC application (in
this case, the file system is the RPC application.)
This effect is demonstrated among current NFS vendors. Some client
vendors use very aggressive read-ahead, starting many remote
read-aheads at the slighest excuse. They do very well on simple
benchmarks of the `cp foo bar` variety. They do badly (i.e. benchmark
worse than their competators) on applications or mixes of applications
with more random activity, where their aggressive read-aheads load the
client, the wire, and the server with wasted work.
Vernon Schryver, vjs at sgi.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11737;
11 Aug 93 13:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11726;
11 Aug 93 13:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17397;
11 Aug 93 13:02 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11710;
11 Aug 93 13:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11662;
11 Aug 93 13:00 EDT
Received: from hp.com by CNRI.Reston.VA.US id aa17306; 11 Aug 93 13:00 EDT
Received: from hpindsh.cup.hp.com by hp.com with SMTP
(16.8/15.5+IOS 3.13) id AA02475; Wed, 11 Aug 93 10:01:07 -0700
Received: from hpindbg.cup.hp.com by hpindsh.cup.hp.com with SMTP
(1.37.109.4/15.5+IOS 3.20+cup+OMrelay) id AA02058; Wed, 11 Aug 93 10:00:59 -0700
Message-Id: <9308111700.AA02058 at hpindsh.cup.hp.com>
To: Geert Jan de Groot <geertj at ica.philips.nl>
Cc: ietf at CNRI.Reston.VA.US, ash at hpindsh.cup.hp.com
Subject: Re: To all unsubscribers
In-Reply-To: Your message of "Wed, 11 Aug 93 13:22:14 +0200."
<9308111122.AA05393 at philica.ica.philips.nl>
Date: Wed, 11 Aug 93 10:00:58 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: ash at hpindsh.cup.hp.com
In message <9308111122.AA05393 at philica.ica.philips.nl> you write:
>
>Numerous people have written:
>>Please unsubscribe me from all lists.
>
>Please stop abusing the ietf list for this and use
>ietf-request at IETF.CNRI.Reston.VA.US instead!
>
>This probably has been told when you subscribed.
>
>Thank you,
>
>Geert Jan
>[I apologize to pollute the list for this..]
I know this is not the best place to speak about this, but since I
have been wading for at least 2 years through the high volume of
non-related IETF info on this list, I guess I can write one out of
band note. I will try to keep it to just the one message.
Unfortunately, it is likely that those who sent the unsubscribe messages
will not be hearing Geert's message, and thus not getting their attitude
(understanding) adjustment of internet etiquette. I suggest that all
XXX-request administrators send a message as part of confirmation of an
addition or deletion of an individual who used an improper mailing address
and inform them of the correct method. Hopefully, this direct type of
education will start making the unsubscribe messages folklore.
-art
------------------------------------------------------------------------------
ART HARKIN
Hewlett-Packard Company E-mail: ash at cup.hp.com
Information Networks Division Phone: (408) 447-3755
19420 Homestead Road MS 43LN,
Cupertino, CA 95014
------------------------------------------------------------------------------
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11878;
11 Aug 93 13:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11868;
11 Aug 93 13:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17800;
11 Aug 93 13:11 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11852;
11 Aug 93 13:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11813;
11 Aug 93 13:10 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa17790;
11 Aug 93 13:10 EDT
Received: by ginger.lcs.mit.edu
id AA22028; Wed, 11 Aug 93 13:10:42 -0400
Date: Wed, 11 Aug 93 13:10:42 -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: <9308111710.AA22028 at ginger.lcs.mit.edu>
To: deering at parc.xerox.com, ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
Cc: jnc at ginger.lcs.mit.edu
As far as routing scaling goes, those devices will be allocated addresses
within larger aggregates (e.g., service-provider aggregates or
sub-aggregates) and will have no impact on wide-area routing.
Good point.
As far as address-space scaling goes, a 64-bit hierarchical address space
can comfortably accommodate tens of thousands of globally-addressable
devices in every household in the world...
Steve, this cannot be settled by a debate, and in any case this is not the
appropriate forum, but I just wanted to mention that not everyone agrees with
the practical precursor to this claim, i.e. that the 64-bit space will
*usefully* address (i.e. in a way usable in the real world) each household in
the world...
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13976;
11 Aug 93 14:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13961;
11 Aug 93 14:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21745;
11 Aug 93 14:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13937;
11 Aug 93 14:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13841;
11 Aug 93 14:32 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa21612;
11 Aug 93 14:32 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA19240; Wed, 11 Aug 93 11:32:43 -0700
Message-Id: <9308111832.AA19240 at Mordor.Stanford.EDU>
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Wed, 11 Aug 93 13:10:42 -0400. <9308111710.AA22028 at ginger.lcs.mit.edu>
Date: Wed, 11 Aug 93 11:32:43 -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
Not to debate this point but, instead, to issue a request again:
Some folks have expressed discomfort with 64-bit addresses. Having
been involved with the SIP effort, I got a very early shot at
expressing my own. In point of fact, however, Steve D. has done a
solid job of countering such concerns.
While I have seen statements of general discomfort, I have not seen
specific analyses which state the specific holes in Steve D's own
analysis. I would like to see some concrete work pursue this, since it
is often described as a show-stopper. One assumes that discomfort at
that level is subject to detailed description and defense.
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13987;
11 Aug 93 14:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13963;
11 Aug 93 14:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21747;
11 Aug 93 14:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13939;
11 Aug 93 14:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13809;
11 Aug 93 14:31 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa21602;
11 Aug 93 14:31 EDT
Received: by ginger.lcs.mit.edu
id AA22692; Wed, 11 Aug 93 14:31:42 -0400
Date: Wed, 11 Aug 93 14:31:42 -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: <9308111831.AA22692 at ginger.lcs.mit.edu>
To: ALH at eagle.es.net, ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
Cc: jnc at ginger.lcs.mit.edu
... a target for completion of Jan. 1, 1983 to have all 250 hosts
converted. Given that this was just 10 years ago it is hard to believe
that we will be any better at predicting our needs for a longer period now.
Sigh. Oddly enough, understanding what happened here may help understand why I
prefer to put off IPng (not that I expect to convince anyone :-).
Nobody that I know of really seriously thought, when the 32-bit IPv4 addresses
were decided on (in ~1977 or whenever it was) that that protocol would ever
handle a system of this size. Perhaps there were, since some people wanted
variable length addresses, but I don't recall anyone predicting a system of
this size this soon.
In light of that choice, when the decision to deploy was made in around 1980
or so, it was necessary to go with what was on the shelf, i.e. 32-bit numbers,
landing us in the soup we are in now. The rush to deploy something, and the
use of what was already there, caused a system to be deployed which is now
going to have be replaced after a fairly short lifetime, as things go. Was it
the right decision? I dunno; in light of things at the time, with all the
investment in working software, the chance to learn more about large networks
through experience (it's astonishing how little we knew then), etc, and no
resources to upgrade, it probably was.
One lesson living through that whole experience has left me with, though, is a
deep appreciation of the long-term costs of short-term decisions; specifically
to deploy stuff in a hurry "because it is there". It may be the right decision,
but the downside down the road can be massive.
Developments like these always take longer than planned, but we need a 5
year plan that can absorb an order of magnitude growth. A group should be
working on the IPngNG (the one after the one after IPv4), without fighting
about the short term means to get us there.
Exactly. However, if some as-yet not clearly understood IPngNG is inevitable,
the question immediately becomes: "if IPv4 is a candidate, albeit with some
patching and kludgery, for that interim thing", which course is cheaper: i) to
go through all the pain of a switch to IPng, knowing that another one is going
to have to be made in the not too distant future (and with less forward force
on it, since IPng won't be as obviously obsolescent as IPv4), or ii) stick
with IPv4 as long as possible, and go directly to IPngNG?
This assumes, of course, that IPv4 can be patched into working for 5 more
years, but it's not clear to me that CIDR, EID's, NAT, etc can't do it.
Oh well, interesting academic speculation, but not anything any of us have
any control over!
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15050;
11 Aug 93 15:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15040;
11 Aug 93 15:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23244;
11 Aug 93 15:12 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15022;
11 Aug 93 15:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14973;
11 Aug 93 15:10 EDT
Received: from eco.twg.com by CNRI.Reston.VA.US id aa23190; 11 Aug 93 15:10 EDT
Received: from LOCAL.eco.twg.com by eco.twg.com (5.67/ECO.m-$Revision: 2.16 $)
id AA06163; Wed, 11 Aug 93 15:10:21 -0400
Message-Id: <9308111910.AA06163 at eco.twg.com>
Received: from apache.twg.com by apache.twg.com id <15732-0 at apache.twg.com>; Wed, 11 Aug 1993 12:11:27 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: David Herron <david at twg.com>
Subject: Re: Now is the time for radical thinking...
To: IPM Return Requested <ietf at CNRI.Reston.VA.US>
Date: Wed, 11 Aug 93 12:11:25 PDT
In-Reply-To: Your message of Wed, 11 Aug 93 14:31:42 -0400.<9308111831.AA22692 at ginger.lcs.mit.edu>
Sensitivity: Personal
Conversion: Prohibited
Conversion-With-Loss: Prohibited
Encoding: 10 TEXT
> This assumes, of course, that IPv4 can be patched into working for 5 more
> years, but it's not clear to me that CIDR, EID's, NAT, etc can't do it.
I just wanna plop out a reminder that there isn't much time left.
My internet service provider (for my home system) was recently assigned
the 165.113 network. Last year the new networks were in the 140's. This
is edging up on 192 way quick!
David
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15235;
11 Aug 93 15:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15224;
11 Aug 93 15:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23394;
11 Aug 93 15:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15205;
11 Aug 93 15:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15143;
11 Aug 93 15:16 EDT
Received: from nic.near.net by CNRI.Reston.VA.US id aa23368; 11 Aug 93 15:16 EDT
Received: from nic.near.net by nic.near.net id aa13791; 11 Aug 93 15:17 EDT
To: Dave Crocker <dcrocker at mordor.stanford.edu>
cc: Noel Chiappa <jnc at ginger.lcs.mit.edu>, ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
In-reply-to: Your message of Wed, 11 Aug 1993 11:32:43 -0700.
<9308111832.AA19240 at Mordor.Stanford.EDU>
Date: Wed, 11 Aug 1993 15: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: John Curran <jcurran at nic.near.net>
Message-ID: <9308111516.aa23368 at CNRI.Reston.VA.US>
--------
From: Dave Crocker <dcrocker at mordor.stanford.edu>
Subject: Re: Now is the time for radical thinking...
Date: Wed, 11 Aug 93 11:32:43 -0700
...
While I have seen statements of general discomfort, I have not seen
specific analyses which state the specific holes in Steve D's own
analysis. I would like to see some concrete work pursue this, since it
is often described as a show-stopper. One assumes that discomfort at
that level is subject to detailed description and defense.
Dave,
64-bit addresses _will_ work for the global Internet, if indeed SIP
is selected by the marketplace as IPng. 64-bit addresses are compact,
yet quite sufficient for our perceived needs. 64-bit addresses do not
allow imbedded data-link addresses of any significant length, but as many
folks have pointed out, the ability to embed data-link addresses is not
a must-have requirement for autoconfiguration or data-link convergence or
...
In truth, the length of the address does not matter as much as the
allocation policy. We have many IPv4 addresses, it's the allocation
policy based on classes which is our principle problem today. Once
SIP allocation begins, it will be very difficult to reorganize assigned
blocks if needed to make more space for a rapidly growing assignment
authority. SIP has a ample space set aside to handle such problems;
another method would be to use variable length addresses and encourage
the growing authority to assign downward. Either way, it will work.
I'm not sure if I've provided the "detailed description and defense"
that you ask for... In truth we can make 75 bits, or 64 bits, or 53 bits
work, address size simply sets the limits which control policy and either
enables or eliminates various usage options. One of SIP's strengths is
its elimination of spurious modes of usage which are not valued by the
current community.
/John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15276;
11 Aug 93 15:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15266;
11 Aug 93 15:19 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23417;
11 Aug 93 15:19 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15254;
11 Aug 93 15:19 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15158;
11 Aug 93 15:17 EDT
Received: from Sun.COM by CNRI.Reston.VA.US id aa23379; 11 Aug 93 15:17 EDT
Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA09611; Wed, 11 Aug 93 12:17:29 PDT
Received: from auckland.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1)
id AA09888; Wed, 11 Aug 93 12:17:31 PDT
Received: by auckland.Eng.Sun.COM (5.0/SMI-SVR4)
id AA02630; Wed, 11 Aug 93 12:17:13 PDT
Date: Wed, 11 Aug 93 12:17:13 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ross Finlayson <Ross.Finlayson at eng.sun.com>
Message-Id: <9308111917.AA02630 at auckland.Eng.Sun.COM>
To: craig at aland.bbn.com
Subject: Re: RPC scaling (was Re: Now is the time for radical thinking...)
Cc: ietf at CNRI.Reston.VA.US
Reply-To: finlayson at eng.sun.com
X-Sun-Charset: US-ASCII
Content-Length: 3343
> Well, there's some question about whether streaming RPCs is the right
> solution to long delay bandwidth products.
> At any rate, the initial point was classic RPC (the stock of the trade
> these days) is *not* the interface you'd want in the future.
Another approach (similar to streaming) that often works well is to
"chain" two or more operations together in a single RPC invocation.
This is useful if the result of one invocation is intended to be used only
as a parameter to the next invocation. In this case you avoid
returning the response to invocation i, and transmitting the request
for invocation i+1.
Example: To compute F2(F1(p1, p2), p3), you could send a single request
containing F1,F2,p1,p2,p3, along with an indication of how they're
chained together. If your RPC is really "object invocation" (where an
implicit first parameter is used as the target of the invocation), then
the equivalent computation is (o1.F1(p2)).F2(p3), which can be optimized
by invoking a single chained request "F1(p2);F2(p3)" on object o1.
Of course, for this to work well, the object resulting from "o1.F1(p2)"
should be implemented by the same server (or at least on the same LAN)
as o1; this is usually the case. (Also, as with streaming, error handling
is a little trickier than regular RPC.) Chains could be generalized
further to include arbitrary conditional expressions, loops etc.,
effectively giving you full "remote evaluation", but this makes the
implementation much more complex. In contrast, simple, linear chaining
is a useful and easily-implemented special case.
The "Vanguard" experimental distributed OS (a system that I worked on
at Apple, prior to joining Sun a few months ago) made good use of
chaining, even in a single-LAN environment. As well as reducing
round-trip RPCs, chaining also simplifies the protocol suite (because
you can chain together existing operations to define more complex ones).
You can also use a prefix of a chain as a "high-level object id",
which gets rebound on each invocation. For example, a client could
use "o1.F1(p2)" as an opaque object reference "o3". Whenever this gets
invoked e.g., "o3.F2(p3)" - the system would automatically create a chained
request (invisible to the client).
As an aside, on the subject of multicast and RPC: In both Vanguard and
Stanford's "V-System" (from which many of the ideas in Vanguard were
derived), multicast communication was, by default, "1-reliable".
An invoking client would remain blocked until the first response was
returned, so from a client's point of view, a multicast invocation looked
exactly the same as a unicast invocation, with no change to the RPC paradigm.
The "1-reliable" semantics guaranteed only that at least one server
received each request. Vanguard extended this model to support
"n-reliable" semantics: a client could specify that it wanted to
receive "n" responses (or time out), instead of just one. Of course,
in this case the invocation no longer looks exactly like a regular RPC,
because the client has to explicitly expect "n" sets of result parameters.
So, the RPC paradigm can accommodate multicast invocations without a
radical change. (However, that's not to say that there aren't other
uses of multicast (e.g., agreement protocols, multimedia sessions) for
which the RPC model is inappropriate.)
Ross.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15554;
11 Aug 93 15:31 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15544;
11 Aug 93 15:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23891;
11 Aug 93 15:30 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15529;
11 Aug 93 15:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15471;
11 Aug 93 15:29 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa23787;
11 Aug 93 15:29 EDT
Received: by ginger.lcs.mit.edu
id AA24822; Wed, 11 Aug 93 15:30:26 -0400
Date: Wed, 11 Aug 93 15:30:26 -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: <9308111930.AA24822 at ginger.lcs.mit.edu>
To: dcrocker at mordor.stanford.edu, jnc at ginger.lcs.mit.edu
Subject: Re: Now is the time for radical thinking...
Cc: ietf at CNRI.Reston.VA.US, jnc at ginger.lcs.mit.edu
While I have seen statements of general discomfort, I have not seen
specific analyses which state the specific holes in Steve D's own
analysis. I would like to see some concrete work pursue this, since it
is often described as a show-stopper. One assumes that discomfort at
that level is subject to detailed description and defense.
Dave, not everyone agrees that Steve's analysis is the complete answer. For
instance, some people think that the internetwork addresses should include the
physical network address (e.g. 802, X.121, E.164, etc). If this is true (and I
don't propose to rehash that debate here) then Steve's analysis, faultless
though it undoubtedly is, is not really crucial.
This (and similar) basic design issues on fixed length versus variable length
addresses have been discussed at *great* length on the Big-Internet mailing
list. For the most recent interation, see the thread "Comments on Internet
Draft on SIP 64-bit Addressing", starting Fri, 11 Jun 93 in the Big-Internet
archives. If this doesn't meet your request for "detailed description and
defense", I'm unsure of what will satisfy you.
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16153;
11 Aug 93 16:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16143;
11 Aug 93 16:05 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25172;
11 Aug 93 16:05 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16120;
11 Aug 93 16:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16052;
11 Aug 93 16:04 EDT
Received: from eagle.nersc.gov by CNRI.Reston.VA.US id aa25041;
11 Aug 93 16:04 EDT
Date: Wed, 11 Aug 1993 13:04:53 -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: <930811130453.6a at EAGLE.ES.NET>
Subject: Re: Now is the time for radical thinking...
To: ietf at CNRI.Reston.VA.US
X-Vmsmail-To: SMTP%"ietf at cnri.reston.va.us"
Noel,
>....I don't recall anyone predicting a system of this size this soon.
I doubt that we will ever be good a predictions, but (even in the same breath)
I will predict that the network of '96 will be very different from that of '93.
>In light of that choice, when the decision to deploy was made in around 1980
>or so, it was necessary to go with what was on the shelf, i.e. 32-bit numbers,
>landing us in the soup we are in now.
Damn pragmatics, but this a 'grass-is-greener' issue. It is always easy to look
back and point out what was wrong with a decision without thinking about the
set of problems that would have resulted from a different choice.
>The rush to deploy something, and the use of what was already there, caused a
>system to be deployed which is now going to have be replaced after a fairly
>short lifetime, as things go. Was it the right decision? I dunno; in light of
>things at the time, with all the investment in working software, the chance to
>learn more about large networks through experience (it's astonishing how little
>we knew then), etc, and no resources to upgrade, it probably was.
One has to ask what is a reasonable lifetime for a technology. How much has the
basic computing environment changed since 1980? In a world that is changing as
fast in other areas as it is, is 5 years too much to expect from the
communications infrastructure?
>One lesson living through that whole experience has left me with, though, is a
>deep appreciation of the long-term costs of short-term decisions; specifically
>to deploy stuff in a hurry "because it is there". It may be the right decision,
>but the downside down the road can be massive.
You should also listen to those who understand the cost of waiting for the
'perfect solution'. The long term costs of unraveling the hacks that will be
used to extend the life of the existing solution will likely be even higher.
>However, if some as-yet not clearly understood IPngNG is inevitable,...
I would argue that it always will be. Lots of smart people worked on getting
us here, and there are more looking ahead, but our understanding changes over
time and anything we define today will not cut it tomorrow. In fact what we
should probably be spending our time at is not so much the details of solution
X vs. Y, as on a process of moving to the next version every N years. This is
a given in hardware and operating systems, but so far taboo for the network.
Granted the period needs to be longer, but the concept should be established.
>This assumes, of course, that IPv4 can be patched into working for 5 more
>years, but it's not clear to me that CIDR, EID's, NAT, etc can't do it.
A combination of all of the above might do it. Once there it will probably take
10 more years to get out from under and on to the 'right solution' (which will
be wrong by then).
>Oh well, interesting academic speculation, but not anything any of us have
>any control over!
>
> Noel
It needs to be more and someone has to establish control. Not so much to dictate
as to guide through the rocks ahead. People have to be willing to 'let go' and
move on.
Tony
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16247;
11 Aug 93 16:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16237;
11 Aug 93 16:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25321;
11 Aug 93 16:08 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16223;
11 Aug 93 16:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16191;
11 Aug 93 16:07 EDT
Received: from relay.philips.nl by CNRI.Reston.VA.US id aa25256;
11 Aug 93 16:07 EDT
Return-Path: <geertj at ica.philips.nl>
Received: from philica.ica.philips.nl ([130.144.131.1]) by relay.philips.nl with SMTP (5.65c/smail2.5/05-10-87);
id AA08794; Wed, 11 Aug 1993 22:07:12 +0200
Received: from ica02.ica.philips.nl by philica.ica.philips.nl;
id AA10880; Wed, 11 Aug 93 22:07:10 +0200
Received: by ica02.ica.philips.nl
id AA13825; Wed, 11 Aug 93 22:07:09 +0200
Message-Id: <9308112007.AA13825 at ica02.ica.philips.nl>
To: David Herron <david at twg.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
In-Reply-To: Your message of "Wed, 11 Aug 1993 12:11:25 PDT."
<9308111910.AA06163 at eco.twg.com>
Date: Wed, 11 Aug 1993 22:07:06 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Geert Jan de Groot <geertj at ica.philips.nl>
On Wed, 11 Aug 93 12:11:25 PDT David Herron wrote:
> > This assumes, of course, that IPv4 can be patched into working for 5 more
> > years, but it's not clear to me that CIDR, EID's, NAT, etc can't do it.
>
> I just wanna plop out a reminder that there isn't much time left.
>
> My internet service provider (for my home system) was recently assigned
> the 165.113 network. Last year the new networks were in the 140's. This
> is edging up on 192 way quick!
Also, think of all the machines for which the silicon must die in order
to force people to go over. I have the 'pleasure' of having some machines
in my network that are still pre-BSD4.1 it seems.
There is no subnetting, broadcasting-with-ones, and similar problems that
show old code these days. For us networkers the machine gives a lot of
problems.
For the user however, the machine works just fine. He is doing the same
he was doing 5 (6? 7?) years ago when he bought it. The manufacturer
has long folded but maintenance is still provided, i.e. no hope that
that box will ever run something better than it does now, but if a
disk breaks replacements are available.
So, for the user the machine works 'just fine' and there is no incentive
for him to change to something else at this time.
The bottom line is that we networkers have to go to great lengths to
keep the machine working, while it comes 'naturally' to the user.
I know of 3 of these boxes, and there must be several tens scattered
all over the organisation. They are not easily replaced because they
are highly specialized and customized.
Is this a scary thought? Think of the large number of machines that
work quite well using IPv4, but, once IPng comes into place, cannot
migrate. A number of these machines cannot easily be replaced because
they are specialized, and we all know how painful protocol translation is.
What I want is to have next year's machines have a secret switch to
enable IPng, (whatever that will be). This allows me to prepare for
the change on purchase of new machines, and be certain that once it
is time to make the switch, most of the machines in my animal zoo
will be able to make that switch.
For non-high demand applications, the life cycle of a machine can easily
be 4 years or more. Add that to the IPng decision time, and the time to
make the IPng available in most products, and it says how much longer
IPv4 has to be availble. That doesn't sound too good.
Therefore, I too, want IPng to be decided reasonable soon.
Geert Jan
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16374;
11 Aug 93 16:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16364;
11 Aug 93 16:13 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25652;
11 Aug 93 16:13 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16351;
11 Aug 93 16:13 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16311;
11 Aug 93 16:12 EDT
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa25603;
11 Aug 93 16:12 EDT
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12327>; Wed, 11 Aug 1993 13:11:35 PDT
Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 11 Aug 1993 13:11:29 -0700
To: Noel Chiappa <jnc at ginger.lcs.mit.edu>
Cc: deering at parc.xerox.com, ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
In-reply-to: Your message of "Wed, 11 Aug 93 10:10:42 PDT."
<9308111710.AA22028 at ginger.lcs.mit.edu>
Date: Wed, 11 Aug 1993 13:11:23 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: <93Aug11.131129pdt.12171 at skylark.parc.xerox.com>
> As far as address-space scaling goes, a 64-bit hierarchical address space
> can comfortably accommodate tens of thousands of globally-addressable
> devices in every household in the world...
>
> Steve, this cannot be settled by a debate, and in any case this is not the
> appropriate forum, but I just wanted to mention that not everyone agrees with
> the practical precursor to this claim, i.e. that the 64-bit space will
> *usefully* address (i.e. in a way usable in the real world) each household in
> the world...
Noel is right -- I should have prefaced my claim about the adequacy of 64-bit
addresses with "In my technical judgement, ...".
By the way, the IEEE Network article I referred to is also available in
PostScript form from parcftp.xerox.com : pub/sip/ieee-sip-paper.ps.Z.
See the subsection entitled "Are 64-bit Addresses Big Enough" for my
attempt to justify my claim above.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16759;
11 Aug 93 16:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16749;
11 Aug 93 16:38 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26752;
11 Aug 93 16:38 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16736;
11 Aug 93 16:38 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16713;
11 Aug 93 16:36 EDT
Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa26650;
11 Aug 93 16:36 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ak00242;
11 Aug 93 20:27 GMT
Date: Wed, 11 Aug 93 20:32 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: Now is the time for radical thinking...
Message-Id: <51930811203215/0003858921NA2EM at mcimail.com>
I just received my copy of WindowsNT and as promised TCP/IP is in there.
They supply a few client apps and an FTP server. WINSOCK is the interface
for third party stuff...
Bob Moskowitz
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16939;
11 Aug 93 16:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16929;
11 Aug 93 16:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27174;
11 Aug 93 16:45 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16916;
11 Aug 93 16:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16885;
11 Aug 93 16:44 EDT
Received: from tomobiki-cho.cac.washington.edu by CNRI.Reston.VA.US id aa27114;
11 Aug 93 16:44 EDT
Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU
(NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA06259; Wed, 11 Aug 93 13:44:52 -0700
Received: from localhost by Ikkoku-Kan.Panda.COM
(NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA09200; Wed, 11 Aug 93 13:44:44 -0700
Date: Wed, 11 Aug 1993 12:50:31 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mark Crispin <MRC at panda.com>
X-Orig-Sender: Mark Crispin <mrc at ikkoku-kan.panda.com>
Subject: Re: Now is the time for radical thinking...
To: John Curran <jcurran at nic.near.net>
Cc: Dave Crocker <dcrocker at mordor.stanford.edu>,
Noel Chiappa <jnc at ginger.lcs.mit.edu>, ietf at CNRI.Reston.VA.US
In-Reply-To: <9308111516.aa23368 at CNRI.Reston.VA.US>
Message-Id: <MailManager.745098631.8276.mrc at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Friends -
I am a veteran of the previous effort to expand the network address
space. I brought up the first production PDP-10 long leader NCP on the
ARPAnet in 1978 at SU-AI (a.k.a. SAIL). This was an expansion from a packet
switch (IMP) number of 6 bits and port (host) number on that switch of 2 bits,
to an IMP number of 8 bits, a port number of 8 bits, a local port number of 8
bits, and a network number (reserved for future use, and at the time a
constant 10 decimal) of 8 bits.
Internet numbers at the time of the TCP/IP transition in 1983 were formed
from ARPAnet numbers as:
<network>.<port>.<local port>.<IMP>
I think in 1978 only a test TIP at BBN and some UNIX(?) system at NPRDC
were in the stratosphere of ARPAnet addresses. It was big news when SU-AI
could talk to the emerging ARPAnet stratosphere, beating Tenex, TOPS-10, TOPS-
20, and ITS to the punch (although ITS joined us week later).
I noticed some very important things about this transition.
First, the original address space lasted only about 10 years. I don't
know when exactly the plug got pulled on 8-bit addresses. The current address
space has lasted about 15 years.
Second, the number of bits of the address space was quadrupled, 8 -> 32.
Furthermore, new fields were added. Curiously, the 6-bit ARPAnet subnet
address width is not that much different from the most common subnet width in
the Internet today, 8 bits; however, node address width quadrupled.
Third, there was total transparency. 8-bit NCPs and 32-bit NCPs could
talk to each other, totally clueless of any difference. The only restriction
was that 8-bit NCPs couldn't talk to systems in the stratosphere (meaning that
if you were in the stratosphere with a high address. This was very much
unlike the TCP transition.
Fourth, new fields were added to the address. The definitions of those
fields evolved -- network numbers became variable width, the local port idea
got recycled -- but the opportunity was taken to insert new concepts.
This leads me to certain conclusions:
Although the rate of IP address space assignment is continuing to
accelerate, the rate of increase of acceleration is slowing down. This has
led some people to believe that an increase from 32 -> 64 bits will be good
enough. I suspect that it will not. A mere 50% improved lifetime of an
expanded address space is not something to take comfort in when considering a
proposal that is half as ambitious.
It is not at all clear to me that we won't run out of 64 bits. We only
have three data points which isn't enough to determine a curve. It is
arguable that the rate of running out of address space was much worse in 1978
than it is today; there was certainly pent-up demand then when today there is
only a recognition of impending danger.
The long leader NCP transition was much less painful than the TCP
transition. It is a lot easier to add bits to fields and make a packet bigger
than it is to change the fundamental transport model. Those of you who think
this is an opportunity to re-design IP, take note.
I find myself reluctant to support a proposal that is so far reaching,
requires massive changes around the world, and yet only doubles the size of
the address space. I fear that 64 bits will not last my lifetime. Although
rebuilding the network infrastructure may be fascinating and fun for some, I
would like to build something that will continue to be useful in the second
half of the 21st century.
Any new network addressing system should have a significant amount of
address space reserved for future use. Routing is becoming increasingly
difficult because, as is often pointed out, IP addresses have no real
heirarchy to suggest routing. This is only going to get worse when you make
the addresses bigger.
On the other hand, I believe that you need at least 128 bits for a
heirarchical routing address system today (which is why such proposals have
been justifiably shot down).
Another possibility is to abandon IP addresses all together, and go to
names, marrying routing and the DNS. That means 512 bit ``addresses'', since
I think the maximum sized DNS name is still 64 bytes. Of course, that would
give people the idea again that the DNS conveys routing. But I suspect that
is where we will ultimately end up, although perhaps not in our lifetimes.
-- Mark --
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17528;
11 Aug 93 17:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17518;
11 Aug 93 17:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28133;
11 Aug 93 17:07 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17505;
11 Aug 93 17:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17434;
11 Aug 93 17:05 EDT
Received: from decvax.zk3.dec.com by CNRI.Reston.VA.US id aa28036;
11 Aug 93 17:05 EDT
Received: from abyss.zk3.dec.com by decvax.dec.com (5.65/DEC-ULTRIX-8/19/92)
id AA22806; Wed, 11 Aug 1993 17:05:59 -0400
Received: by abyss.zk3.dec.com (5.65/DEC-USSG-ZK3-ULTRIX-09/27/91);
id AA14846; Wed, 11 Aug 1993 17:05:58 -0400
Message-Id: <9308112105.AA14846 at abyss.zk3.dec.com>
To: ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
Date: Wed, 11 Aug 93 17:05:57 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: kaufman at zk3.dec.com
X-Mts: smtp
I'm embarrassed to be sending this to the ietf list, but I didn't pick
the venue for the discussion...
>Some folks have expressed discomfort with 64-bit addresses.
>While I have seen statements of general discomfort, I have not seen
>specific analyses which state the specific holes in Steve D's own
>analysis. I would like to see some concrete work pursue this, since it
>is often described as a show-stopper. One assumes that discomfort at
>that level is subject to detailed description and defense.
I claim it doesn't require a very careful analysis to see that 64 bits
will not last "forever". The internet has been doubling in size every
year for a long time, and while there are reasons why it might slow
down there are also reasons why it might accelerate. Intuition says
that means we need an extra address bit every year. Adding 32 bits
will buy us 32 years. A slightly more careful analysis says that
since we encode hierarchy information in those bits and we are not
great at predicting which parts of the hierarchy will grow fastest, we
can only make 50% efficient use of those bits (which is why we're
feeling the strain even though we have only about 21 bits worth of
hosts). That says 32 bits will buy us 16 years **if we continue to be
as careful administering the address space as we are today**.
Now perhaps given the rate of change of technology it is foolish to
try to plan for a future more than 10 years out. Some other change
will obsolete IPng in that timeframe anyway. But it is nearly certain
that most of us will live to see the day when 64 bits runs out.
--Charlie
(kaufman at zk3.dec.com)
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17866;
11 Aug 93 17:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17856;
11 Aug 93 17:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29084;
11 Aug 93 17:25 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17844;
11 Aug 93 17:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab17805;
11 Aug 93 17:24 EDT
Received: from qualcomm.com by CNRI.Reston.VA.US id aa29014; 11 Aug 93 17:24 EDT
Received: from servo.qualcomm.com by qualcomm.com; id AA07178
sendmail 5.65/QC-main-2.1 via SMTP
Wed, 11 Aug 93 14:21:12 -0700 for ietf at CNRI.Reston.VA.US
Received: by servo; id AA03893
sendmail 5.67/QC-subsidiary-2.1
Wed, 11 Aug 93 14:24:57 -0700 for ses at tipper.oit.unc.edu
Date: Wed, 11 Aug 93 14:24:57 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Phil Karn <karn at qualcomm.com>
Message-Id: <9308112124.AA03893 at servo>
To: 0003858921 at mcimail.com
Cc: ses at tipper.oit.unc.edu, ietf at CNRI.Reston.VA.US
In-Reply-To: "Robert G. Moskowitz"'s message of Tue, 10 Aug 93 11:23 GMT <64930810112346/0003858921NA2EM at mcimail.com>
Subject: Now is the time for radical thinking...
>Just visualize it:
>"For an extra $10 a month you too can get USENET news feeds on any subject
>you want! Or play battle chess with a friend across the country! All you
>need in your home computer, is this nifty $299 interface card that you MUST
>buy from us to insure compatiblity and a low $100 installation and hookup
>fee. This is a one time offer, so hurry. Be the first on your block to get
>ALL the news." BTW, I do not own a TV, let alone Cable TV, juck.
Guess what? It's already on the way! A small startup in Cupertino,
Hybrid Networks, Inc, is doing exactly this right now. You dial into a
conventional SLIP/PPP router to send your packets into the Internet,
while you listen with a special modem to a high speed (currently 5
megabits/s) data stream on a CATV channel. Since most interactive network
users receive much more data than they send, this is a big win. And yes,
the CATV data stream is encrypted.
Dunno when you can actually sign up for commercial service, but I've seen
the system in operation with "friendly users". It works. Very well.
Phil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18895;
11 Aug 93 18:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18885;
11 Aug 93 18:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01821;
11 Aug 93 18:33 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18872;
11 Aug 93 18:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18847;
11 Aug 93 18:32 EDT
Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa01793;
11 Aug 93 18:32 EDT
Received: by inet-gw-2.pa.dec.com; id AA27396; Wed, 11 Aug 93 15:33:29 -0700
Received: by us1rmc.bb.dec.com; id AA08130; Wed, 11 Aug 93 18:32:05 -0400
Message-Id: <9308112232.AA08130 at us1rmc.bb.dec.com>
Received: from ranger.enet; by us1rmc.enet; Wed, 11 Aug 93 18:32:06 EDT
Date: Wed, 11 Aug 93 18:32:06 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Donald E. Eastlake 3rd (Tech. Coord., PW for UNIX products) LKG/BB3, 508-486-6577" <dee at ranger.enet.dec.com>
To: mrc at panda.com
Cc: ietf at CNRI.Reston.VA.US
Apparently-To: ietf at cnri.reston.va.us, mrc at panda.com
Subject: RE: Re: Now is the time for radical thinking...
DNS names can be up to 255 bytes or 2040 bits without compression.
--------------
From: US1RMC::"MRC at panda.com" "Mark Crispin" 11-AUG-1993 17:58
To: John Curran <jcurran at nic.near.net>
CC: Dave Crocker <dcrocker at mordor.stanford.edu>, Noel Chiappa
<jnc at ginger.lcs.mit.edu>, ietf at CNRI.Reston.VA.US
Subj: Re: Now is the time for radical thinking...
Friends -
[...]
Another possibility is to abandon IP addresses all together, and go to
names, marrying routing and the DNS. That means 512 bit ``addresses'', since
I think the maximum sized DNS name is still 64 bytes. Of course, that would
give people the idea again that the DNS conveys routing. But I suspect that
is where we will ultimately end up, although perhaps not in our lifetimes.
-- Mark --
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19022;
11 Aug 93 18:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19012;
11 Aug 93 18:44 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02135;
11 Aug 93 18:44 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19000;
11 Aug 93 18:44 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18978;
11 Aug 93 18:43 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa02108; 11 Aug 93 18:43 EDT
Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA13181 for ietf at cnri.reston.va.us; Wed, 11 Aug 93 18:43:59 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA09358; Wed, 11 Aug 93 15:42:13 PDT
Message-Id: <9308112242.AA09358 at aland.bbn.com>
To: ietf at CNRI.Reston.VA.US
Subject: address sizes
Reply-To: Craig Partridge <craig at aland.bbn.com>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Wed, 11 Aug 93 15:42:12 -0700
X-Orig-Sender: craig at aland.bbn.com
What's the longest phone number (I can't recall) around 13 or 14 digits,
or 10**14?
2^64 is about 10**19. So, assuming some intelligence in parceling out
the address space this time (we've learned, presumably, right?), we run out
of IPng addresses only after the telephone companies run out of phone numbers,
right? (The phone guys want to talk to your toaster too).
Craig
E-mail: craig at aland.bbn.com or craig at bbn.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19146;
11 Aug 93 18:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19133;
11 Aug 93 18:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02766;
11 Aug 93 18:55 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19115;
11 Aug 93 18:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19079;
11 Aug 93 18:54 EDT
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa02667;
11 Aug 93 18:54 EDT
Received: from goshawk.lanl.gov by mailhost.lanl.gov (5.65/1.14)
id AA10292; Wed, 11 Aug 93 16:55:00 -0600
Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17)
id AA28061; Wed, 11 Aug 93 16:55:10 MDT
Message-Id: <9308112255.AA28061 at goshawk.lanl.gov>
To: deering at parc.xerox.com
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
Date: Wed, 11 Aug 93 16:55:09 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
Steve,
The analysis in the SIP paper assumes a particular model of providers,
end systems, and multicast addressing. What if these assumptions are
insufficient to meet future needs? I not only include consideration
just in terms of enumerating providers and end systems, but what if there
are new addressing needs, such as new models of multicasting, needs
for mobility and/or flows, political needs (this is a very real subject in
terms of address administration), etc.
I would like to think that our next address space is flexible
enough to accomodate a model shift and to allow functioning of a variety
of addressing and routing plans at the same time.
While the RISC approach is elegant and very applicable to a static
design, such as a microprocessor, it does not appear to me to be
the right approach for a possibly moving target such as an
Internetwork datagram address.
This discussion should be retitled and moved to the BI list.
peter
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19177;
11 Aug 93 18:56 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19167;
11 Aug 93 18:55 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02788;
11 Aug 93 18:55 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19155;
11 Aug 93 18:55 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19103;
11 Aug 93 18:55 EDT
Received: from tomobiki-cho.cac.washington.edu by CNRI.Reston.VA.US id aa02701;
11 Aug 93 18:55 EDT
Received: from localhost by Tomobiki-Cho.CAC.Washington.EDU
(NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA06340; Wed, 11 Aug 93 15:54:21 -0700
Date: Wed, 11 Aug 1993 15:53: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: Mark Crispin <MRC at cac.washington.edu>
X-Orig-Sender: Mark Crispin <mrc at tomobiki-cho.cac.washington.edu>
Subject: RE: Re: Now is the time for radical thinking...
To: "Donald E. Eastlake 3rd (Tech. Coord., PW for UNIX products) LKG/BB3, 508-486-6577" <dee at ranger.enet.dec.com>
Cc: ietf at CNRI.Reston.VA.US
In-Reply-To: <9308112232.AA08130 at us1rmc.bb.dec.com>
Message-Id: <MailManager.745109626.6332.mrc at Tomobiki-Cho.CAC.Washington.EDU>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 11 Aug 93 18:32:06 EDT, Donald E. Eastlake 3rd (Tech. Coord., PW for
UNIX products) LKG/BB3, 508-486-6577 wrote:
> DNS names can be up to 255 bytes or 2040 bits without compression.
Yes, but aren't they effectively limited to 64 bytes by SMTP? Or has that
limitation been repealed?
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19401;
11 Aug 93 19:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19391;
11 Aug 93 19:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03483;
11 Aug 93 19:18 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19379;
11 Aug 93 19:18 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19338;
11 Aug 93 19:17 EDT
Received: from alpha.Xerox.COM by CNRI.Reston.VA.US id aa03468;
11 Aug 93 19:17 EDT
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <13133>; Wed, 11 Aug 1993 16:17:57 PDT
Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 11 Aug 1993 16:17:55 -0700
To: John Curran <jcurran at nic.near.net>
Cc: ietf at CNRI.Reston.VA.US, deering at parc.xerox.com
Subject: Re: Now is the time for radical thinking...
In-reply-to: Your message of "Wed, 11 Aug 93 12:17:22 PDT."
<9308111516.aa23368 at CNRI.Reston.VA.US>
Date: Wed, 11 Aug 1993 16:17: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: <93Aug11.161755pdt.12171 at skylark.parc.xerox.com>
> Once SIP allocation begins, it will be very difficult to reorganize
> assigned blocks if needed to make more space for a rapidly growing
> assignment authority.
As Paul Francis pointed out some time ago, if we are going to support
a provider-oriented addressing hierarchy (which is our plan), auto-
renumbering has to work. If auto-renumbering works, then we have more
freedom to change the address space allocations over time, i.e., we don't
have to "get it right" from the start, and the allocations can evolve to
track the ebb and flow of providers and their subscribers.
Steve
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19660;
11 Aug 93 19:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19650;
11 Aug 93 19:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04295;
11 Aug 93 19:54 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19637;
11 Aug 93 19:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19615;
11 Aug 93 19:53 EDT
Received: from nic.near.net by CNRI.Reston.VA.US id aa04285; 11 Aug 93 19:53 EDT
Received: from nic.near.net by nic.near.net id aa20752; 11 Aug 93 19:54 EDT
To: Steve Deering <deering at parc.xerox.com>
cc: ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
In-reply-to: Your message of Wed, 11 Aug 1993 16:17:48 -0700.
<93Aug11.161755pdt.12171 at skylark.parc.xerox.com>
Date: Wed, 11 Aug 1993 19:54:04 -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: <9308111953.aa04285 at CNRI.Reston.VA.US>
--------
] From: Steve Deering <deering at parc.xerox.com>
] Subject: Re: Now is the time for radical thinking...
] Date: Wed, 11 Aug 1993 16:17:48 PDT
]
] > Once SIP allocation begins, it will be very difficult to reorganize
] > assigned blocks if needed to make more space for a rapidly growing
] > assignment authority.
]
] As Paul Francis pointed out some time ago, if we are going to support
] a provider-oriented addressing hierarchy (which is our plan), auto-
] renumbering has to work. If auto-renumbering works, then we have more
] freedom to change the address space allocations over time, i.e., we don't
] have to "get it right" from the start, and the allocations can evolve to
] track the ebb and flow of providers and their subscribers.
I agree that auto-renumbering is going to have to work if IPng is
going to be useful. I was not referring to the technical difficulty
of reallocation, but the administrative and political issues which
make address space reallocation problematic. Even with wonderful
technical support, I'm not confident that ISOC/IAB/IR can successfully
"take back" and reallocate any significant portion of an address space.
Sorry for the confusion in my initial message.
/John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19787;
11 Aug 93 20:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19777;
11 Aug 93 20:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04517;
11 Aug 93 20:08 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19765;
11 Aug 93 20:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19728;
11 Aug 93 20:07 EDT
Received: from black-ice.cc.vt.edu by CNRI.Reston.VA.US id aa04495;
11 Aug 93 20:07 EDT
Received: by black-ice.cc.vt.edu (AIX 3.2/UCB 5.64/4.03)
id AA18392; Wed, 11 Aug 1993 20:08:31 -0400
Message-Id: <9308120008.AA18392 at black-ice.cc.vt.edu>
To: Craig Partridge <craig at aland.bbn.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: address sizes
In-Reply-To: Your message of "Wed, 11 Aug 1993 15:42:12 EDT."
<9308112242.AA09358 at aland.bbn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 11 Aug 1993 20:08:31 +22312049
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Valdis Kletnieks <valdis at black-ice.cc.vt.edu>
On Wed, 11 Aug 1993 15:42:12 EDT, you said:
> 2^64 is about 10**19. So, assuming some intelligence in parceling out
> the address space this time (we've learned, presumably, right?), we run out
> of IPng addresses only after the telephone companies run out of phone numbers
,
> right? (The phone guys want to talk to your toaster too).
Craig:
We've not learned.
Witness the pain and confusion in various parts of the US as we
run out of area codes that have a '0' or '1' as the first digit,
the infamous 'You must dial a one and then the area code' recorded
message, and so forth.
The single biggest argument against the 64-bit fixed length
address IPng contenders is the fact that we have *NOT* learned
how to do address allocation efficiently - ask anybody in those
parts of New York City who were forcibly evicted from the 212
area code.... And then ask yourself how we intend to avoid
similar debacles on the digital side.
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19990;
11 Aug 93 20:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19979;
11 Aug 93 20:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05062;
11 Aug 93 20:33 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa19966;
11 Aug 93 20:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa19942;
11 Aug 93 20:32 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa05032;
11 Aug 93 20:32 EDT
Received: by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA02238>; Wed, 11 Aug 1993 17:32:54 -0700
Date: Wed, 11 Aug 1993 17:32:54 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Bob Braden <braden at isi.edu>
Message-Id: <199308120032.AA02238 at zephyr.isi.edu>
To: deering at parc.xerox.com, jcurran at nic.near.net
Subject: Re: Now is the time for radical thinking...
Cc: ietf at CNRI.Reston.VA.US
Even with wonderful
*> technical support, I'm not confident that ISOC/IAB/IR can successfully
*> "take back" and reallocate any significant portion of an address space.
*> Sorry for the confusion in my initial message.
*>
*> /John
*>
John,
That's an interesting challenge. CIDR will give us an opportunity to
try the experiment.
Bob Braden
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20059;
11 Aug 93 20:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20049;
11 Aug 93 20:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05148;
11 Aug 93 20:35 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20036;
11 Aug 93 20:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20001;
11 Aug 93 20:34 EDT
Received: from uu2.psi.com by CNRI.Reston.VA.US id aa05100; 11 Aug 93 20:34 EDT
Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP;
id AA27796 for ietf at CNRI.Reston.VA.US; Wed, 11 Aug 93 20:35:29 -0400
Received: by aland.bbn.com (4.1/3.1.090690-BBN)
id AA09964; Wed, 11 Aug 93 17:33:40 PDT
Message-Id: <9308120033.AA09964 at aland.bbn.com>
To: Valdis Kletnieks <valdis at black-ice.cc.vt.edu>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: address sizes
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Craig Partridge <craig at aland.bbn.com>
Date: Wed, 11 Aug 93 17:33:39 -0700
X-Orig-Sender: craig at aland.bbn.com
> Witness the pain and confusion in various parts of the US as we
> run out of area codes that have a '0' or '1' as the first digit,
> the infamous 'You must dial a one and then the area code' recorded
> message, and so forth.
Valdis:
I think the 0/1 dialing problem is interface rather than numbering
scheme -- an attempt to make what should have been a fixed-length numbering
system into a variable-length, relative-to-where-you-are numbering scheme.
(Done for good human factors reasons, but reasons which don't applyt
to computers).
As for changing area codes to support 0/1 in the middle digit, and splitting
New York, I don't view this as a problem either -- as a network gets filled we
split its hosts and allocate new numbers. Works fine. Again, human factors
as folks get attached to their numbers (remember when folks expected the
first part of their phone number to indicate the part of town they were
in -- my grandmother's number used to start UNiversity 5 in NYC, to indicate
she lived near Columbia), but no real allocation problem.
One of my concerns is that folks are talking about *big* and *variable*
length addresses as the solution. A discussion earlier this month suggested
that while variable was OK, mixing variable sizes with potentially large
sizes is has disturbing performance implications.
I'm happy to cope with small variable addresses, or (if I must) really
big fixed sized addresses. I'd really like to avoid big and variable.
(Note this is from the perspective of someone who is spending most of his
time doing gigabit networking research and thus worries about things like
how to forward hundreds of millions of IPng packets per second).
Craig
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20371;
11 Aug 93 21:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20361;
11 Aug 93 21:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06101;
11 Aug 93 21:12 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20337;
11 Aug 93 21:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20291;
11 Aug 93 21:11 EDT
Received: from quern.epilogue.com by CNRI.Reston.VA.US id aa06042;
11 Aug 93 21:11 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Rob Austein <sra at epilogue.com>
X-Orig-Sender: sra at epilogue.com
To: Mark Crispin <mrc at cac.washington.edu>
CC: "Donald E. Eastlake, III" <dee at ranger.enet.dec.com>,
ietf at CNRI.Reston.VA.US
In-reply-to: Mark Crispin's message of Wed, 11 Aug 1993 15:53:46 -0700 (PDT) <MailManager.745109626.6332.mrc at Tomobiki-Cho.CAC.Washington.EDU>
Subject: Re: Now is the time for radical thinking...
Date: Wed, 11 Aug 93 21:12:03 EDT
Message-ID: <9308112112.aa02485 at quern.epilogue.com>
Mark,
The current de jure limit on hostname length is RFC-1123 section 2.1.
The "MUST support" limit is 64, the "SHOULD support" limit is 255.
--Rob Austein <sra at epilogue.com>
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20387;
11 Aug 93 21:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20373;
11 Aug 93 21:12 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06109;
11 Aug 93 21:12 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20339;
11 Aug 93 21:12 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20299;
11 Aug 93 21:11 EDT
Received: from nic.near.net by CNRI.Reston.VA.US id aa06059; 11 Aug 93 21:11 EDT
Received: from bronze.near.net by nic.near.net id aa27669; 11 Aug 93 21:12 EDT
To: Bob Braden <braden at isi.edu>
cc: deering at parc.xerox.com, ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
In-reply-to: Your message of Wed, 11 Aug 1993 17:32:54 -0700.
<199308120032.AA02238 at zephyr.isi.edu>
Date: Wed, 11 Aug 1993 21:09:30 -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: <9308112111.aa06059 at CNRI.Reston.VA.US>
--------
] From: Bob Braden <braden at isi.edu>
] Subject: Re: Now is the time for radical thinking...
] Date: Wed, 11 Aug 1993 17:32:54 -0700
]
] *> Even with wonderful
] *> technical support, I'm not confident that ISOC/IAB/IR can successfully
] *> "take back" and reallocate any significant portion of an address space.
] ...
] That's an interesting challenge. CIDR will give us an opportunity to
] try the experiment.
Are you certain that there is a parallel here? Minor renumbering to
maximize aggregration will certainly occur over the course of CIDR
deployment (in fact, has already begun). But so far there has been
little discussion of reallocation of entire blocks of addresses.
CIDR will let us try an experiment with a small installed base
(today's Internet). Depletion of one branch of the SIP allocation
tree will be much more interesting involving an order of magnitude
more systems. I presumed that SIP would handle this through the
allocation of the currently reserved blocks, but if (as Steve suggests)
auto-renumbering will solve it, then even better.
/John
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20444;
11 Aug 93 21:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20434;
11 Aug 93 21:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06177;
11 Aug 93 21:14 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20421;
11 Aug 93 21:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20395;
11 Aug 93 21:13 EDT
Received: from gibbs.oit.unc.edu by CNRI.Reston.VA.US id aa06144;
11 Aug 93 21:13 EDT
Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1)
id AA23549; Wed, 11 Aug 93 21:14:09 -0400
Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1)
id AA20390; Wed, 11 Aug 93 21:16:31 EDT
Message-Id: <9308120116.AA20390 at tipper>
X-Really-To: gibbs.oit.unc.edu
To: Valdis Kletnieks <valdis at black-ice.cc.vt.edu>
Cc: Craig Partridge <craig at aland.bbn.com>, ietf at CNRI.Reston.VA.US
Subject: Re: address sizes
In-Reply-To: Your message of "Wed, 11 Aug 93 20:08:31."
<9308120008.AA18392 at black-ice.cc.vt.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 11 Aug 93 21:16:31 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Simon E Spero <ses at tipper.oit.unc.edu>
Would everybody who's 100% sure that 64bits will suffice for all time please
send me all their RAM in excess of 640K? I'm running NT so I need it more
than you.
P.s.
Isn't it time to take this over to big-internet. We haven't had an
address size war there for ,oooh, days.
Simon // that factory fire - adds a whole new meaning to smoking some resin.
----
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 aa20581;
11 Aug 93 21:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20571;
11 Aug 93 21:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06593;
11 Aug 93 21:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20558;
11 Aug 93 21:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20519;
11 Aug 93 21:28 EDT
Received: from tadpole.Tadpole.COM by CNRI.Reston.VA.US id aa06575;
11 Aug 93 21:28 EDT
Received: from chiba.tadpole.com by tadpole.tadpole.com (4.1/SMI-4.1)
id AA13545; Wed, 11 Aug 93 20:29:00 CDT
Received: by chiba.tadpole.com (5.0/SMI-SVR4)
id AA10876; Wed, 11 Aug 1993 20:25:23 +0600
Date: Wed, 11 Aug 1993 20:25:23 +0600
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jim Thompson <jim at tadpole.com>
Message-Id: <9308120125.AA10876 at chiba.tadpole.com>
To: mrc at cac.washington.edu, sra at epilogue.com
Subject: Re: Now is the time for radical thinking...
Cc: dee at ranger.enet.dec.com, ietf at CNRI.Reston.VA.US
X-Sun-Charset: US-ASCII
Content-Length: 695
> From ietf-request at ietf.nri.reston.va.us Wed Aug 11 20:25:28 1993
> Sender: ietf-request at IETF.CNRI.Reston.VA.US
> From: Rob Austein <sra at epilogue.com>
> X-Orig-Sender: sra at epilogue.com
> To: Mark Crispin <mrc at cac.washington.edu>
> Cc: "Donald E. Eastlake, III" <dee at ranger.enet.dec.com>,
> ietf at CNRI.Reston.VA.US
> Subject: Re: Now is the time for radical thinking...
> Date: Wed, 11 Aug 93 21:12:03 EDT
>
> Mark,
>
> The current de jure limit on hostname length is RFC-1123 section 2.1.
> The "MUST support" limit is 64, the "SHOULD support" limit is 255.
Say, "thank you very much" to Sun, who got people on the HR RFC team
to keep from having to change their braindamage.
Jim
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24485;
11 Aug 93 23:06 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24470;
11 Aug 93 23:06 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa09024;
11 Aug 93 23:06 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24451;
11 Aug 93 23:05 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24424;
11 Aug 93 23:04 EDT
Received: from gibbs.oit.unc.edu by CNRI.Reston.VA.US id aa08972;
11 Aug 93 23:04 EDT
Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1)
id AA29016; Wed, 11 Aug 93 23:05:23 -0400
Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1)
id AA20476; Wed, 11 Aug 93 23:07:45 EDT
Message-Id: <9308120307.AA20476 at tipper>
X-Really-To: gibbs.oit.unc.edu
To: ietf at CNRI.Reston.VA.US
Subject: Re: address sizes , and the radical side IPNG
In-Reply-To: Your message of "Wed, 11 Aug 93 17:33:39 PDT."
<9308120033.AA09964 at aland.bbn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 11 Aug 93 23:07:45 -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>
Craig Partridge <craig at aland.bbn.com> writes:
>
> I'm happy to cope with small variable addresses, or (if I must) really
>big fixed sized addresses. I'd really like to avoid big and variable.
>(Note this is from the perspective of someone who is spending most of his
>time doing gigabit networking research and thus worries about things like
>how to forward hundreds of millions of IPng packets per second).
>
If we must have a fixed 64bit quantity, why not let it encode the MTU size :-)
Actually, I think it's an EID thing. We need something relatively
short so we can easily identify the destination for a packet. That's what
EIDs are for. We need something to tell us where that endpoint lives -
addresses . Then we need something to tell us how to get there -routing doo-dabs.
I find it much easier to envisage a scalable system based on 'flow-a-grams'-
mostly switching on EIDS and ignoring the address unless it changes. In a
multimedia world, the bulk of traffic will be acting in a connection oriented
way, with resource reservation, and a radically different approach to packet
loss and transmission errors - if it's not there in time for the next frame,
forget it, I don't want it - and don't expect a tip. In such a world,
the ability to have variable length addresses which can be created dynamically
at setup, and change during the life of the session seems essential.
Resource reservation could have a massive effect on routing paradigms. In
the current paradigm, there seems to be an implicit assumption that if
a packet to a certain destination took a particular route, then that is a
good route to take for another packet. With resource reservation, packets
to the same destination but on different 'flows' are likely to take
radically different routes.
Suppose I borrow a few million dollars, and run some fibre along the
railway tracks from Raleigh to Washington, and stick some switches and
routers onto each end. Now, since any bandwidth I don't sell is gone for
good, I'll want to advertise at a good price to sell. However, since I'm
taking reservations (higher price, more profit), I don't want to over
commit. Any policy based routing system worthy of the name will have
to support some sort of true Routing Information Exchange, as well as
a Routing Information Futures Market -
"One point five megabits RDU-WAS, 10:15 - 10-30; offer 256, bid 254".
Imagine if 50 other people had the same idea. Imagine none of them having
enough guaranteed bandwidth to meet a request, so a route via charlotte is
needed. For a given connection, the path might remain fairly constant,
modulo the occasional outage, or a blue-light special on another link, but
across connections there'd be huge differences.
Message: address is just a source route with nothing left to loose.
Radical IPNG-
[ On behalf of the children of the Thatcher-Reagan era,
I'd like to make the following statement; you spent our money for your tax
cuts, and take the payments for your pensions.
You built and bought your cars with dirty engines, and took them to the
drive-thru so we could serve you burgers.
You cut down all our forests, and what you couldn't cut, you poisoned.
Now it's time to make another choice, and you say "Not in my lifetime".
Not in your lifetime,
In our lifetime.
Make the right choice. The power to choose. ]
-----
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 aa00879;
12 Aug 93 4:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00869;
12 Aug 93 4:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa01107;
12 Aug 93 4:57 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00857;
12 Aug 93 4:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00812;
12 Aug 93 4:48 EDT
Received: from mitsou.inria.fr by CNRI.Reston.VA.US id aa00979;
12 Aug 93 4:48 EDT
Received: by mitsou.inria.fr
(5.65c/IDA-1.2.8) id AA01785; Thu, 12 Aug 1993 10:46:39 +0200
Message-Id: <199308120846.AA01785 at mitsou.inria.fr>
To: kaufman at zk3.dec.com
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
In-Reply-To: Your message of "Wed, 11 Aug 93 17:05:57 EDT."
<9308112105.AA14846 at abyss.zk3.dec.com>
Date: Thu, 12 Aug 93 10:46:37 +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>
=> I claim it doesn't require a very careful analysis to see that 64 bits
=> will not last "forever". The internet has been doubling in size every
=> year for a long time, and while there are reasons why it might slow
=> down there are also reasons why it might accelerate. Intuition says
=> that means we need an extra address bit every year. Adding 32 bits
=> will buy us 32 years. A slightly more careful analysis says that
=> since we encode hierarchy information in those bits and we are not
=> great at predicting which parts of the hierarchy will grow fastest, we
=> can only make 50% efficient use of those bits (which is why we're
=> feeling the strain even though we have only about 21 bits worth of
=> hosts). That says 32 bits will buy us 16 years **if we continue to be
=> as careful administering the address space as we are today**.
=>
=> Now perhaps given the rate of change of technology it is foolish to
=> try to plan for a future more than 10 years out. Some other change
=> will obsolete IPng in that timeframe anyway. But it is nearly certain
=> that most of us will live to see the day when 64 bits runs out.
=>
=> --Charlie
=> (kaufman at zk3.dec.com)
Charlie,
I think there are a couple of flaws in your analysis. You are mixing two
things:
1) The efficiency of address of allocation, which tells us essentially "how
many numbers an address consume",
2) The rate of growth.
The "50%" figure that you quote is part of the "efficiency of address
allocation". It explain why we feel limited today with 32 bits addresses,
although we only have something like 2 million hosts -- a far cry from the 7
billions that 32 bits allow. If one assume that 64 bits assignment will
be "about as efficient" as the current 32 bits assignment, there is thus no
need to "divide by two" the 32 years that you mention.
In fact, one should point out that, according to opinions expressed during the
Amsterdam IETF debates, we still have breathing space with the 32 bits
addresses; depending how strongly you believe in CIDR, figures varying between
5 and 10 years were quoted. If that is true, then 64 bits would last from 37
to 42 years.
I do indeed hope to live that long. But, as you mention, there are all reasons
to believe that so many things will have changed by then that we will have to
change our networking practices anyhow. Besides, who does really believe in
sustained exponential growth, at a rate of 100% a year, for a period of 40
years? This rate is typical of a "booming" industry; but booming industries
get mature some day. The PeeCee market was growing that fast for a period; it
is now sustaining a solid 20% growth, which may well be a better predictor of
the Internet future...
An other way to look at the numbers is to start from a likely "final target",
say 10**12 hosts. This is only 500000 times more than the current picture,
i.e. 2**19; which means that adding 19 bits to the current 32 would be
sufficient.
So, if one can show advantages in a simple 64 bits format, why not use these
adavantages?
Christian Huitema
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01846;
12 Aug 93 7:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01836;
12 Aug 93 7:40 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03751;
12 Aug 93 7:40 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01790;
12 Aug 93 7:39 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01752;
12 Aug 93 7:38 EDT
Received: from mcigateway.mcimail.com by CNRI.Reston.VA.US id aa03711;
12 Aug 93 7:38 EDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id af25773;
12 Aug 93 11:29 GMT
Date: Thu, 12 Aug 93 11: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 CNRI.Reston.VA.US>
Subject: Re: address sizes
Message-Id: <52930812113125/0003858921NA2EM at mcimail.com>
Valdis Kletnieks said:
>The single biggest argument against the 64-bit fixed length
>address IPng contenders is the fact that we have *NOT* learned
>how to do address allocation efficiently - ask anybody in those
>parts of New York City who were forcibly evicted from the 212
>area code.... And then ask yourself how we intend to avoid
>similar debacles on the digital side.
And Baltimore, and coming soon Detroit (we've been told that our switch date
in Aug '94), and...
Bob
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03000;
12 Aug 93 8:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02990;
12 Aug 93 8:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05029;
12 Aug 93 8:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02978;
12 Aug 93 8:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02924;
12 Aug 93 8:28 EDT
Received: from smcvax.smcvt.edu by CNRI.Reston.VA.US id aa04978;
12 Aug 93 8:28 EDT
Received: from SMCVAX.SMCVT.EDU by SMCVAX.SMCVT.EDU (PMDF #3520 ) id
<01H1NGF3P7WC8ZEP13 at SMCVAX.SMCVT.EDU>; Thu, 12 Aug 1993 08:22:13 EST
Date: 12 Aug 1993 08:22:13 -0500 (EST)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Gary C. Kessler, +1 802-655-8633" <KUMQUAT at smcvax.smcvt.edu>
Subject: Address sizes
To: ietf at CNRI.Reston.VA.US
Message-id: <01H1NGF3PHJI8ZEP13 at SMCVAX.SMCVT.EDU>
X-VMS-To: IN%"ietf at cnri.reston.va.us"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Craig Partridge asked
What's the longest phone number (I can't recall) around 13 or 14 digits,
or 10**14?
According to E.164 (ISDN Numbering Plan), an ISDN number can be up to 15
digits although some administrations may allow register capabilities up
to 16 or 17 digits. Neither take into account the <=40-digit subaddress!
(Strictly speaking, the network doesn't have to bother with the
subaddress necessarily, but one never knows.)
/gary kessler
Hill Associates
Colchester, VT
+1 802-655-8633
kumquat at smcvax.smcvt.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07705;
12 Aug 93 11:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07696;
12 Aug 93 11:22 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11114;
12 Aug 93 11:22 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07659;
12 Aug 93 11:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07612;
12 Aug 93 11:20 EDT
Received: from TURBO.Kean.EDU by CNRI.Reston.VA.US id aa11039;
12 Aug 93 11:20 EDT
Received: (from user akc) by TURBO.Kean.EDU; 12 Aug 93 10:45:56 EST
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: "Al Costanzo"@CNRI.Reston.VA.US,
Associate Director - Computer Services <AKC at turbo.kean.edu>
Subject: Address sizes
Encoding: 12 text (note by akc), 40 message (from KUMQUAT)
Date: 12 Aug 93 10:45:56 EST
Message-ID: <9308121120.aa11039 at CNRI.Reston.VA.US>
Hi,
At Kean College of New Jersey we -DO- do subaddressing on our nailed up
B channel which feeds a cisco router. Works well. Also consider
something that "looks like" a DNIC in the x.25 world that we use to
route an x.25 call out of a X.25 cloud and into the ISDN scheme of things.
Regards,
Al Costanzo
---- original message:
Return-Path: <@TURBO.Kean.EDU:ietf-request at List.Kean.EDU>
Received: from TURBO.Kean.EDU by TURBO.Kean.EDU; 12 Aug 93 08:48:30 EST
Received: from IETF.nri.reston.VA.US by TURBO.Kean.EDU; 12 Aug 93 08:43:03 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02941;
12 Aug 93 8:28 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02924;
12 Aug 93 8:28 EDT
Received: from smcvax.smcvt.edu by CNRI.Reston.VA.US id aa04978;
12 Aug 93 8:28 EDT
Received: from SMCVAX.SMCVT.EDU by SMCVAX.SMCVT.EDU (PMDF #3520 ) id
<01H1NGF3P7WC8ZEP13 at SMCVAX.SMCVT.EDU>; Thu, 12 Aug 1993 08:22:13 EST
Date: 12 Aug 1993 08:22:13 -0500 (EST)
Sender:ietf-request at IETF.CNRI.Reston.VA.US
From: "Gary C. Kessler, +1 802-655-8633" <KUMQUAT at smcvax.smcvt.edu>
Subject: Address sizes
To: ietf at CNRI.Reston.VA.US
Message-id: <01H1NGF3PHJI8ZEP13 at SMCVAX.SMCVT.EDU>
X-VMS-To: IN%"ietf at cnri.reston.va.us"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Reply-To: ietf at List.Kean.EDU, "Gary C. Kessler, +1 802-655-8633" <KUMQUAT at smcvax.smcvt.edu>
Craig Partridge asked
What's the longest phone number (I can't recall) around 13 or 14 digits,
or 10**14?
According to E.164 (ISDN Numbering Plan), an ISDN number can be up to 15
digits although some administrations may allow register capabilities up
to 16 or 17 digits. Neither take into account the <=40-digit subaddress!
(Strictly speaking, the network doesn't have to bother with the
subaddress necessarily, but one never knows.)
/gary kessler
Hill Associates
Colchester, VT
+1 802-655-8633
kumquat at smcvax.smcvt.edu
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10499;
12 Aug 93 13:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10491;
12 Aug 93 13:47 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16358;
12 Aug 93 13:47 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10468;
12 Aug 93 13:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10394;
12 Aug 93 13:44 EDT
Received: from phelix.bellcore.com by CNRI.Reston.VA.US id aa16272;
12 Aug 93 13:44 EDT
Received: by phelix.ims.bellcore.com id AA29160
(5.65c/IDA-1.4.4 for ietf at cnri.reston.va.us); Thu, 12 Aug 1993 13:43:36 -0400
Date: Thu, 12 Aug 1993 13:43:36 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jill Weber <jill at phelix.ims.bellcore.com>
Message-Id: <199308121743.AA29160 at phelix.ims.bellcore.com>
To: ietf at CNRI.Reston.VA.US
Subject: unsubscribe
Please unsubscribe Peter Clitherow`s name that is
associated with the machine alex.ims.bellcore.com.
The machine alex.ims.bellcore.com is no longer
in use and Peter Clitherow is no longer part of Bellcore.
Jill
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12332;
12 Aug 93 15:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19439;
12 Aug 93 15:11 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12317;
12 Aug 93 15:11 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12250;
12 Aug 93 15:07 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: atommib 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-atommib-sonet-00.txt
Date: Thu, 12 Aug 93 15:07:25 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308121507.aa12250 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 ATM MIB Working Group of the
IETF.
Title : Definitions of Managed Objects for the SONET/SDH
Interface Type
Author(s) : Tracy Brown, Kaj Tesink
Filename : draft-ietf-atommib-sonet-00.txt
Pages : 82
Note: This Internet-Draft is the update for draft-ietf-cox-sonetmib-02.txt
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing Synchronous
Optical Network/Synchronous Digital Hierarchy (SONET/SDH) objects. This
document is a companion document with Definitions of Managed Objects for
the DS1/E1 and DS3/E3 Interface Types, RFC1406 [14] and RFC1407 [13].
This memo specifies a MIB module in a manner that is both compliant to the
SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
[Temporary Note: Upon progression of this specification as a Proposed
Standard, an SNMPv2 and an SNMPv1 version of this MIB module will be made
available to ease migration.]
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-atommib-sonet-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-atommib-sonet-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-atommib-sonet-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atommib-sonet-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 aa12609;
12 Aug 93 15:18 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19727;
12 Aug 93 15:18 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12596;
12 Aug 93 15:18 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12473;
12 Aug 93 15:15 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-houttuin-rfc1327-tutor-03.txt
Date: Thu, 12 Aug 93 15:15:40 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308121515.aa12473 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : A tutorial on gatewaying between X.400 and Internet mail
Author(s) : J. Houttuin
Filename : draft-houttuin-rfc1327-tutor-03.txt
Pages : 17
There are many ways in which X.400 and Internet (RFC 822) mail systems can
be interconnected. Addresses and service elements can be mapped onto each
other in different ways. From the early available gateway implementations,
one was not necessarily better than any other, but the sole fact that each
handled the mappings in a different way led to major interworking problems,
especially when a message (or address) crossed more than one gateway. The
need for one global standard on how to implement X.400 - Internet mail
gatewaying was satisfied by the Internet Request For Comments 1327,
"Mapping between X.400(1988)/ISO 10021 and RFC 822."
This tutorial was produced especially to help new gateway managers find
their way into the complicated subject of mail gatewaying according to
RFC 1327. The need for such a tutorial can be illustrated by quoting the
following discouraging paragraph from RFC 1327, chapter 1: "Warning: the
remainder of this specification is technically detailed. It will not make
sense, except in the context of RFC 822 and X.400 (1988). Do not attempt
to read this document unless you are familiar with these specifications."
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-houttuin-rfc1327-tutor-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-houttuin-rfc1327-tutor-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-houttuin-rfc1327-tutor-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-houttuin-rfc1327-tutor-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 aa12979;
12 Aug 93 15:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20060;
12 Aug 93 15:25 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12957;
12 Aug 93 15:25 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12763;
12 Aug 93 15:23 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: thinosi at ulcc.ac.uk
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-thinosi-cookbook-00.txt
Date: Thu, 12 Aug 93 15:23:26 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308121523.aa12763 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 Minimal OSI Upper-Layers
Working Group of the IETF.
Title : Octet sequences for upper-layer OSI to support basic
communications applications
Author(s) : P. Furniss
Filename : draft-ietf-thinosi-cookbook-00.txt
Pages : 28
This document specifies those elements of the OSI upper-layer protocols
(Session, Presentation and ACSE) needed to support applications with "basic
communications requirements". These include OSI application protocols such
as X.400 P7 and Directory Access Protocol, and "migrant" protocols,
originally defined for use over other transports.
The upper-layer protocol elements are specified in this document as the
particular octet sequences that comprise an "envelope" around the
application protocol's data. It therefore independent, as a document, from
the OSI base standards, although an implementation based on this document
will be able to interwork with an implementation based on the base
standard, when both are being used to support an appropriate application
protocol.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-thinosi-cookbook-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-thinosi-cookbook-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-thinosi-cookbook-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-thinosi-cookbook-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 aa13056;
12 Aug 93 15:26 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20090;
12 Aug 93 15:26 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13022;
12 Aug 93 15:26 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12823;
12 Aug 93 15:24 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at ucdavis.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-pppext-lcp-main-01.txt
Date: Thu, 12 Aug 93 15:24:11 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308121524.aa12823 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 Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : The Point-to-Point Protocol (PPP)
Author(s) : W. Simpson
Filename : draft-ietf-pppext-lcp-main-01.txt
Pages : 61
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP is
comprised of three main components:
1. A method for encapsulating multi-protocol datagrams.
2. A Link Control Protocol (LCP) for establishing, configuring,
and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for establishing and
configuring different network-layer protocols.
This document defines the PPP organization and methodology, and the PPP
encapsulation, together with an extensible option negotiation mechanism
which is able to negotiate a rich assortment of configuration parameters
and provides additional management functions. The PPP Link Control
Protocol (LCP) is described in terms of this mechanism.
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-pppext-lcp-main-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-pppext-lcp-main-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-pppext-lcp-main-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-lcp-main-01.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 aa13144;
12 Aug 93 15:27 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20159;
12 Aug 93 15:27 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13100;
12 Aug 93 15:27 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12907;
12 Aug 93 15:25 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-labarre-iimc-mibii-03.txt, .ps
Date: Thu, 12 Aug 93 15:25:08 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308121525.aa12907 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : ISO/CCITT and Internet Management Coexistence (IIMC):
Translation of Internet MIB-II (RFC1213) to ISO/CCITT
GDMO MIB (IIMCMIB-II)
Author(s) : L. LaBarre
Filename : draft-labarre-iimc-mibii-03.txt, .ps
Pages : 102
This document is intended to facilitate the multi-protocol management
coexistence and interworking for networks that are managed using the
ISO/CCITT Common Management Information Protocol (CMIP) and networks that
are managed using the Internet Simple Network Management Protocol (SNMP).
This document contains the ISO/CCITT GDMO definition and registration of
MIB-II as derived from the Internet MIB-II [RFC1213], according to the
procedures defined in "Translation of Internet MIBs to ISO/CCITT GDMO MIBs"
[IIMCIMIBTRANS]. In addition, this document includes a translated
IPForwarding Table as derived from the Internet definition in [RFC1354].
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-labarre-iimc-mibii-03.txt".
Or
"get draft-labarre-iimc-mibii-03.ps".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-labarre-iimc-mibii-03.txt".
Or
"SEND draft-labarre-iimc-mibii-03.ps".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-labarre-iimc-mibii-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-labarre-iimc-mibii-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 aa13216;
12 Aug 93 15:28 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20220;
12 Aug 93 15:28 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13168;
12 Aug 93 15:28 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12978;
12 Aug 93 15:26 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-labarre-internetmib-iso-03.txt, .ps
Date: Thu, 12 Aug 93 15:25:59 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308121526.aa12978 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : ISO/CCITT and Internet Management Coexistence (IIMC):
Translation of Internet MIBs to ISO/CCITT GDMO MIBs
(IIMCIMIBTRANS)
Author(s) : L. LaBarre
Filename : draft-labarre-internetmib-iso-03.txt, .ps
Pages : 59
This document is intended to facilitate the multi-protocol management
coexistence and interworking for networks that are managed using the
ISO/CCITT Common Management Information Protocol (CMIP) and networks that
are managed using the Internet Simple Network Management Protocol (SNMP).
This document contains translation and registration procedures that are
applicable to translation of Internet MIBs, defined according to the
Internet Structure of Management Information (SMI), into ISO/CCITT
SMI-defined MIBs. This document also defines and registers generic
management information that may be used with the translation procedures to
facilitate interoperability.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-labarre-internetmib-iso-03.txt".
Or
"get draft-labarre-internetmib-iso-03.ps".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-labarre-internetmib-iso-03.txt".
Or
"SEND draft-labarre-internetmib-iso-03.ps".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-labarre-internetmib-iso-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-labarre-internetmib-iso-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 aa13314;
12 Aug 93 15:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20382;
12 Aug 93 15:29 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13298;
12 Aug 93 15:29 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13179;
12 Aug 93 15:27 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: if-mib 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-ifmib-evolution-02.txt
Date: Thu, 12 Aug 93 15:27:53 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308121527.aa13179 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 Interfaces MIB Working Group
of the IETF.
Title : Evolution of the Interfaces Group of MIB-II
Author(s) : K. McCloghrie, F. Kastenholz
Filename : draft-ietf-ifmib-evolution-02.txt
Pages : 56
Abstract not provided.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-ifmib-evolution-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-ifmib-evolution-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-ifmib-evolution-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ifmib-evolution-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 aa13356;
12 Aug 93 15:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20456;
12 Aug 93 15:30 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13344;
12 Aug 93 15:30 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13260;
12 Aug 93 15:28 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: bridge-mib at pa.dec.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-bridge-sr-objects-03.txt
Date: Thu, 12 Aug 93 15:28:37 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308121528.aa13260 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 Bridge MIB Working Group
of the IETF.
Title : Definitions of Managed Objects for Source Routing
Bridges
Author(s) : E. Decker, K. McCloghrie, P. Langille, A. Rijsinghani
Filename : draft-ietf-bridge-sr-objects-03.txt
Pages : 24
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in TCP/IP based
internets. In particular it defines objects for managing source routing
bridges.
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-bridge-sr-objects-03.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-bridge-sr-objects-03.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-bridge-sr-objects-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-bridge-sr-objects-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 aa14275;
12 Aug 93 16:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21420;
12 Aug 93 16:02 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14255;
12 Aug 93 16:02 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14158;
12 Aug 93 15:59 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: namedroppers at nic.ddn.mil
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-dns-common-errors-01.txt
Date: Thu, 12 Aug 93 15:59:09 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308121559.aa14158 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 Domain Name System Working
Group of the IETF.
Title : Common DNS errors and suggested fixes.
Author(s) : A. Kumar, J. Postel, C. Neuman,
P. Danzig, S. Miller
Filename : draft-ietf-dns-common-errors-01.txt
Pages : 10
This memo describes common errors seen in DNS implementations and suggests
some fixes. Where applicable, violations of recommendations from RFC 1034
and RFC 1035 are mentioned. The memo also describes, where relevant, the
algorithms followed in BIND (versions 4.8.3 and 4.9 which the authors
referred to) to serve as an example.
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-dns-common-errors-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-dns-common-errors-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-dns-common-errors-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dns-common-errors-01.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 aa14319;
12 Aug 93 16:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21437;
12 Aug 93 16:02 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14259;
12 Aug 93 16:02 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14174;
12 Aug 93 15:59 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: namedroppers at nic.ddn.mil
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-dns-config-errors-00.txt
Date: Thu, 12 Aug 93 15:59:15 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308121559.aa14174 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 Domain Name System Working
Group of the IETF.
Title : Common DNS Data File Configuration Errors
Author(s) : P. Beertema
Filename : draft-ietf-dns-config-errors-00.txt
Pages : 8
This memo describes errors often found in DNS data files. It points out
common mistakes system administrators tend to make and why they often go
unnoticed for long periods of time.
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-dns-config-errors-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-dns-config-errors-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-dns-config-errors-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-dns-config-errors-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 aa14354;
12 Aug 93 16:02 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21463;
12 Aug 93 16:02 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14336;
12 Aug 93 16:02 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12865;
12 Aug 93 15:24 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-chang-iimc-proxy-03.txt, .ps
Date: Thu, 12 Aug 93 15:24:43 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308121524.aa12865 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : ISO/CCITT and Internet Management Coexistence (IIMC):
ISO/CCITT to Internet Management Proxy (IIMCPROXY)
Author(s) : A. Chang
Filename : draft-chang-iimc-proxy-03.txt, .ps
Pages : 67
This document is intended to facilitate the use of the ISO/CCITT Common
Management Information Protocol (CMIP) for integrated management of
networks via proxy management of TCP/IP networks that are managed using
Simple Network Management Protocol (SNMP). This document describes an
ISO/CCITT to Internet "proxy" which allows interworking between CMIP-based
managers and SNMP-based agents. The proxy emulates CMIS service requests
by mapping between corresponding ISO/CCITT GDMO and Internet MIB
definitions, and generating SNMP message(s) needed to emulate the service.
The proxy also emulates CMIS service responses and notifications by
converting incoming SNMP response and trap message(s) in a similar fashion.
Thus, the proxy appears as a CMIP-based agent to the manager, and as an
SNMP-based manager to the agent. The proxy depends on the availability of
corresponding MIB definitions translated as described in [IIMCIMIBTRANS].
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-chang-iimc-proxy-03.txt".
Or
"get draft-chang-iimc-proxy-03.ps".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-chang-iimc-proxy-03.txt".
Or
"SEND draft-chang-iimc-proxy-03.ps".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-chang-iimc-proxy-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-chang-iimc-proxy-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 aa15695;
12 Aug 93 16:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23711;
12 Aug 93 16:48 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15675;
12 Aug 93 16:48 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa15610;
12 Aug 93 16:47 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: atommib 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-atommib-atm-00.txt
Date: Thu, 12 Aug 93 16:47:10 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308121647.aa15610 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 ATM MIB Working Group of the
IETF.
Title : Definitions of Managed Objects for ATM Management
Author(s) : M. Ahmed, K. Tesink
Filename : draft-ietf-atommib-atm-00.txt
Pages : 65
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing ATM-based
interfaces, networks and services.
This memo specifies a MIB module in a manner that is both compliant to the
SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
Note: Upon progression of this specification as a Proposed Standard, an
SNMPv2 and an SNMPv1 version of this MIB module will be made available to
ease migration.
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-atommib-atm-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-atommib-atm-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-atommib-atm-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atommib-atm-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 aa15817;
12 Aug 93 16:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15809;
12 Aug 93 16:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23883;
12 Aug 93 16:52 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15797;
12 Aug 93 16:51 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15755;
12 Aug 93 16:50 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa23825;
12 Aug 93 16:50 EDT
Received: by ginger.lcs.mit.edu
id AA06274; Thu, 12 Aug 93 16:50:20 -0400
Date: Thu, 12 Aug 93 16:50:20 -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: <9308122050.AA06274 at ginger.lcs.mit.edu>
To: david at twg.com, ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
Cc: jnc at ginger.lcs.mit.edu
> This assumes, of course, that IPv4 can be patched into working for 5 more
> years, but it's not clear to me that CIDR, EID's, NAT, etc can't do it.
I just wanna plop out a reminder that there isn't much time left. My
internet service provider (for my home system) was recently assigned the
165.113 network. Last year the new networks were in the 140's. This is
edging up on 192 way quick!
Yes, we are using class B's quickly. That's why CIDR is coming. However,
recall that A's represent 1/2 of the address space, while B's are 1/4 and
C's are 1/8th. Since around half the A's are not allocated, we can create
*two more* spaces the size of the *entire* C space pretty easily, and since
the C space is not getting used very quickly at all...
Noel
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15866;
12 Aug 93 16:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23909;
12 Aug 93 16:53 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15849;
12 Aug 93 16:52 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12940;
12 Aug 93 15:25 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-labarre-iimc-party-03.txt, .ps
Date: Thu, 12 Aug 93 15:25:36 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308121525.aa12940 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : ISO/CCITT and Internet Management Coexistence (IIMC):
ISO/CCITT to Internet Management Security (IIMCSEC)
Author(s) : L. LaBarre
Filename : draft-labarre-iimc-party-03.txt, .ps
Pages : 59
This document is intended to facilitate the multi-protocol management
coexistence and interworking for networks that are managed using the
ISO/CCITT Common Management Information Protocol (CMIP) and networks that
are managed using the Internet Simple Network Management Protocol (SNMP).
This document defines the end-to-end security architecture, services, and
mechanisms for use with ISO/CCITT-Internet proxies. This document also
contains the ISO/CCITT GDMO definition and registration of the SNMP Parties
MIB, derived from the Internet SNMP Parties MIB [RFC1447] according to the
procedures defined in "Translation of Internet MIBs to ISO/CCITT GDMO MIBs"
[IIMCIMIBTRANS].
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-labarre-iimc-party-03.txt".
Or
"get draft-labarre-iimc-party-03.ps".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-labarre-iimc-party-03.txt".
Or
"SEND draft-labarre-iimc-party-03.ps".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-labarre-iimc-party-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-labarre-iimc-party-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16583;
12 Aug 93 17:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16576;
12 Aug 93 17:32 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25163;
12 Aug 93 17:32 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16564;
12 Aug 93 17:32 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16524;
12 Aug 93 17:30 EDT
Received: from GINGER.LCS.MIT.EDU by CNRI.Reston.VA.US id aa25121;
12 Aug 93 17:30 EDT
Received: by ginger.lcs.mit.edu
id AA06421; Thu, 12 Aug 93 17:31:10 -0400
Date: Thu, 12 Aug 93 17:31:10 -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: <9308122131.AA06421 at ginger.lcs.mit.edu>
To: ALH at eagle.es.net, ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
Cc: jnc at ginger.lcs.mit.edu
It is always easy to look back and point out what was wrong with a
decision without thinking about the set of problems that would have
resulted from a different choice.
True, but a number of people were arguing at the time that a fixed length
address was a bad idea, so it's not just hindsight. Would the extra code to
handle variable addresses have been small enough not to harm the chances of
the project, and would it have saved us a *lot* of grief today?
"Those who forget history are doomed to repeat it", and all that.
The long term costs of unraveling the hacks that will be used to extend
the life of the existing solution will likely be even higher.
Well, I don't see CIDR as a nasty hack. There's also an argument to be made
that we are going to see NAT boxes, or something like them, *anyway*, to
handle hosts which i) can't be converted, and ii) can't be ditched. Now, maybe
that argument is wrong, but if not, there's no way to avoid that cost, so
maybe we should get a real bang for our buck?
In fact what we should probably be spending our time at is not so much the
details of solution X vs. Y, as on a process of moving to the next version
every N years. This is a given in hardware and operating systems, but so
far taboo for the network. Granted the period needs to be longer, but the
concept should be established.
The cycles may be there in hardware, but they are pretty slow in software.
How long has Fortran been around? How long are we going to have to suffer
through Unix? I wouldn't say that changes are "taboo" for the network; as you
mentioned, we did go from NCP to TCP.
Communication systems are an order of magnitude more painful to change, since
changes cannot be totally local. (You spend more brainpower figuring out an
good interoperabilty scheme, which has to work over a longer and longer time
as the system gets bigger, than you do doing the new design. :-) That's why I
want to i) minimize the number of them, and ii) get as much as we can out of
them when they do happen.
> Oh well, interesting academic speculation, but not anything any of us
> have any control over!
It needs to be more and someone has to establish control. Not so much to
dictate as to guide through the rocks ahead. People have to be willing to
'let go' and move on.
Sounds good to me. I assume I'll be in charge? Oh, you don't think that's
a good idea? You want to be in charge? Gee, X doesn't think that's a good
idea. Etc, etc. As you said, "damn pragmatics"! :-)
Noel
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17510;
12 Aug 93 18:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ab17503;
12 Aug 93 18:45 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27193;
12 Aug 93 18:45 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17491;
12 Aug 93 18:45 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17459;
12 Aug 93 18:44 EDT
Received: from eagle.nersc.gov by CNRI.Reston.VA.US id aa27148;
12 Aug 93 18:43 EDT
Date: Thu, 12 Aug 1993 15:44:37 -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: <930812154437.6a at EAGLE.ES.NET>
Subject: Re: Now is the time for radical thinking...
To: jnc at ginger.lcs.mit.edu, ietf at CNRI.Reston.VA.US
X-Vmsmail-To: SMTP%"jnc at ginger.lcs.mit.edu"
Noel,
>>"Those who forget history are doomed to repeat it", and all that.
I was not proposing to forget, just avoid second guessing.
>
> In fact what we should probably be spending our time at is not so much the
> details of solution X vs. Y, as on a process of moving to the next version
> every N years. This is a given in hardware and operating systems, but so
> far taboo for the network. Granted the period needs to be longer, but the
> concept should be established.
>
>The cycles may be there in hardware, but they are pretty slow in software.
>How long has Fortran been around? How long are we going to have to suffer
>through Unix? I wouldn't say that changes are "taboo" for the network; as you
>mentioned, we did go from NCP to TCP.
How close is the Fortran or Unix of 1993 to that of 1983? There are small
and constant changes that go almost unnoticed. Only the name remains the same.
>Communication systems are an order of magnitude more painful to change, since
>changes cannot be totally local. (You spend more brainpower figuring out an
>good interoperabilty scheme, which has to work over a longer and longer time
>as the system gets bigger, than you do doing the new design. :-) That's why I
>want to i) minimize the number of them, and ii) get as much as we can out of
>them when they do happen.
One could make the same arguements about the operating system of a computer,
yet the vendors have established a way of feeding the changes in small doses
that are less painful. Part of the reason changes in the communications system
are painful is that they are put off until it becomes a major effort. After I
thought about it I realized there have been changes in the use of IP if not the
protocol itself. This leads to a state of 'compliant' but not 'interoperable'.
This was the point of the HOST and ROUTER requirements RFC's, but how many
systems are fully compliant with those? How often will they be updated?
What would happen if the IP version number were defined to change every 5 years
with minor updates every 6 months? People could start specifing 'IPvN.M or later'
and expect to interoperate with other systems of that vintage. What it takes
is a shift in mindset about how to use these 'well defined interfaces between
protocol layers'. We need to take much smaller, more well defined steps if we
want to move without disruption to the system.
We would also have to establish the expectation that compatibility would only
be supported one major version back. This would give a system a useful life
between 5 and 10 years which will likely exceed the life of its maintenance.
A big part of the job is setting expectations. People expect the data network
to be as stable as the voice network. Someone sold the wrong idea here because
the voice network has a lengthy headstart and has worked through most of these
startup kinks. If we could sell the idea that a MINOR change is required every
6 months we could start down a road that would be much smoother for the end user.
Tony
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17885;
12 Aug 93 19:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17878;
12 Aug 93 19:23 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa28153;
12 Aug 93 19:23 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17865;
12 Aug 93 19:23 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17839;
12 Aug 93 19:21 EDT
Received: from watson.ibm.com by CNRI.Reston.VA.US id aa28136;
12 Aug 93 19:21 EDT
Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9799;
Thu, 12 Aug 93 19:22:41 EDT
Date: Thu, 12 Aug 93 19:11:19 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: jnc at ginger.lcs.mit.edu, ietf at CNRI.Reston.VA.US
Subject: Now is the time for radical thinking...
Message-ID: <9308121921.aa28136 at CNRI.Reston.VA.US>
Ref: Your note of Thu, 12 Aug 93 16:50:20 -0400
>Since around half of the A's are not allocated, we can create
>*two more* spaces the size of the *entire* C space pretty easily...
Noel,
Just to add to what you said, let me point out that the *allocated*
half of the A's is used in a rather wasteful fashion. So, if we'll
reclaim these A's by giving folks who are using A's now, but don't
have enough hosts to justify use of Class A, few B's (or even C's)
we can create yet another space (or two) comparable in size to the
*entire* C space.
Yakov.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00895;
13 Aug 93 5:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00887;
13 Aug 93 5:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03631;
13 Aug 93 5:01 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00874;
13 Aug 93 5:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00830;
13 Aug 93 4:50 EDT
Received: from mitsou.inria.fr by CNRI.Reston.VA.US id aa03408;
13 Aug 93 4:50 EDT
Received: by mitsou.inria.fr
(5.65c/IDA-1.2.8) id AA04756; Fri, 13 Aug 1993 10:52:35 +0200
Message-Id: <199308130852.AA04756 at mitsou.inria.fr>
To: yakov at watson.ibm.com
Cc: jnc at ginger.lcs.mit.edu, ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
In-Reply-To: Your message of "Thu, 12 Aug 93 19:11:19 EDT."
<9308121921.aa28136 at CNRI.Reston.VA.US>
Date: Fri, 13 Aug 93 10:52:34 +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>
=> Ref: Your note of Thu, 12 Aug 93 16:50:20 -0400
=>
=> >Since around half of the A's are not allocated, we can create
=> >*two more* spaces the size of the *entire* C space pretty easily...
=> Noel,
=> Just to add to what you said, let me point out that the *allocated*
=> half of the A's is used in a rather wasteful fashion. So, if we'll
=> reclaim these A's by giving folks who are using A's now, but don't
=> have enough hosts to justify use of Class A, few B's (or even C's)
=> we can create yet another space (or two) comparable in size to the
=> *entire* C space.
=> Yakov.
=>
While that may well be true, let me remind you that fighting exponential
growth is a tricky business. Remember the old "water lily" riddle? Suppose
that a water lily doubles size every night. Saturday morning, after two weeks
of sustained growth, it occupies one half of the pool. When will he occupy all
the pool?
The Internet is just like that water lily. Suppose we come to the point where
all of C is allocated, and the Internet is still doubling size every year (as
we hope it will). Just how long does it take to use a space equivalent to the
current space of class C? Or to three times that space?
Answer: one year for doubling once; two years for doubling twice...
So I would say that this idea of using the class A space could give us some
breathing space if we have not found anything better in the interval. But this
will have a cost (all those oldies that still believe in classes). And it
cannot be the "final answer".
Christian Huitema
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01841;
13 Aug 93 7:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01834;
13 Aug 93 7:57 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06860;
13 Aug 93 7:57 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01819;
13 Aug 93 7:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01782;
13 Aug 93 7:55 EDT
Received: from darpa.mil by CNRI.Reston.VA.US id aa06845; 13 Aug 93 7:55 EDT
Received: from LOCALHOST by vax.darpa.mil (5.65c/5.61+local-5)
id <AA01364>; Fri, 13 Aug 1993 07:54:53 -0400
Message-Id: <199308131154.AA01364 at vax.darpa.mil>
To: Mark Crispin <MRC at cac.washington.edu>
Cc: "Donald E. Eastlake 3rd (Tech. Coord.,\
PW for UNIX products) LKG/BB3,\
508-486-6577" <dee at ranger.enet.dec.com>,
ietf at CNRI.Reston.VA.US
Reply-To: pvm at arpa.mil
Subject: Re: Now is the time for radical thinking...
In-Reply-To: Your message of Wed, 11 Aug 93 15:53:46 -0700.
<MailManager.745109626.6332.mrc at Tomobiki-Cho.CAC.Washington.EDU>
Date: Fri, 13 Aug 93 07:54:52 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>
The strings in DNS labels, i.e. the part between two dots, is limited
to 63 bytes.
The overall length of a DNS name is limited to ~255 characters, the
"~" is because I don't know how you want to count the dots, which have
to be there, and count against the technical limit. By the way, even
this technical limit is just a number we said was large enough to
certify an implementation as valid, not inherent in the protocol.
Valid DNS names:
1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.0.net
A-very-long-string-without-any-dots-inside.edu
8236223434624937487263486234623649364896492.com
paul
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06162;
13 Aug 93 11:37 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06157;
13 Aug 93 11:37 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14224;
13 Aug 93 11:37 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06144;
13 Aug 93 11:37 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa06140;
13 Aug 93 11:37 EDT
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: fddi-mib at cs.utk.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: FDDI Management Information Base to Proposed
Standard
Date: Fri, 13 Aug 93 11:37:05 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308131137.aa06140 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Draft "FDDI Management Information
Base" <draft-ietf-fddimib-objects-02.txt> as a Proposed Standard. This
document is the product of the FDDI MIB Working Group. The IESG contact
person is Marshall Rose.
(RFC Editor -- please note the "Notes to the RFC Editor" section at the
bottom of this message.)
Technical Summary
This MIB module defines managed objects which correspond to ANSI SMT
version 7.3. RFC 1285, a Proposed Standard, defines managed objects
which correspond to ANSI SMT version 6.2. These two MIB modules (and
two SMT versions) are not compatible, and different subtrees are used
for the objects.
Working Group Summary
There were no significant areas of disagreement in the working group.
Protocol Quality
The NM AD and the NM Directorate have reviewed the specification.
No implementations are known to exist, however this draft is derived
from RFC 1285, which has received extensive implementation experience.
Notes to the RFC Editor
1. Please change the module name from RFCxxxx-MIB to
FDDI-SMT73-MIB
2. Please change the "fddi" OID to { transmission 15 }
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07519;
13 Aug 93 12:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07512;
13 Aug 93 12:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16328;
13 Aug 93 12:24 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07500;
13 Aug 93 12:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa07434;
13 Aug 93 12:22 EDT
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa16286;
13 Aug 93 12:22 EDT
Received: from goshawk.lanl.gov by mailhost.lanl.gov (5.65/1.14)
id AA13912; Fri, 13 Aug 93 10:22:56 -0600
Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17)
id AA24478; Fri, 13 Aug 93 10:23:07 MDT
Message-Id: <9308131623.AA24478 at goshawk.lanl.gov>
To: Christian.Huitema at sophia.inria.fr
Subject: Re: Now is the time for radical thinking...
Cc: ietf at CNRI.Reston.VA.US
Date: Fri, 13 Aug 93 10:23:07 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
Christian,
>>> While that may well be true, let me remind you that fighting exponential
>>> growth is a tricky business.
This is certainly true. However close the Internet looks like a water lily
it is still not clear that we are seeing exponential growth. Many
have speculated that we will see logistic growth. It is not worth
arguing about this, but there certainly a logistic limit today approximated
by the total number of potential IP hosts.
It would be interesting to see if anyone has a curve tracking the total
number of silicon entities out there. Even if the curve is logistic it
may actually predict higher bounds than an exponential model for the next
10 years. Perhaps someone can dredge this historical data out of
their marketing organization?
>>>
>>> So I would say that this idea of using the class A space could give us some
>>> breathing space if we have not found anything better in the interval. But this
>>> will have a cost (all those oldies that still believe in classes). And it
>>> cannot be the "final answer".
It will be critical to keep IPv4 going irrespective of the IPng activities.
The problem of classful systems will be with us with IPng as well. If
a system has a hard time becoming a classless IPv4 system then it is
probably fair to speculate it will have a hard time becoming an IPng
system.
The Internet community needs to commit to making IPv4 work as long
as possible and there are several steps that we could take to help
make this possible:
aggressively develop and deploy CIDR technology (being done)
allocate address space by need (a management issue which
many Internet Registries are already following)
planning for reallocating those sites who because of older
technology choices have very low occupancy of IPv4
address space.
This same planning and deployment effort will also
reduce the size of global IP routing systems.
develop and deploy technology for IPv4 to help users and sites
reclaim IPv4 address space and move their sites into
the global CIDR hierarchy and then enable them to
move within the CIDR hierarchy as they choose to do
so.
As switch based technology becomes more prevelant it
should be easier to get higher occupancy rates at the
periphery of the Internet by releasing us from the
stanglehold of the logical IP subnet model (physical
subnet == IP subnet).
We know how to do most of this, the question many ask is if we have
the will to do so. The answer should be a resounding YES! (this
writer's opinion)
Basic CIDR seems to have an okay start, but the success of the overall
enterprise depends on us investigating further steps, including reclamation,
renumbering, NAT, etc. This does not preclude IPng activities which
are also tremendously important. The Internet community is now
sufficiently large and vibrant to take on multiple threads of attack to
future problems. Many of the CIDR followon activities could be in
products within the next 2 years since they will respond to customers'
needs for a global IPv4 Internet and therefore will be of interest to
IPv4 product producers.
with regards,
peter
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10211;
13 Aug 93 14:02 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10200;
13 Aug 93 14:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20403;
13 Aug 93 14:01 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10178;
13 Aug 93 14:01 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09868;
13 Aug 93 13:59 EDT
Received: from tomobiki-cho.cac.washington.edu by CNRI.Reston.VA.US id aa20195;
13 Aug 93 13:59 EDT
Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU
(NX5.67d/UW-NDC Revision: 2.27.MRC ) id AA08400; Fri, 13 Aug 93 10:58:43 -0700
Received: by Ikkoku-Kan.Panda.COM
(NX5.67c/UW-NDC/Panda Revision: 2.27.MRC ) id AA16949; Fri, 13 Aug 93 10:58:36 -0700
Date: Fri, 13 Aug 1993 10:53:34 -0700 (PDT)
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mark Crispin <mrc at panda.com>
Subject: Re: Now is the time for radical thinking...
To: Paul Mockapetris <pvm at arpa.mil>
Cc: "Donald E. Eastlake 3rd (Tech. Coord., PW for UNIX products) LKG/BB3, 508-486-6577" <dee at ranger.enet.dec.com>,
ietf at CNRI.Reston.VA.US
In-Reply-To: <199308131154.AA01364 at vax.darpa.mil>
Message-Id: <Pine.3.85.9308131033.A16926-0100000 at Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Yes, Paul, but SMTP (RFC-821) still creates an effective maximum name
limit of 64 characters. Supposedly it is the ``minimum'' maximum name
limit but in effect it limits the usable name space to 64 characters.
Any name longer than that will break with certain applications, and the
vendor can claim compliance with the standards.
Pretty bad, but it used to be that sendmail had a limit of 28 or so
characters!
I'm not sure if the Brave New World of X.400 will change this, but at
least for now we seem to be in no great danger of getting host names of
more than 64 characters.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12453;
13 Aug 93 14:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12446;
13 Aug 93 14:58 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23178;
13 Aug 93 14:58 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12424;
13 Aug 93 14:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12314;
13 Aug 93 14:56 EDT
Received: from deins.Informatik.Uni-Dortmund.DE by CNRI.Reston.VA.US id aa23100;
13 Aug 93 14:56 EDT
Received: from localhost.Informatik.Uni-Dortmund.DE
by deins.informatik.uni-dortmund.de
id AA24852; Fri, 13 Aug 93 20:49:49 +0200
To: Mark Crispin <mrc at panda.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
In-Reply-To: Your message of "Fri, 13 Aug 1993 10:53:34 PDT."
<Pine.3.85.9308131033.A16926-0100000 at Ikkoku-Kan.Panda.COM>
Date: Fri, 13 Aug 1993 20:49:47 +0200
Message-Id: <24851.745267787 at deins.Informatik.Uni-Dortmund.DE>
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ruediger Volk <rv at deins.informatik.uni-dortmund.de>
> Yes, Paul, but SMTP (RFC-821) still creates an effective maximum name
> limit of 64 characters. Supposedly it is the ``minimum'' maximum name
> limit but in effect it limits the usable name space to 64 characters.
> Any name longer than that will break with certain applications, and the
> vendor can claim compliance with the standards.
>
> Pretty bad, but it used to be that sendmail had a limit of 28 or so
> characters!
since in this part of the world names tend to be longer, we have some
experience with this. It seems that sendmail (and other SMTP implementations)
now usually is distributed in versions that can handle much more than 28 chars;
in fact the problems with the buffer size for the actually used addresses
disappeared earlier than problems with the buffer that's used for holding
the incoming HELO argument.
Regarding buffer size for domain names in other applications, we recently
have seen a limit of 32 bytes show up with a new HP/UX release (very nasty
effects on name servers).
But since you asked about domain length in the context of IPng addressing,
a SMTP limit seems to just eliminate RFC821 from being an IPng proposal :-)
If proposing domain names seriously for IPng addresses, I don't see any
problem result from specifying a larger MUST be supported length.
> I'm not sure if the Brave New World of X.400 will change this, but at
> least for now we seem to be in no great danger of getting host names of
> more than 64 characters.
well, on the last scan of the German DNS the longest host name was:
anatue-indigo.anatom.theoretische-medizin.Uni-Xxxxxxxxx.DE
12345678901234567890123456789012345678901234567890123456789012345678901234567890
1 2 3 4 5 6 7 8
(ruler provided to ease the counting... name slightly change to protect the
[un?]guilty:-)
not too far away from hitting 64 chars (and some people's ideas about
X.400 certainly provide the background for creating this kind of names;
and those people certainly would expand to "...Uni-XXXXXXXXX.D400.DE"
for mail addressing! which results in a length of 63 chars - pretty close)
---
Ruediger Volk
Universitaet Dortmund, Informatik IRB DE-NIC
D-44221 Dortmund, Germany
E-Mail: rv at Informatik.Uni-Dortmund.DE
Phone: +49 231 755 4760 Fax: +49 231 755 2386
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12923;
13 Aug 93 15:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12914;
13 Aug 93 15:15 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23747;
13 Aug 93 15:15 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12889;
13 Aug 93 15:15 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12798;
13 Aug 93 15:13 EDT
Received: from tigger.jvnc.net by CNRI.Reston.VA.US id aa23654;
13 Aug 93 15:13 EDT
Received: by tigger.jvnc.net id AA05215
(5.65c/IDA-1.4.4 for ietf at CNRI.Reston.VA.US); Fri, 13 Aug 1993 15:13:46 -0400
Date: Fri, 13 Aug 1993 15:13:46 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Ms. Sydney Feit" <feit at tigger.jvnc.net>
Message-Id: <199308131913.AA05215 at tigger.jvnc.net>
To: craig at aland.bbn.com, ietf at CNRI.Reston.VA.US
Subject: RPC and other technologies
Cc: c at tigger.jvnc.net
Your point about moving the process is well-taken.
For example, Dave Gelernter's LINDA technology provides
a startlingly simple programming interface for distributed
OR parallel computing. But what is best is that the communications
AND where something is done BOTH are decoupled from the programming
interface.
Several cooperating systems make up a LINDA environment. The run-time
environment looks at where the data is and who has MIPS to spare
and keeps balancing to optimize power and decrease usage of
bandwidth.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14542;
13 Aug 93 16:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14535;
13 Aug 93 16:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26067;
13 Aug 93 16:21 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14522;
13 Aug 93 16:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14484;
13 Aug 93 16:19 EDT
Received: from inet-gw-2.pa.dec.com by CNRI.Reston.VA.US id aa25891;
13 Aug 93 16:19 EDT
Received: by inet-gw-2.pa.dec.com; id AA13158; Fri, 13 Aug 93 13:19:51 -0700
Received: by us1rmc.bb.dec.com; id AA16963; Fri, 13 Aug 93 16:18:23 -0400
Message-Id: <9308132018.AA16963 at us1rmc.bb.dec.com>
Received: from ranger.enet; by us1rmc.enet; Fri, 13 Aug 93 16:18:29 EDT
Date: Fri, 13 Aug 93 16:18:29 EDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Donald E. Eastlake 3rd (Tech. Coord., PW for UNIX products) LKG/BB3, 508-486-6577" <dee at ranger.enet.dec.com>
To: ietf at CNRI.Reston.VA.US
Cc: dee at ranger.enet.dec.com
Apparently-To: ietf at cnri.reston.va.us
Subject: DNS entry sizes (was Now is the time for radical thinking...)
Below is the histogram of character lengths and deptsh (number of internal
dots) from the latest domain name survey. The longest is 58 character, the
deepest is 9 levels. (Many of the deep entries look like DNS
misconfiguration). I have also included the "interesting" entries: those
deeper than 5 levels or shorter than 7 characters or longer than 43 characters.
It is interesting that there are no domain names shorter than 6 characters. It
would not be too hard to have an entry of the form x.xx which would be only 4
characters.
The previous domain name survey had a number of entries that were >64. All the
entries over 64 characters in length were exactly 76 characters long and of the
form:
n1-12-234-telecommunications-and-networking-group-development.ocs.drexel.edu
Donald
--------------
From: US1RMC::"mrc at panda.com" "Mark Crispin" 13-AUG-1993 14:14
To: Paul Mockapetris <pvm at arpa.mil>
CC: "Donald E. Eastlake 3rd (Tech. Coord., PW for UNIX products) LKG/BB3,
508-486-6577" <ranger::dee>, ietf at CNRI.Reston.VA.US
Subj: Re: Now is the time for radical thinking...
Yes, Paul, but SMTP (RFC-821) still creates an effective maximum name
limit of 64 characters. Supposedly it is the ``minimum'' maximum name
limit but in effect it limits the usable name space to 64 characters.
Any name longer than that will break with certain applications, and the
vendor can claim compliance with the standards.
Pretty bad, but it used to be that sendmail had a limit of 28 or so
characters!
I'm not sure if the Brave New World of X.400 will change this, but at
least for now we seem to be in no great danger of getting host names of
more than 64 characters.
--------------
csize 6 count 26
csize 7 count 80
csize 8 count 68
csize 9 count 174
csize 10 count 502
csize 11 count 2075
csize 12 count 4389
csize 13 count 8644
csize 14 count 12206
csize 15 count 16141
csize 16 count 19045
csize 17 count 21829
csize 18 count 27522
csize 19 count 28275
csize 20 count 26496
csize 21 count 23074
csize 22 count 23411
csize 23 count 23995
csize 24 count 14768
csize 25 count 12838
csize 26 count 11550
csize 27 count 6498
csize 28 count 4494
csize 29 count 3761
csize 30 count 2443
csize 31 count 2553
csize 32 count 1605
csize 33 count 1458
csize 34 count 749
csize 35 count 439
csize 36 count 348
csize 37 count 268
csize 38 count 179
csize 39 count 143
csize 40 count 108
csize 41 count 73
csize 42 count 32
csize 43 count 26
csize 44 count 17
csize 45 count 7
csize 46 count 7
csize 47 count 7
csize 48 count 8
csize 49 count 8
csize 50 count 0
csize 51 count 9
csize 52 count 4
csize 53 count 3
csize 54 count 3
csize 55 count 0
csize 56 count 0
csize 57 count 0
csize 58 count 1
psize 1 count 456
psize 2 count 102103
psize 3 count 161120
psize 4 count 36786
psize 5 count 1858
psize 6 count 30
psize 7 count 2
psize 8 count 3
psize 9 count 1
First column is depth, next is length, order is alphabetic:
6 29 130.133.7.99.met.fu-berlin.de
6 28 192.35.196.19.nctsw.navy.mil
1 6 3k.com
1 6 3m.com
4 49 9780x1.betriebssysteme.informatik.th-darmstadt.de
4 49 9780x2.betriebssysteme.informatik.th-darmstadt.de
6 34 a1.transalta.ab.ca.transalta.ab.ca
4 51 a2pc1.neurologie.klinische-medizin.uni-tuebingen.de
4 51 a2pc2.neurologie.klinische-medizin.uni-tuebingen.de
4 51 a2pc3.neurologie.klinische-medizin.uni-tuebingen.de
1 6 aau.dk
3 45 abakus.versorgungstechnik.fh-wolfenbuettel.de
1 6 abc.hu
6 29 abyss.uksr.hp.com.uksr.hp.com
6 29 acfp1.acfp.af.mil.acfp.af.mil
3 44 achat.gruenlandforschung.fal-braunschweig.de
6 30 ada1.elan.af.mil.robins.af.mil
7 31 ada1.elan.af.mil.wr.aflc.af.mil
4 44 adler.eye.klinische-medizin.uni-tuebingen.de
6 48 adonis.clnsnet.ariadne-t.gr.clnsnet.ariadne-t.gr
4 53 aegypt1.aeginst.kulturwissenschaften.uni-tuebingen.de
4 53 aegypt2.aeginst.kulturwissenschaften.uni-tuebingen.de
4 53 aegypt3.aeginst.kulturwissenschaften.uni-tuebingen.de
6 40 afaa-net.afaa-net.af.mil.afaa-net.af.mil
1 6 ag.gov
6 31 agistri.ccf.auth.gr.ccf.auth.gr
1 6 aka.fi
3 44 akazie.strukturforschung.fal-braunschweig.de
3 48 allegro.dokumentationsstelle.fal-braunschweig.de
5 46 allenesmac.apple-consortium.cs.adelaide.edu.au
4 47 allent.pi.sozialwissenschaften.uni-tuebingen.de
4 52 altor1.aeginst.kulturwissenschaften.uni-tuebingen.de
4 52 altor2.aeginst.kulturwissenschaften.uni-tuebingen.de
3 46 analyse.versorgungstechnik.fh-wolfenbuettel.de
6 33 anarchy.isse.gmu.edu.isse.gmu.edu
4 58 anatue-indigo.anatom.theoretische-medizin.uni-tuebingen.de
4 51 anna.medpsych.theoretische-medizin.uni-tuebingen.de
6 32 ap1000.juten.mtl.t.u-tokyo.ac.jp
4 45 apcis-diag-192-207-18-1.delmar.edu.delmar.edu
4 45 apcis-diag-192-207-18-2.delmar.edu.delmar.edu
4 49 apcis-diag-192-207-19-1.templejc.edu.templejc.edu
4 49 apcis-diag-192-207-19-2.templejc.edu.templejc.edu
4 49 apcis-diag-192-58-118-1.tarleton.edu.tarleton.edu
4 49 apcis-diag-192-58-118-2.tarleton.edu.tarleton.edu
3 48 aphrael.manchester-metropolitan-university.ac.uk
3 49 applied-math-terminal-server.amath.washington.edu
1 6 apu.fi
3 45 archer.pflanzenernaehrung.fal-braunschweig.de
8 54 arnold.phchem.uoa.ariadne-t.gr.phchem.uoa.ariadne-t.gr
3 44 arps-049m-hp-thin-eth-rep.acs.ohio-state.edu
3 44 asante-10bt-se426m-226net.acs.ohio-state.edu
4 49 asterix.microelectronic.e-technik.th-darmstadt.de
1 6 aud.dk
6 38 audfdi.aud.alcatel.com.aud.alcatel.com
4 46 aug-lrz-bridge.regent.e-technik.tu-muenchen.de
3 44 aurikel.zentralbuecherei.fal-braunschweig.de
4 51 automatix.microelectronic.e-technik.th-darmstadt.de
1 6 aw.com
4 48 azachay.pi.sozialwissenschaften.uni-tuebingen.de
4 51 b8pc1.neurologie.klinische-medizin.uni-tuebingen.de
4 51 b8pc2.neurologie.klinische-medizin.uni-tuebingen.de
4 51 b8pc3.neurologie.klinische-medizin.uni-tuebingen.de
4 46 banhart.eye.klinische-medizin.uni-tuebingen.de
4 45 baro.pi.sozialwissenschaften.uni-tuebingen.de
3 44 barre.betriebswirtschaft.fal-braunschweig.de
6 40 base.base.bellcore.com.luna.bellcore.com
1 6 bc.net
3 44 belford-uiuc-dcs-na-graphics-net.cs.uiuc.edu
9 37 bernard.msb.ag.gov.bc.ca.ag.gov.bc.ca
3 48 bernstein.gruenlandforschung.fal-braunschweig.de
4 52 berta.medpsych.theoretische-medizin.uni-tuebingen.de
3 45 beryll.gruenlandforschung.fal-braunschweig.de
4 47 biblio.pi.sozialwissenschaften.uni-tuebingen.de
4 51 bilbo.neurologie.klinische-medizin.uni-tuebingen.de
1 6 bke.hu
1 6 blh.no
3 44 blitz.versorgungstechnik.fh-wolfenbuettel.de
4 45 bloomfield.sns.neuphilologie.uni-tuebingen.de
6 40 bluejay.cas.pitt.edubluejay.cas.pitt.edu
1 6 bnr.ca
6 29 boas3.bo.astro.it.pd.astro.it
6 23 bom.gw.au.ho.bom.gov.au
3 46 brenner.versorgungstechnik.fh-wolfenbuettel.de
6 37 bridge1-deh100.hsc.usc.ed.hsc.usc.edu
6 37 bridge1-edm100.hsc.usc.ed.hsc.usc.edu
6 37 bridge1-hso100.hsc.usc.ed.hsc.usc.edu
5 47 bronwynsmac.apple-consortium.cs.adelaide.edu.au
1 6 bu.edu
3 44 butterfly.verfahrenstechnik.uni-stuttgart.de
1 6 c3.com
1 6 c4.com
8 46 c9f102.nhn.navair.navy.mil.nhn.navair.navy.mil
1 6 cae.ca
3 48 callisto.tierzucht-mariensee.fal-braunschweig.de
3 44 calphurnia-uiuc-dcs-tapestry-net.cs.uiuc.edu
3 47 cappuccino-uiuc-dcs-na-graphics-net.cs.uiuc.edu
2 44 career-planing-training-portable.uoregon.edu
1 6 cat.de
3 46 caxton-house-router.southbank-university.ac.uk
1 6 cbs.dk
3 44 cbvt-ibvt.verfahrenstechnik.uni-stuttgart.de
1 6 cc.com
6 30 cc5.kuleuven.ac.be.fundp.ac.be
1 6 cci.de
1 6 cg.com
6 37 charlottekler.hsc.usc.edu.hsc.usc.edu
6 33 charon.hsc.wvu.edu.commed.wvu.edu
6 32 charon.hsc.wvu.edu.ortho.wvu.edu
3 48 chemiedahlem-geowisslankwitz.chemie.fu-berlin.de
6 39 chemtechmac10.chemtech.kth.se.in.kth.se
6 39 chemtechmac11.chemtech.kth.se.in.kth.se
6 39 chemtechmac12.chemtech.kth.se.in.kth.se
6 39 chemtechmac13.chemtech.kth.se.in.kth.se
6 39 chemtechmac14.chemtech.kth.se.in.kth.se
6 39 chemtechmac15.chemtech.kth.se.in.kth.se
3 44 christine.verfahrenstechnik.uni-stuttgart.de
3 44 cigff.gruenlandforschung.fal-braunschweig.de
3 44 cisco-serial-cornell.cicnet.cornell-iowa.edu
3 54 cisco-tzv-msee.tierzucht-mariensee.fal-braunschweig.de
3 47 ciziud.dokumentationsstelle.fal-braunschweig.de
4 52 clara.medpsych.theoretische-medizin.uni-tuebingen.de
8 37 clarinet.asms.bt.co.uk.axion.bt.co.uk
3 47 classic.tierzucht-mariensee.fal-braunschweig.de
4 54 clio1.wiwisem.wirtschaftswissenschaft.uni-tuebingen.de
1 6 cmc.ca
1 6 cmr.ca
1 6 cnr.it
1 6 co.edu
4 47 cognet.pi.sozialwissenschaften.uni-tuebingen.de
4 44 coletrane.ats.neuphilologie.uni-tuebingen.de
7 43 collins.esi.yamanashi.ac.jp.yamanashi.ac.jp
5 48 convert_to_80-gw.cad.commodore.com.commodore.com
6 30 copydisk4.1.3.eso.mc.xerox.com
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17283;
13 Aug 93 19:24 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03211;
13 Aug 93 19:24 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17260;
13 Aug 93 19:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17211;
13 Aug 93 19:22 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa03189;
13 Aug 93 19:22 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA11687>; Fri, 13 Aug 1993 16:06:42 -0700
Message-Id: <199308132306.AA11687 at zephyr.isi.edu>
To: Internet-Research-Group: ;
Cc: IETF-Announce: ;
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Subject: Internet Monthly Report Availability via FTP and EMAIL
Reply-To: cooper at isi.edu
Date: Fri, 13 Aug 93 16:06:41 PDT
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Ann Westine Cooper <cooper at isi.edu>
--NextPart
Internet Monthly Report Availability via FTP and EMAIL
The Internet Monthly Report (IMR) is normally distributed via EMail to
the IMR list and the IETF list. For most readers this is the most
convenient way to receive the report. However, there are some mail
systems or mail gateways that do not accommodate large messages (some
issues of the IMR are more than 100,000 characters). Readers that do
not receive the IMR via the normal distribution may obtain copies via
FTP or EMail retrieval.
IMR Retrieval using RFC-INFO Service
------------------------------------
The EMail retrieval system "RFC-Info" will send a large report in
segments in separate EMail messages not exceeding 50,000 characters
each.
Details on obtaining the current IMR, or back issues, via FTP or EMAIL
may be obtained by sending an EMAIL message to "rfc-info at ISI.EDU" with
the message body "help: ways_to_get_imrs". For example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
IMR Retrieval using FTP
-----------------------
IMRs are available via anonymous FTP from VENERA.ISI.EDU, with the
pathname: in-notes/imr/imryymm.txt (where "yymm" refers to the date of
the IMR. For example IMR9207.TXT is the report for July 1992). Login
with FTP username "anonymous" and password "ftp".
Requests to be added or deleted from the Internet Monthly Report list
should be sent to "imr-request at isi.edu".
Requests to be added or deleted from the IETF list should be sent to
"ietf-request at nri.reston.va.us".
. . .
IMR retrieval using MIME
------------------------
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retreive the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="rfc-info at isi.edu"
Content-Type: text/plain
Retrieve: imr
Doc-ID: imr9307
--OtherAccess
Content-Type: Message/External-body;
name="imr9307.txt";
site="venera.isi.edu";
access-type="anon-ftp";
directory="in-notes/imr"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17306;
13 Aug 93 19:25 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17299;
13 Aug 93 19:25 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03212;
13 Aug 93 19:24 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17258;
13 Aug 93 19:24 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17219;
13 Aug 93 19:22 EDT
Received: from zephyr.isi.edu by CNRI.Reston.VA.US id aa03191;
13 Aug 93 19:22 EDT
Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-13)
id <AA11701>; Fri, 13 Aug 1993 16:06:51 -0700
Message-Id: <199308132306.AA11701 at zephyr.isi.edu>
To: Internet-Research-Group: ;
Cc: ietf at CNRI.Reston.VA.US
Subject: Internet Monthly Report - July 1993
Reply-To: cooper at isi.edu
Date: Fri, 13 Aug 93 16:06:50 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Ann Westine Cooper <cooper at isi.edu>
July 1993
INTERNET MONTHLY REPORTS
------------------------
The purpose of these reports is to communicate to the Internet Research
Group the accomplishments, milestones reached, or problems discovered by
the participating organizations.
This report is for Internet information purposes only, and is not
to be quoted in other publications without permission from the
submitter.
Each organization is expected to submit a 1/2 page report on the first
business day of the month describing the previous month's activities.
These reports should be submitted via network mail to:
Ann Westine Cooper (Cooper at ISI.EDU)
NSF Regional reports - To obtain the procedure describing how to
submit information for the Internet Monthly Report, send an email
message to mailserv at is.internic.net and put "send imr-procedure" in
the body of the message (add only that one line; do not put a
signature).
Requests to be added or deleted from the Internet Monthly report list
should be sent to "imr-request at isi.edu".
Details on obtaining the current IMR, or back issues, via FTP or
EMAIL may be obtained by sending an EMAIL message to "rfc-
info at ISI.EDU" with the message body "help: ways_to_get_imrs". For
example:
To: rfc-info at ISI.EDU
Subject: getting imrs
help: ways_to_get_imrs
Cooper [Page 1]
Internet Monthly Report July 1993
TABLE OF CONTENTS
INTERNET ARCHITECTURE BOARD
IAB MESSAGE . . . . . . . . . . . . . . . . . . . . . . page 3
INTERNET RESEARCH REPORTS . . . . . . . . . . . . . . . . page 4
PRIVACY AND SECURITY . . . . . . . . . . . . . . . . . page 4
INTERNET ENGINEERING REPORTS . . . . . . . . . . . . . . page 4
Internet Projects
ANSNET/NSFNET BACKBONE ENGINEERING . . . . . . . . . . . page 10
BARRNET . . . . . . . . . . . . . . . . . . . . . . . . . page 13
BOLT BERANEK AND NEWMAN, INC., . . . . . . . . . . . . . page 14
CSUNET (CALIFORNIA STATE UNIVERSITY NETWORK). . . . . . . page 15
INTERNIC INFORMATION SERVICES . . . . . . . . . . . . . . page 16
ISI . . . . . . . . . . . . . . . . . . . . . . . . . . . page 19
JVNCNET . . . . . . . . . . . . . . . . . . . . . . . . . page 29
MERIT/MICHNET . . . . . . . . . . . . . . . . . . . . . . page 31
MERIT/NSFNET ENGINEERING. . . . . . . . . . . . . . . . . page 32
MERIT/NSFNET INFORMATION SERVICES . . . . . . . . . . . . page 39
NEARNET (NEW ENGLAND ACADEMIC AND RESEARCH NETWORK) . . . page 41
NORTHWESTNET . . . . . . . . . . . . . . . . . . . . . . page 41
PREPnet . . . . . . . . . . . . . . . . . . . . . . . . . page 43
UCL . . . . . . . . . . . . . . . . . . . . . . . . . . . page 43
CALENDAR OF EVENTS . . . . . . . . . . . . . . . . . . . . . page 47
Cooper [Page 2]
Internet Monthly Report July 1993
INTERNET ARCHITECTURE MESSAGE
IAB MEETING
The IAB held an open meeting at the Amsterdam IETF, on Tuesday
evening July 13, 1993. About 110 observers attended, approximately
20% of the IETF meeting. The following is a brief summary of the
meeting. A more complete summary is available by anonymous FTP from
host ftp.isi.edu with pathname pub/IAB/IABmins.jul93.txt.
1. Standards Procedures Document
Another round of revisions will be made in the replacement for
RFC-1310, and a new Internet-Draft will be circulated. However,
the IAB feels this document should be moved into an RFC as soon
as possible. A key issue is the rules for intellectual
property, particularly copyrights. The IAB will take steps to
inform and involve the Internet community, as soon as ISOC
lawyers have prepared new text.
2. Proposed ISOC Liaison Agreements with ISO and ITU
The IAB accepted a recommendation from Vint Cerf, President of
the Internet Society, that a Memorandum of Understanding (MOU)
between ISO and ISOC be drafted. This MOU, if accepted by both
sides, would form the basis for a Category A liaison
relationship with ISO. It would be framed to protect the
successful IETF processes for standards making, while
establishing the ground rules for interaction between IETF
working groups and ISO subcommittees, and any other relations
deemed helpful. Cerf agreed to draft such a document, for
presentation to the Internet community for comments and
discussions.
Liaison with the ITU, delayed by their reorganization, is now
under active consideration.
3. Projections of CIDR Effects
There was an extensive discussion of the existing projections of
the effects of CIDR on preserving the IP address space and
preventing a routing explosion. The uncertainties are still
very large, and further studies, with their assumptions
carefully documented, are needed.
Cooper [Page 3]
Internet Monthly Report July 1993
4. Architecture
The IAB has initiated a study of modificiations of the Internet
architecture for shared media, like public data networks.
Steve Kent summarized the ongoing work in the IETF and IRTF
towards a security architecture for the Internet.
Bob Braden, for the IAB (Braden at ISI.EDU)
INTERNET RESEARCH REPORTS
-------------------------
PRIVACY AND SECURITY
--------------------
The PSRG met at Cambridge University on July 7-9, preceeding the
IETF meeting in Amsterdam. Most of the meeting was devoted to
review and discussion of the Internet security architecture
document. This document is now over 100 pages in length and is
expected to double in size by the end of this year. It is
undergoing substantial review and revision by PSRG members and
members of the IETF community are being solicited to contribute
to the document. A draft version of this document will be
published as one or more Internet Drafts before the end of the
year.
The general and program chairs for the ISOC-PSRG Security
Symposium reported that planning is proceeding apace and that
review of submissions will occur in September.
The next meeting of the PSRG will be held at MIT, October 5-7.
Steve Kent <kent at BBN.COM>
INTERNET ENGINEERING REPORTS
----------------------------
IETF MONTHLY REPORT
1. The 27th IETF meeting was held in Amsterdam, The Netherlands,
from July 12-16. 1993. The meeting, co-hosted by SURFnet and
RARE, was the first time an IETF meeting has been held outside
of North America. The meeting was wekk attended with almost 500
attendees during the week, a little over the original estimates
of 450 attendees made one year ago during the Cambridge meeting.
Cooper [Page 4]
Internet Monthly Report July 1993
The ratio of non-US attendees was, as expected, significantly
higher than at the past few meetings which have ranged from
between 8 and 11%. For this meeting, 46% of the attendees were
from outside the United States. The top five countries were, in
terms of the number of individuals attending:
The Netherlands 55 attendees
United Kingdon 30 attendees
Germany 25 attendees
Sweden 15 attendees
France 14 attendees
2. The next meeting of the IETF will be held in Houston, Texas from
November 1-5, 1993. This meeting is being co-hosted by SESQUINET
and Rice University. Note that information on future IETF
meetings can be always be found in the file 0mtg-sites.txt which
is located on the IETF shadow directories.
3. The IESG issued three Last Calls to the IETF during the month
of July, 1993:
o Compressing IPX Headers Over WAN Media (CIPX)
<draft-ietf-pppext-cipx-04> (Proposed Standard)
o FDDI Management Information Base
<draft-ietf-fddimib-objects-02> (Proposed Standard)
o Use of ISO CLNP in TUBA Environments
<draft-ietf-tuba-clnp-04> (Proposed Standard)
4. One Working Group was concluded during this period:
Chassis MIB (chassis)
5. 62 Internet Draft actions were taken during the month of July,
1993:
(Revised draft (o), New Draft (+) )
(cat) o Generic Security Service API : C-bindings
<draft-ietf-cat-secservice-03.txt>
(mospf) o Multicast Extensions to OSPF
<draft-ietf-mospf-multicast-04.txt, .ps>
(mhsds) o Representing Tables and Subtrees in the Directory
<draft-ietf-mhsds-subtrees-03.txt, .ps>
(mhsds) o Representing the O/R Address hierarchy in the
Directory Information Tree
<draft-ietf-mhsds-infotree-03.txt, .ps>
Cooper [Page 5]
Internet Monthly Report July 1993
(mhsds) o Use of the Directory to support routing for RFC 822
and related protocols
<draft-ietf-mhsds-822dir-03.txt, .ps>
(mhsds) o Use of the Directory to support mapping between
X.400 and RFC 822 Addresses
<draft-ietf-mhsds-supmapping-03.txt, .ps>
(mhsds) o A simple profile for MHS use of Directory
<draft-ietf-mhsds-mhsprofile-03.txt, .ps>
(mhsds) o MHS use of Directory to support MHS Routing
<draft-ietf-mhsds-routdirectory-03.txt>
(pppext) o The PPP Internetwork Packet Exchange Control
Protocol (IPXCP) <draft-ietf-pppext-ipxcp-04.txt>
(bgp) o Definitions of Managed Objects for the Border
Gateway Protocol (Version 4)
<draft-ietf-bgp-mibv4-02.txt>
(tuba) o Use of ISO CLNP in TUBA Environments
<draft-ietf-tuba-clnp-04.txt>
(nasreq) o Network Access Server Proposed Requirements Document
<draft-ietf-nasreq-nasrequirements-01.txt>
(hostmib) o Host Resources MIB
<draft-ietf-hostmib-resources-02.txt>
(mhsds) o MHS use of Directory to support MHS Content
Conversion <draft-ietf-mhsds-convert-01.txt, .ps>
(ospf) o OSPF Version 2 <draft-ietf-ospf-version2-03.txt,
.ps>
(x400ops) o Postmaster Convention for X.400 Operations
<draft-ietf-x400ops-postmaster-02.txt>
(pppext) o Compressing IPX Headers Over WAN Media (CIPX)
<draft-ietf-pppext-cipx-04.txt>
(avt) o RTP: A Real-Time Transport Protocol
<draft-ietf-avt-rtp-02.txt>
(avt) o Media Encodings <draft-ietf-avt-encodings-01.txt>
(avt) o Sample Profile for the Use of RTP for Audio and
Video Conferences with Minimal Control
<draft-ietf-avt-profile-01.txt>
(pppext) o PPP LCP Extensions <draft-ietf-pppext-lcpext-02.txt>
(pip) o Use of DNS with Pip <draft-ietf-pip-dns-01.txt>
(none) o Classless Inter-Domain Routing (CIDR): an Address
Assignment and Aggregation Strategy
<draft-fuller-cidr-strategy-03.txt>
(iplpdn) o Parameter Negotiation for the Multiprotocol
Interconnect
<draft-ietf-iplpdn-para-negotiation-01.txt>
(iplpdn) o Determination of Encapsulation of Multi-protocol
Datagrams in Circuit-switched Environments
<draft-ietf-iplpdn-multi-isdn-01.txt>
(pppext) o PPP over ISDN <draft-ietf-pppext-isdn-01.txt>
Cooper [Page 6]
Internet Monthly Report July 1993
(pppext) o PPP in Frame Relay
<draft-ietf-pppext-frame-relay-01.txt>
(pppext) o PPP in X.25 <draft-ietf-pppext-x25-01.txt>
(cat) o FTP Security Extensions
<draft-ietf-cat-ftpsec-02.txt>
(none) o Exchanging Routing Information Across Provider
Boundaries in the CIDR Environment
<draft-rekhter-cidr-environment-01.txt>
(mospf) o MOSPF: Analysis and Experience
<draft-ietf-mospf-analysis-02.txt>
(none) o Connection Multiplexing Protocol (CMP)
<draft-cameron-cmp-01.txt>
(uri) o Uniform Resource Locators
<draft-ietf-uri-url-01.txt, .ps>
(tuba) o Assignment of System Identifiers for TUBA/CLNP Hosts
<draft-ietf-tuba-sysids-02.txt>
(none) o FTP Operation Over Big Address Records (FOOBAR)
<draft-piscitello-ftp-bigports-02.txt>
(none) o Korean Character Encoding for Internet Messages
<draft-chon-korean-encoding-01.txt>
(frnetmib) o Definitions of Managed Objects for Frame Relay
Service <draft-ietf-frnetmib-fr-02.txt>
(isn) o FYI on Questions and Answers: Answers to Commonly
Asked "Elementary and Secondary School Internet
User" Questions <draft-ietf-isn-faq-01.txt>
(dns) o DNS Resolver MIB Extensions
<draft-ietf-dns-resolver-mib-01.txt>
(dns) o DNS Server MIB Extensions
<draft-ietf-dns-server-mib-01.txt>
(atm) o Default IP MTU for use over ATM AAL5 Services
<draft-ietf-atm-mtu-01.txt>
(atm) o Classical IP and ARP over ATM
<draft-ietf-atm-classic-ip-01.txt>
(frnetmib) o Service Management Architecture for Virtual
Connection Services
<draft-ietf-frnetmib-virtual-sma-01.txt>
(iiir) o Hypertext Markup Language (HTML): A Representation
of Textual Information and MetaInformation for
Retrieval and Interchange
<draft-ietf-iiir-html-01.txt, .ps>
(madman) o DSA Monitoring MIB
<draft-ietf-madman-dsa-mib-01.txt>
(pppext) + PPP HDLC Framing <draft-ietf-pppext-framing-00.txt>
(wnils) + Whois and Network Information Lookup Service Whois++
<draft-ietf-wnils-whois-lookup-00.txt>
(pppext) + The Point-to-Point Protocol (PPP)
<draft-ietf-pppext-lcp-main-00.txt>
Cooper [Page 7]
Internet Monthly Report July 1993
(dns) + Common DNS Errors and Suggested Fixes
<draft-ietf-dns-common-errors-00.txt>
(x400ops) o Mail based file distribution Part 1: Dialog between
two nodes <draft-ietf-x400ops-tbl-dist-part1-01.txt>
(appleip) + KIP AppleTalk/IP Gateway Functionality
<draft-ietf-appleip-kip-gateway-00.txt, .ps>
(x400ops) o Mail based file distribution Part 2: Over-all
structure <draft-ietf-x400ops-tbl-dist-part2-01.txt>
(pip) + IP Independent Transition (IPIT) for Pip
<draft-ietf-pip-ipit-transition-00.txt>
(isis) + Routing over Nonbroadcast Multiaccess Links
<draft-ietf-isis-nbma-00.txt>
(none) + TELNET MPX option
<draft-caradec-telnet-mpx-option-00.txt>
(none) + Definitions of Managed Objects for the Node in Fibre
Channel Standard
<draft-chu-fibre-channel-mib-00.txt>
(iplpdn) + A Simple Multilink Protocol for Synchronizing the
Transmission of Multi-protocol Datagrams.
<draft-ietf-iplpdn-simple-multi-00.txt>
(pppext) + Point-to-Point Protocol Extensions for Bridging
<draft-ietf-pppext-for-bridging-00.txt>
(none) + The Virtual Network Protocol for Host Mobility
<draft-teraoka-mobileip-vip-00.txt>
(none) + Internet Authentication Requirements
<draft-haller-auth-requirements-00.txt>
(tn3270e) + TN3270 Enhancements
<draft-ietf-tn3270e-enhancements-00.txt>
(tn3270e) + TN3270 Extensions for LUname and Printer Selection
<draft-ietf-tn3270e-luname-print-00.txt>
6. 17 RFC's were published during the month of July, 1993.
RFC St WG Title
------- -- -------- -------------------------------------
RFC1440 E (none) SIFT/UFT: Sender-Initiated/Unsolicited
File Transfer
RFC1477 I (idpr) IDPR as a Proposed Standard
RFC1478 PS (idpr) An Architecture for Inter-Domain Policy
Routing
RFC1479 PS (idpr) Inter-Domain Policy Routing Protocol
Specification: Version 1
RFC1481 I (iab) IAB Recommendation for an Intermediate
Strategy to Address the Issue of Scaling
RFC1482 I (bgpdepl) Aggregation Support in the NSFNET Policy
Routing Database
RFC1483 PS (atm) Multiprotocol Encapsulation over ATM
Adaptation Layer 5
Cooper [Page 8]
Internet Monthly Report July 1993
RFC1484 E (osids) Using the OSI Directory to achieve User
Friendly Naming(OSI-DS 24(v1.2))
RFC1485 PS (osids) A String Representation of Distinguished
Names(OSI-DS 23(v5))
RFC1486 E (none) An Experiment in Remote Printing
RFC1487 PS (osids) X.500 Lightweight Directory Access
Protocol
RFC1488 PS (osids) The X.500 String Representation of
Standard Attribute Syntaxes
RFC1489 I (none) Registration of a Cyrillic Character Set
RFC1490 DS (iplpdn) Multiprotocol Interconnect over Frame
Relay
RFC1491 I (ids) A Survey of Advanced Usages of X.500
RFC1492 I (none) An Access Control Protocol, Sometimes
Called TACACS
RFC1493 DS (bridge) Definitions of Managed Objects for
Bridges
St(atus): ( S) Internet Standard
(PS) Proposed Standard
(DS) Draft Standard
( E) Experimental
( I) Informational
Steve Coya (scoya at nri.reston.va.us)
Cooper [Page 9]
Internet Monthly Report July 1993
INTERNET PROJECTS
-----------------
ANSNET/NSFNET BACKBONE ENGINEERING
----------------------------------
Network Status Summary
======================
ANSnet stability improved in July over the June measurements. New
routing software was deployed in the ANSnet to reduce instability,
and simplify the reconfiguration process. T3 circuit topology
changes where implemented to improve route diversity.
July Backbone Traffic and Routing Statistics
============================================
The total inbound packet count for the network (measured using SNMP
interface counters) was 32,888,889,408 on T3 ENSS interfaces, up
4.6% from June. The total packet count into the network including
all ENSS serial interfaces was 37,587,985,321 up 5.8% from June.
As of July 31, the number of networks configured in the Merit
Policy Routing Database was 14122 for the T3 backbone. Of these,
3228 were never announced to the T3 backbone (e.g. silent nets).
The maximum number of networks announced to the T3 backbone during
the month (from samples collected every 15 minutes) was 10,058.
Rcp_routed Routing Software Changes
===================================
During July the "Dynamic Reconfig" version of the rcp_routed
routing daemon was deployed. The primary purpose of this version
was to eliminate the disturbance caused by restarting the routing
daemon as a means of reconfiguration. Problems arose with this
feature, and for the moment routing daemon restarts are still being
used to accomplish reconfiguration. There was also a problem with
an EGP option used only at ENSS145. To correct this, the "Less
Broken" version of the routing daemon was deployed on ENSS145. In
August, the problems with the reconfiguration are expected to be
corrected allowing non-disruptive reconfigurations. Release notes
provide further details. They can be found in:
ftp.ans.net:/pub/info/t3-rcp_routed/Release-Notes
Cooper [Page 10]
Internet Monthly Report July 1993
Routing Stability Measured on the T3 Network
============================================
Internal routing stability measurements are made by monitoring
short term disconnect times (disconnects of five minutes duration
or less). This is intended as a measure of stability rather than
complete connectivity. Stability during July was 97.3% including
disruptions during the configuration windows. Excluding the
configuration windows, stability was 97.7%.
MONTH overall excluding configs
------ ------- -----------------
January 99.1% 99.5%
February 99.0% 99.5%
March 97.5% 99.1%
April 96.1% 97.2%
May 97.4% 98.0%
Jun 95.5% 96.6%
July 97.3% 97.7%
July stability was improved over June. Most of the network was
quite stable. ENSS230 suffered chronic troubles throughout the
month. There was one troublesome CNSS-CNSS circuit that
contributed to the instability. This was the CNSS80 (St. Louis) to
CNSS96 (Denver) circuit. The flooding in the Midwest contributed
to problems with this circuit.
A patch panel problem at CNSS57 (College Park) on July 13 caused a
lengthy outage to the T3 circuit at ENSS136. There was about 3.75
hours of instability at ENSS136 due to congestion on the T1 backup
link. This single event made ENSS136 the most unstable node in
July. ENSS145 has exhibited CPU starvation problems. Reducing the
routing daemon logging on this machine has helped. The problem is
related to building 24 KB EGP packets (and searching the
announcement restrictions to do so) for multiple EGP peers that
accept full routing. ENSS145 saw 3.5 hours of instability.
ENSS136 and ENSS144 have seen similar problems but far less often
(ENSS144 saw about 2 hours of instability). The Denver nodes also
exhibited instability due to the St. Louis to Denver circuit.
These are ENSS213, ENSS141 and ENSS142, each with over 3 hours of
instability.
The remaining ANSnet nodes saw under 3 hours of cumulative
instability. The number of nodes experiencing a great deal of
outage improved over June. The breakdown by sites is as follows:
Cooper [Page 11]
Internet Monthly Report July 1993
MONTH >5 hr >2 hr > 1hr >30 min >15 min <= 15min
------------------------------------------------------------
January 0 0 1 8 19 55
February 0 0 1 24 19 41
March 0 4 18 23 23 22
April 2 2 3 13 12 57
May 0 4 33 32 15 5
June 3 21 35 18 12 3
Jul 0 12 28 44 6 1
The majority of ANSnet nodes saw between 30 minutes to 2 hours of
instability. That is between 99.9 and 99.7 percent stability. Two
problems which can be corrected are improvements in routing around
problem links and elimination of the config run disruptions. The
former will reduce the instability due to problems such as the St.
Louis to Denver link and the latter will move the majority of nodes
to the under 30 minutes of instability threshold (better than 99.9%
stability).
T3 Backbone Topology Change
===========================
During July, we added a new T3 circuit between the Hartford CNSS48
and the Cleveland CNSS40. We also removed the T3 circuit between
the Greensboro CNSS72 and the Hartford CNSS48.
The San Francisco CNSS8 <-> Seattle CNSS88 T3 backbone link was
rolled over to a new fiber.
Notable Outages in July '93
============================
E140 (Lincoln) suffered an extended outage due to hardware problems
on 7/1
Several circuits terminating in St. Louis suffered from problems on
7/13 that were complicated by flooding.
E230 (DigEx) suffered an extended outage due to scheduled circuit
testing on 7/7
E139 (Rice) sufferd an extended circuit outage on 7/11
E136 (College Park) lost T3 connectivity due to hardware problems
on 7/13
Jordan Becker <becker at ans.net>
Cooper [Page 12]
Internet Monthly Report July 1993
BARRNET (BAY AREA REGIONAL RESEARCH NETWORK)
--------------------------------------------
BARRNET Membership Update
-------------------------
Date: 7/31/93
Member Organizations: 185
New Members, Jun/Jul: Philips Semiconductor
Woodland High School
Informix Software
CR Labs
VHDL International
Kalpana, Inc.
Elan Computer Group
TelLink
Publications: The BARRNetter (Quarterly Newsletter)
Heard on the Net (Electronic
Newsletter) BARRTech Notes
The BARRNetter, Heard on the Net, and BARRTech notes are
currently available to BARRNet members only. Submissions and
comments welcome. Email: jhoag at barrnet.net
News: Networkers from over 60 countries will attend a 6-day
workshop for technologically developing countries to be held
this August 10-16 on the Stanford campus. BARRNet and the
Internet Society are co-sponsoring the workshop, which will
be held in conjunction with INET '93. 130 participants will
attend workshop sessions taught by an international team of
instructors, covering low-cost and advanced internetworking
technologies and the use of network services. Following the
workshop, attendees will also participate in the INET'93
conference in San Francisco.
New FTP Archives and Gopher server: BARRNet's ftp archives
can now be reached at either of the following hostnames:
ftp.barrnet.net
nic.barrnet.net
Gopher clients can access these archives by connecting to:
gopher.barrnet.net (port 70)
Cooper [Page 13]
Internet Monthly Report July 1993
The BARRNet anonymous FTP archives contain information about
BARRNet, the Internet in general, and resources to assist
our members in configuring aspects of their internetworking
connections. In the months ahead, the archives will be
expanded to include a wider range of Internet resource
materials, popular client/server software, and other files
of general interest to the Internet community.
BARRNet info at barrnet.net
Pine Hall, Rm 115 Phone: 415-725-1790
Stanford University Fax: 415-723-0010
Stanford, CA 94305-4122
John Hoag <jhoag at barrnet.net>
BOLT BERANEK AND NEWMAN INC.
----------------------------
Scaleability
------------
Work on the network editor for the flow-level simulator is nearing
completion. The user interface has been constructed using GUI
tools from the InterViews distribution. The graphical network
editor has been heavily leveraged from the Unidraw graphical editor
toolkit, which is based on a general model of graphically-
represented objects with additional state and which directly
supports connections between objects.
The study on congestion issues for distributed simulation has been
completed. For the probable topologies for distributed
simulations, there is typically only one bottleneck point along any
given path -- it occurs as the traffic enters a site tail circuit
(typically T1) from the backbone network (expected to be T3).
There appear to be three useful strategies in handling congestion
at this point:
- the application should prioritize traffic, and the network
should provide priority queueing
- the network should provide fairness between flows (based on
source/destination addresses)
- when traffic is dropped, the oldest traffic in queue for the
given flow should be dropped, rather than dropping the newest
traffic
(See December '92 Internet Monthly Report for more details about
this project and the toolset being developed.)
Cooper [Page 14]
Internet Monthly Report July 1993
Real-Time Multicast (Communications)
------------------------------------
During July, we implemented two new multicast services as
modifications to mrouted -- multi-level flows and multicast access
control.
Multi-level flows are intended for use in applications where
different types or grades of data (such as hierarchically-encoded
video) are being sent to a multicast address where receivers might
have differing requirements for the various data streams. The
sending application labels messages in a multicast flow with a
subflow identifier (carried in the IP precedence field). Receivers
can provide a subflow mask when adding themselves to a group (the
subflow mask is carried in an unused field in the IGMP Host
Membership Report message). Routers only forward packets if they
belong to a requested subflow. When IP multicast supports pruning,
some simple modifications to the routing protocol will be required
to propagate subflow masks with the routing information.
IP multicast access control is a mechanism to provide a simple form
of access control to the IP multicast system. An access list of
permitted receivers is provided to mrouted. When an IGMP Host
Membership Report is received by mrouted, the source is checked
against the list for the group (if any is provided), and the
message is ignored if the host is not present. Backwards
compatibility is maintained by having groups without access lists
allow any receiver to join. The access list is distributed using
"flow-tracking" RCOs (described in the May Internet Monthly), which
are associated with the multicast destination address.
A draft of a document describing Resource Coordination Objects
(RCOs) was completed, with a final draft planned for distribution
next month.
We have started work on an RCO-based resource-scheduling utility,
intended to help organize access to shared network resources such
as the DARTnet and the MBONE.
Karen Seo <kseo at BBN.COM>
CSUNET (THE CALIFORNIA STATE UNIVERSITY NETWORK)
-----------------------------------------------
* In order to reduce costs to end-users, CSUnet has dropped its
subscription to CERFNET as of July 31. CSUnet will retain its T-1
connections to the NSFNET ENSS at San Diego and to BARRNET at San
Francisco and San Diego.
Cooper [Page 15]
Internet Monthly Report July 1993
* CSUnet is investigating how to ramp-up to DS3/ATM to provide for
interactive two-way video-conferencing and increased Internet
demands.
* A Request for Information (RFI) to telecommunications facility
vendors was disseminated to several major IECs and RBOCs which will
disclose (via non-disclosure agreements with CSUnet) their
proprietary ATM and Broadband, Low and Medium Bandwidth, and remote
access offerings and plans that are soon to be available. The
responses are due mid-August.
Newly Connected CSUnet TCP/IP Members:
-------------------------------------
CSU Monterey Bay, Planning Office (Seaside, CA)
El Camino College (converted from X.25 to Internet)
Grossmont Unified High School District (San Diego, CA)
Kern Community College District (Kern, CA)
Ventura County Superintendent Of Schools (Ventura, CA)
New Pending TCP/IP Members (signed contract pending):
-----------------------------------------------------
Butte College (Orville, CA)
College of the Sequioas (Visalia, CA)
This is also a PBX and video connection.
Mike Marcinkevicz <mdm at csu.net>
INTERNIC INFORMATION SERVICES
-----------------------------
This month the InterNIC begins regular entries to the Internet
Monthly Report. The InterNIC is a cooperative project of three
organizations, General Atomics/CERFnet, AT&T, and Network
Solutions, Inc. (NSI), designed to provide network information
services to the networking community. General Atomics/CERFnet
provides Information Services; AT&T provides Directory and Database
Services; and NSI provides Registration Services.
InterNIC Information Services
-----------------------------
InterNIC Information Services, provided by General Atomics/CERFnet,
provides a range of services to the networking community. These
include a Reference Desk with a toll-free phone number
(800.444.4345) and mailbox (info at internic.net). InterNIC
Information Services provides procedures for getting connected to
Cooper [Page 16]
Internet Monthly Report July 1993
the Internet, pointers to resources and tools available over the
network, and training seminars for new and intermediate users.
The goal of InterNIC Information Services is to act as a focal
point of information for network information centers (NICs) and end
users. Information about the Internet and how to use it is
collected and re-distributed via hardcopy and FAX, and through the
InfoSource via Gopher, WAIS, telnet, FTP, and e-mail. Below are
statistics from July representing the number and type of inquiries
handled by InterNIC's Reference Desk:
REFERENCE DESK CONTACTS - July, 1993
====================================
Method Contacts Daily Average
====== ======== =============
Email 288 14
Phone 944 47
FAX 68 3
U.S. Mail 15 1
=============================================
TOTAL 1,315 66
During July, Information Services also planned the first NIC Fest,
to be held in conjunction with SIGUCCS in San Diego on November 6.
The InterNIC seminar schedule has also been established. Details on
both seminar and NIC Fest can be found on the InfoSource or by
sending mail to info at internic.net. Visit the InterNIC booth at
InterOP and leave your card for a chance to win a free gift.
Directory and Database Services
-------------------------------
InterNIC Directory and Database Services, provided by AT&T, offers
a number of services designed to help users find resources in the
Internet.
The "Directory of Directories" contains individual listings of many
types of resources. "Directory" Services provides access to tools
that help locate individuals or specific files (WHOIS, X.500,
Netfind, Archie, Gopher). "Database" Services makes general
Internet information (RFCs, Internet Drafts, etc.) available to the
community and can also support databases for special groups or
other organizations.
The Directory of Directories was originally seeded with the
contents of the Internet Resource Guide (compiled by BBN's NNSC),
and is continually expanded to include new entries. If you have a
Cooper [Page 17]
Internet Monthly Report July 1993
resource you would like to list, or would like detailed information
on any of our services, please send email to admin at ds.internic.net.
July activities in Directory and Database Services included
creation and maintenance of a "Current IETF Documents Archive" to
make available the most current versions of documents during the
Amsterdam IETF and recording the MBONE broadcasts of Amsterdam IETF
sessions so they could be downloaded and played back for those who
could not attend or listen "live". Directory and Database Services
also initiated registration of our X.500 DSA at the root level of
the DIT to provide increased reliability, and creation of a WHOIS
server that searches WHOIS data available at MILNET, InterNIC
Registration Services, and InterNIC Directory and Database
Services, returning the combined results.
InterNIC Registration Services
------------------------------
The InterNIC registration services group continues to work with
Internet service providers and regional registries on CIDR address
allocation. There were 71,204 Class C number delegated or
allocated during this month of operation. This large number
includes the delegation of 194.x.x.x to RIPE NCC. We will continue
the delegation to providers as necessary. Individual class C
requests are being referred to the anticipated service provider
when a service provider can be identified.
The following statistic show the activity at the InterNIC
Registration facility during the month of July.
Hostmaster Email 2772
Postal/Fax Applications 250
Telephone Calls 903
Domain Registered 554
Inverse Addresses 356
Class C's Assigned 71,204
Class B's Assigned 193
ASN Assigned 26
Connections Retrievals
Gopher Sessions 24,254 9,662
Wais Sessions 12,224 21,725
Ftp Sessions 4,404 17,873
Telnet Sessions 27,084
Mail Server 778
Susan Calcari (susanc at is.internic.net)
Subu Subramanian (subu at qsun.att.com)
John Zalubski (johnz at internic.net)
Cooper [Page 18]
Internet Monthly Report July 1993
ISI
---
GIGABIT NETWORKING
Joyce Reynold's Trip Report
Joint European Networking Conference
Norwegian Institute of Technology (NTH)
Trondheim, Norway
May 10th-13th, 1993
RARE ISUS Working Group
The RARE Information Services and User Support (ISUS) Working
Group, chaired by Jill Foster, met in tandem with the JENC
Conference. The first meeting was held of the morning of May
10th.
The agenda on this day included:
1) Review of the Pisa minutes
Report on the results of the electronic mail meeting
Other matters
2) Administrative
3) Report of COSINE projects (Concise, P3)
4) Brief Liaison Reports (IETF User Services Area,
CNI, TopNode, CNIDR, and EARNInfo)
5) Update/Review of the Task Forces within ISUS (e.g.,
Support of Special Interest Groups, ISO SR projects,
document delivery, CWIS, etc.)
Other business on this agenda included documentation (from
10:00- 11:00am), publicity awareness (11:00-12:00noon), an ISUS
plenary (12:00-12:30pm), and any other business.
Introductions were made around the room from the attendees.
Discussion then focussed around the RARE Document server and the
mailing list. They are now available via Gopher. Comments were
made from the attendees that there not only needs to be a number
on each of the documents on this server, but also there is a
need to put in some kind of abstract. Erik Huizer suggested
that this group ought to tailor the "style" based on CNRI's
Internet-Drafts type tagging. This is a preliminary suggestion.
Tim Dixon, Erik, Jill, and others will discuss this further.
Cooper [Page 19]
Internet Monthly Report July 1993
Brief Report on COSINE projects
This included CONCISE (a European Information Service) and P3
(Supports International User Groups). COSINE is looking for
funding for the continuation of its projects. P3 is currently
being funded. Each group is trying to be self sufficient.
A talk was presented on CONCISE. The past history was CONCISE
was to build an OSI information services. This project was
completed, and the deliverables were satisfied. The services
were extended to February 1993, as the usage was increasing. In
regards to CONCISE in the present:
information items available circa 800
countries accessing greater than 35
accesses in quarter 1 (1993) 6,296
SIGs (special interest groups) 12
server reliability over 12 months 99%
The CONCISE future includes:
services contract anticipated to continue
support and maintenance agreed for 1993
A fourth CONCISE site is to be in Belgium
Enhancements are planned (e.g., Telnet, access to other
servers, etc.)
CONCISE questions:
- Positioning - where should it fit within the relationships
of information services in Europe and globally.
- Publicity - usage increases dramatically when information
is disseminated
- information - what is put out?
- Enhancements
Liaison Reports
Geza Turchanyi presented a report on RIPE's NIDUS (Network
Information Discovery for Users Support) Working Group.
This group is currently concentrating on user surveys and
documentation.
Bert Stals presented an EARNinfo report, including EARN's
"Guide to Network Resource Tools" publication.
Cooper [Page 20]
Internet Monthly Report July 1993
Joyce Reynolds presented a report on the current activities
and new FYI RFC publications of the User Services Area of
the Internet Engineering Task Force (IETF).
Document Delivery
Bert Stals lead this session. This session focused on the
better use of networked services, and offering assistance in
using networks. Deliverables currently include:
introduction leaflets
user guides
reference cards
handout/leaflet publication
The original intent of this group is to bring together basic
introductory information for local and national support groups.
There is a desire to see information up on a central Gopher
server, so that one can set up a "training Gopher". In
regards to publication of documentation, if it is copyrighted,
will there be a willingness for redistribution? The answer is
if there is an acknowledgement from the source, similar to the
RFC series of notes. The problem with this is that some
publishers have taken the verbatim documentation, published
it and then made a profit. There seemed to be two differing
opinions that came out of this group's discussions regarding
user and documentation availability. Concensus was reached
that "political" filtering should make all information
available to all users.
Network Training Material Task Force Meeting
The aims of this group include:
- see what network training material exist
- provide a comprehensive mix and match package for:
a) network training staff
b) end users
- use the net to deliver training
- share experiences and successful methods
- enable the research community to make better use
of networked services
- liase with IETF and Australian groups
Margaret Issacs is working on a catalog of training materials.
Jill is looking for volunteers to help add to the catalog. She
has a couple of North American volunteers. Milan Sterba
volunteered a student working with him to help out from the
Cooper [Page 21]
Internet Monthly Report July 1993
European perspective.
A training PAK is being developed by this Task Force. The
pack is to include:
video
OHP Masters
Speaker's notes and suggested demos
Handouts
Workshop sheets
Evaluation forms
Disk based tutorial
Bibliography of reference documentation
IETF BOF at JENC
Erik Huizer presented an IETF BOF which included:
- What is the IETF?
- How does it work?
- What is an RFC?
- What is a STD (Standard)?
- What kinds of working groups will be
meeting in Amsterdam?
- What will they be working on?
Joyce Reynolds submitted an IETF User Services Area summary
for Erik to read to the BOF participants on what working
groups in her area will meet and what they will work on.
Global Interconnection session
Bernhard Stockman led off this session with a slide of Europe
and networking traffic from 1991. Since then, there has been
an increase of traffic and a there is a need for more global
infrastructure. The Global Internet Exchange (GIX) is being
developed. This is due to the advent of global connectivity.
The increased complexity has driven the concept of the GIX.
There is a need for a specification of a neutral framework.
The GIX proposal was worked out by the IEPG (Internet
Engineering Planning Group). The intent is to specify
connection points so people can come with their router
and connect.
In this spring of 1993, a pilot GIX was installed in
Washington, D.C. Bernhard emphasized that this is currently
a working version, not a production version. Its intent:
Cooper [Page 22]
Internet Monthly Report July 1993
- ubiquitous and homogeneous Internet
- maximal connectivity and maximal facility
- simplified method to give connectivity to all
Internet connected networks
- stable and reliable policy based routing
- no restrictions in top level transit backbones
- free choice of transit backbones
- restriction as close to the end-users as possible
The functionality of GIX includes connectivity, transit, and
routing. It is required to have scalability, manageability,
accountability, and timeliness. The GIX model includes a
physical layer 2 structure where providers can be their
routes and peer with other providers. There is to be a
routing registry, also. Discussion are continuing to go
on with regards to routing implementation, switching of
traffic, transit, and management.
There has been one basic model discussed for one GIX:
|---| |---|
| N |--------------| |---------| N |
|---| | | |---|
| |
|---------|
| |
| GIX |
| |
|---------|
| |
|---| | | |---|
| N |--------------| |---------| N |
|---| |---|
This provides low connection cost for geographically close local
networks.
Multiple GIXs are interconnected via fully connected backbones
(services providers). Some networks connect as a backbone,
others have to negotiate transit. Multiple GIXs interconnected
via shared resources need commonly agreed methods (similar
to EBONE).
Cooper [Page 23]
Internet Monthly Report July 1993
Refinements to GIX:
1) Physical Layer 2 LANs
* 24hr/7days a week management coverage
* excellent environmental support
* pro-rate the share of costs
2) Routing Registry
* neutral routing registry
* registration of preferred paths
* method for routing policy
3) Route Server
* gated
The Washington D.C. GIX pilot (this is NOT the GIX, but this
is the platform where they are piloting a GIX) is called
MAE-East. They may set up another pilot on the West coast
(MAE-West) if this pilot proves successful. Participation
is from several telecommunications entities (MCI, Sprint,
etc.). This pilot is supported by the CIX Association, and
is regarded as excellent as a first GIX pilot. The traffic
capacity is possible over the MAE-East, but also via direct
connection between connecting networks.
The working rules for MAE-East:
- only network providers can join
- any network providers can join
- any network providers may or may not peer with
any other provider
- providers pay for their connection
Daniel Karrenberg was the second presenter of this session
presenting a talk coordinating IP networks in Europe. There
were 350,000 hosts registered in the DNS (Domain Name System)
as of last March 1993. Daniel went on to explain what is RIPE
and what is the RIPE NCC. RARE is the financial and legal
umbrella of the RIPE organizations. In general, there are
providing:
1) information services and the RIPE document store
2) WAIS, Gopher, and WWW access
3) interactive services
4) general support for the RIPE meetings
Cooper [Page 24]
Internet Monthly Report July 1993
The most specialized services the RIPE NCC provides include:
1) The Internet Registry (IR) (specifically,
IP network numbers)
Global Internet Registry (InterNIC)
/ \
/ \
|---------| |----------|
| RIPE | | A-P |
| NCC | | NIC |
|---------| |----------|
The Internet Assigned Numbers Authority (IANA) delegates to
the IRs.
There are currently more than 1,000 network numbers assigned
by the RIPE NCC each month. These assignments are
decentralized to local IRs:
2) service provider IRs (Europanet, EBONE, etc.)
3) non-services providers (community services, goodwill)
The challenges to this effort is in managing the growth. It
is an exciting challenge. Daniel noted that Paul Mockapetris,
in his talk, mentioned that there could be 100,000 nets by 1996.
Other challenges include:
1) routing stability in the registry, with a multiple
interconnection architecture. You will have to have
something like this.
2) quality of services
3) to find good people to do the work
4) getting the funds to continue. A need to spread
funding out to more services providers.
IPng (Next Generation Internet Protocol) session
Bob Hinden presented a talk on the next generation of IP
effort, which included discussion on what is the short term,
medium term, and long term issues, and a summary.
What is the problem? Overwhelming success! In the beginning,
no one could imagine running out of IP network numbers. The
Cooper [Page 25]
Internet Monthly Report July 1993
Internet is doubling about every year. 11,000 networks in
excess of millions of hosts. There are problems in two areas.
In the short term, it is the routing table size and computation.
In the later term, it is IP address exhaustion. This is a
"success" problem, not a "broken" problem.
Bob put up an Internet growth graph slide which showed a big
curve, which doesn't seem to want to level off. Recently, the
growth curve has been going in a straight line, but it still
doesn't stop. Bob explained that IP routing is largely flat.
There is no topological relationship, if you were just looking
at an IP number. There is a need to have routing computations
that are consistently updated, globally. There is no information
in addresses to aggregate. One can send a whole range of
addresses in one route. Routing tables are growing
exponentially.
The current IP addresses are broken into three classes (A,B,C,
etc.). In the local part of an address is the division between
domain and host. In the short term, we are running out of Class
B network numbers and assignments of multiple Class C addresses
will aggravate routing problems. In the long term, we will run
out of all network numbers.
What is being done? The IETF is developing solutions. The short
term solution is CIDR (Classless Inter-Domain Routing). In the
medium term, new IP protocols are in development with large
address space, with fixed boundaries of IP addresses:
Class As are too big
Class Bs are 50% assigned
Class Cs are too small
CIDR will relax the boundaries of IP addresses. It will allow
multiple Class C addresses to be used efficiently at one site.
Allocate blocks of IP addresses to providers. New or additional
assignments will be made from provider blocks.
In the medium term of new protocol development, there are three
primary contenders: TUBA, SIP/IPAE, and PIP. In Bob's opinion,
it will be the transition factor, not what protocol will be
used, that will be most critical. All these protocol can work,
with responsible people working on this effort. The community
needs to decide. Once one protocol is chosen, the people need
to get behind it and support it.
Cooper [Page 26]
Internet Monthly Report July 1993
Long Term work:
NIMROD
- separation of address and identifiers
- dynamic creation of level of hierarchy
independent of hosts
- routes calculated and installed based on
traffic patterns and policy requirements
UNIFIED Source Demand Routing (SDR)
- use BGP/IDRP protocols for common case
routers
- use IDPR for specialized policy routes
- provide efficient, yet flexible routing
In summary:
- there is significant work in all of these areas
- CIDR is being deployed now
* blocks of addresses have been assigned to providers
- new IP protocols are being developed and implemented
* no clear winner (yet)
* routing implementations are being
routed and deployed
* research is underway on routing paradigms,
with the focus on stability and flexibility
Internet Engineering Steering Group (IESG) teleconference
There was an IESG teleconference held on 13 May, in which
Bob Hinden, Erik Huizer and Joyce Reynolds participated at
the SINTEF facility in Trondheim, during the JENC conference.
Special thanks to Alf Hansen for his assistance.
15 RFCS WERE PUBLISHED THIS MONTH.
RFC 1477: Steenstrup, M., "IDPR as a Proposed Standard",
BBN Systems and Technologies, July 1993.
RFC 1479: Steenstrup, M., "Inter-Domain Policy Routing
Protocol Specification: Version 1", BBN Systems
and Technologies, July 1993.
RFC 1481: Huitema, C., " IAB Recommendation for an
Intermediate Strategy to Address the Issue
of Scaling", July 1993.
RFC 1482: Knopper, M., Steven J. Richardson, "Aggregation
Support in the NSFNET Policy-Based Routing
Cooper [Page 27]
Internet Monthly Report July 1993
Database", Merit/NSFNET, June 1993.
RFC 1483: Heinanen, Juha, "Multiprotocol Encapsulation over
ATM Adaptation Layer 5", Telecom Finland,
July 1993.
RFC 1484: Hardcastle-Kille, S., "Using the OSI Directory
to Achieve User Friendly Naming (OSI-DS 24
(v1.2)", ISODE Consortium, July 1993.
RFC 1485: Hardcastle-Kille, S., "A String Representation
of Distinguished Names (OSI-DS 24 (v1.2)",
ISODE Consortium, July 1993.
RFC 1486: Rose, M., (Dover Beach Consulting, Inc.),
C. Malamud, (Internet Multicasting Service),
"An Experiment in Remote Printing", July 1993.
RFC 1487: Yeong, W. (PSI), T. Howes (University of Michigan)
S. Kille (ISODE Consortium), July 1993.
RFC 1488: Howes, T, (University of Michigan), S. Kille
(ISODE Consortium), W. Yeong (PSI Int'l), C. Robbins
(NeXor Ltd), "The X.500 String Representation of
Standard Attribute Syntaxes", July 1993.
RFC 1489: Chernov, A., "Registration of a Cyrillic Character
Set", RELCOM Development Team, July 1993.
RFC 1490: Bradley, T., C. Brown, (Wellfleet Comm.), and
A. Malis (Ascom Timeplex, Inc.), "Multiprotocol
Interconnect over Frame Relay", July 1993.
RFC 1491: Weider, C., Merit Network, Inc., and R. Wright,
LBL, "A Survey of Advanced Usages of X.500",
July 1993.
RFC 1492: Finseth, C., "An Access Control Protocol,
Sometimes Called TACACS", University of Minnesota,
July 1993.
RFC 1493: Decker, E. (Cisco), P. Langielle (DEC),
A. Rijsinghani (DEC), K. McCloghrie, Hughes LAN
Systems, Inc., "Definitions of Managed Objects for
Bridges", July 1993.
Ann Cooper (Cooper at ISI.EDU)
Cooper [Page 28]
Internet Monthly Report July 1993
MULTIMEDIA CONFERENCING
At the Amsterdam IETF, there were two meetings of the newly created
WG on Multiparty Multimedia Session Control (MMusic). This
represented the first time we were able to get beyond the
groundwork and delve into the details for a strawman communications
substrate. Detailed minutes and slides may be found in
venera.isi.edu:confctrl/minutes as "ietf.7.93" and "slides.7.93.ps"
respectively.
Two channels of live audio and video were multicast from the
Amsterdam IETF meeting, the fifth such multicast. The cumulative
total of remote hosts that joined into the audio multicast was 518.
For the first time, this was slightly more than the number of
people who attended locally (approximately 490). Thanks to the
efforts of a number of people, both in Amsterdam and elsewhere
around the MBONE, to re-engineer the topology of the MBONE, this
multicast was much improved over the previous ones in that both
channels of audio and video worked to most places most of the week.
However, the quality was often "listenable" but not "good". We
need further work on performance monitoring so we can find and fix
bottlenecks.
During July, the IETF AVT working group discussed via email how
transport-layer demultiplexing should be done in the Realtime
Transport Protocol (RTP). The results of this discussion, and some
revisions to the protocol options for security, were incorporated
by Henning Schulzrinne into a new Internet Draft of the spec,
dubbed the "next-to-last call" within the working group.
Steve Casner, Eve Schooler (casner at ISI.EDU, schooler at ISI.EDU)
JVNCNET
-------
JvNCnet-Global Enterprise Services, Inc.
3 Independence Way
Princeton, NJ 08540
1-800-35-TIGER
I. New Information
GES has moved to a new location at the Princeton Corporate
Center. (Address above).
Main number is (609) 897-7300; fax (609) 897-7310.
Network operations center (NOC) telephone numbers are:
(609) 897-7318, 897-7319, and 897-7320.
Cooper [Page 29]
Internet Monthly Report July 1993
II. Symposia Series (open to the public)
A. Internet Information Services and Implementation
Procedures
Date: September 9, 1993
Location: Princeton Marriott Forrestal Village,
Plainsboro, NJ
Audience: Network information systems specialists,
computer consultants, and network technical
staff including system managers of TCP/IP-
based networks responsible for managing an
Internet connection and installing network
services. Additionally, those who will
manage a new Internet system or anyone new
to the Internet who is interested in
learning about internet information
services will benefit from attendance.
Speakers include: Mark Lindner (gopher), Alan
Emtage (archie), and Jim Fullton (WAIS).
Early bird special for registration by Sep. 3, 1993
JvNCnet Members.....$250; non-members.....$275.
After September 3:
JvNCnet Members.....$295; non-members.....$325
Registration and information:
Email to hammer at jvnc.net or call 609-897-7315.
B. GES has scheduled Cisco router configuration classes.
Audience: Network managers, operations staff,
technicians, and anyone involved with the
configuration and management of routing
and bridging equipment.
--Knowledge of basic routing principles, TCP/IP, or
OSI is recommended but not required.
Class location:
GES office in Princeton, NJ.
Length: Router Configuration Course is five days:
Monday - Thursday 9:00 am to 5:00 pm.
Friday - 9:00 am to 3:00 pm.
Cooper [Page 30]
Internet Monthly Report July 1993
First five-day session begins July 26-July 30.
Subsequent course dates:
August 9-13, 30-3 September
September 13-17, 27-1 October
October 11-15
November 1-5, 15-19, 29-3 December
December 13-17
Request course outline, price, and other details
from instructor Steven Williams at:
(609) 897-7314 or
email to williams at jvnc.net
by Rochelle Hammer (hammer at jvnc.net)
MERIT/MICHNET
-------------
As members of the IETF working group NASREQ, MichNet engineers John
Vollbrecht, Allan Rubens, Glenn McGregor, Larry Blunk and Richard
Conto have published the internet draft "Network Access Server
Proposed Requirements Document" (draft-ietf-nasreq-
nasrequirements-01.txt). This document focuses on issues of
authentication, authorization and accounting support for the
Network Access Server (NAS) in its role of providing access to a
wide range of environments.
After an initial review of vendors and their available products,
Merit chose to work with Livingston in implementing a pilot NAS
supporting MichNet requirements of authentication, common user
interface, and a means by which to track patterns of network use.
Beta test of the Livingston Portmaster at the University of
Michigan MichNet site has begun, with initial indications of
superior performance for PPP and SLIP access. Network Access
Servers will ultimately be deployed throughout the MichNet
backbone, providing state-of-the-art network access to users around
the state.
As announced earlier, use of SLIP (Serial Line Internet Protocol)
and SLFP (Serial Line Framing Protocol) are now restricted to basic
TCP/IP service, ftp, telnet, finger, and Quote of the Day, on
MichNet public ports. Unrestricted access requires the use of PPP
(Point-to-Point Protocol) and authorization for a full service
connection. MichNet is encouraging serial TCP/IP users to move to
PPP, a true Internet standard and a newer protocol offering better
performance and authorization for access to some services.
Cooper [Page 31]
Internet Monthly Report July 1993
The Michigan Molecular Institute (MMI) is the most recent MichNet
affiliate. Providing graduate level courses in polymer science in
conjunction with several Michigan colleges and universities, the
Institute is involved in advanced research and the development of
polymers and polymer composites.
Jo Ann Ward (jaw at merit.edu)
MERIT/NSFNET ENGINEERING
------------------------
This report is a summary of the major activities carried out by
Merit's Internet Engineering Group during the period of June and
July of 1993, which included: improvement of the NSFNET
configuration process; routing coordination for the Russian
networks; organizing the NSFNET regional tech meeting;
participation and organizing of several IETF working group
meetings; and progress on implementation of IDRP.
I. Improvement of the NSFNET configuration process
The number of networks configured (and requested to be
configured) for the NSFNET backbone continue to increase
rapidly, with an average monthly growth rate of 7-10%. To keep
pace with the work load, we have continued to improve the NSFNET
configuration process. We have made major progress in that area
and significant improvement in efficiency has been achieved.
(1) Use of powerful UNIX tools:
As our migration from the mainframe-based database to UNIX-based
relational database was completed in the first quarter of this
year, more readily available and powerful UNIX tools have been
used to facilitate the configuration tasks, including tracking
of configuration requests (e.g., use "mh", "diff", and "fgrep"
to quickly group related requests and eliminate duplicate
requests), deployment of configuration files (e.g., "rcp" or
"rdist"), and automated acknowledgement for configuration
requests (by use of "mh" scripts).
(2) Streamlined process for non-US requests:
Now that the registration process for non-US nets no longer
requires a confirmation step (in most cases) from NSF or from
foriegn reps, Merit has implemented a set of streamlined
procedure for accepting and configuring non-US networks. The
current policy is that a NACR for non-US networks may be
submitted directly to nsfnet-admin at merit.edu by an authorized
Cooper [Page 32]
Internet Monthly Report July 1993
person of a NSFNET midlevel/regional. This procedure has helped
to expedite configuration processing of non-US nets.
(3) Adoption of NACR 7.0:
To allow for a more efficient and scalable approach, a version
of machine parsable "network announcement change request" (NACR)
template was adopted in June, 1993. This version of NACR is
simpler, and easier to fill out, than previously versions. A new
field called "home AS" has been added to this new version and
this information will be made available to the Internet
community. More importantly, it is machine parsable and can be
generated by the auto-NACR program (see (4)).
We recently announced that a block of consecutive Class C
addresses may be submitted on one NACR to further facilitate the
NACR submission process. The transition from older NACR versions
to the new NACR 7.0 was smooth and has been successfully
completed. The cooperation from the NSFNET regionals in this
transition has been excellent. The new NACR template and
instructions are available from nic.merit.edu:
nsfnet/announced.networks/template.net.README
nsfnet/announced.networks/template.net
(4) Auto-NACR Program:
To enhance data validation and to facilitate the submission of
NACRs, a program called Auto-NACR (or NACR Server) was developed
and deployed in May. A designated person of NSFNET regionals may
connect with the program to submit a NACR. The NACR Server
program is curser driven with extensive on-line help. It checks
the InterNic "whois" information and the Merit's PRDB to fill in
some information, and it validates many fields in real time. A
NACR in the electronic mail format will be generated and
delivered to all related AS's once all the fields on NACR have
been properly filled in.
(5) Enhancement of NACR parser:
The work on enhancing the Lex-based NACR parser has been
completed. We have added more effective NACR validations to
catch inconsistencies and the parser is more flexible and can
handle more NACR variations.
(6) Automation of "whois" check:
For all configuration requests, the network and orgnization
information is validated with the InterNic "whois" information
Cooper [Page 33]
Internet Monthly Report July 1993
before the network is configured. The process of the InterNic
"whois" validation has been partially automated. The work load
on this part has been reduced substantially. We also expect that
this automation would help us to catch typos and other types of
errors and inconsistencies more easily.
II. Routing Coordination for Russian networks
Up until June 1993, announcements of Russian networks to the
NSFNET/ANSnet backbone were not accepted. Merit coordinated with
NSF and ANS on the planning and implementation of routing of
traffic to and from Russian networks on the ANS backbone. The
plan allows announcements of Russian networks to be accepted,
but only for the purposes of communication with ANS's customers.
Traffic to and from Russia will not be carried by the shared
NSFNET Backbone Services. In particular, Russian traffic will
not be passed to other federal agency networks. Russian networks
have been configured on the NSFNET/ANSnet backbone according to
this routing implementation plan.
(1) The "no-install" feature of the rcp_routed allows
configuration of specific networks neither to be advertised to
any peer nor installed in the forwarding tables even if received
from an internal link. This feature has been used at the
following sites to actively filtering traffic to and/or from
these Russian networks.
E135 San Diego, E137 Princeton, E144 FIX-West,
E145 FIX-East, E146 ARPA
All of the AS's bordering these ENSS's are NSFNET service users,
and we are actively filtering routes for them.
(2) The "no-announce" feature of the rcp_routed allows
configuration of specific networks not to be advertised to
certain peer AS's but these networks may be announced to other
peers and will be installed in the forwarding table if received
from an internal link. This feature has been used at the
following sites to disallow advertisement of these Russian
network to certain peers.
E129 Champaign, E130 Argonne, E133 Ithaca, E134 Boston,
E136 College Park, E139 Houston, E141 Boulder, E143 Seattle
All of these AS's are NSFNET service users, but the no-announce
feature (weak filtering) was used because the ENSS was shared
with CO+RE customers. These AS's should use explicit
announcements for reachability, or have some other path to the
Cooper [Page 34]
Internet Monthly Report July 1993
Russian nets.
III. NSFNET Regional Techs Meeting
A meeting of the NSFNET Regional Techs group was held June 10th
and 11th in Reston, Virginia at the headquarters of Sprint,
International. The major topics discussed at the meeting are
summarized as follows.
(1) Configuration of NSFNET for Aggregation
Steve Richardson, Merit, Dale Johnson, Merit
The session discussed what the NSFNET backbone will offer in
terms of initial support of CIDR. An overview of the process of
configuring the backbone was given by Dale Johnson, who noted
that this process will see minimal changes in moving to CIDR.
Steve Richardson presented what has since been published as RFC
1482 (by M. Knopper and S. Richardson), "Aggregation Support in
the NSFNET Policy-Based Routing Database," illustrating the
following services:
- the NSFNET will accept announcements of aggregates (coming
from CIDR-capable regional peer routers);
- the NSFNET will "aggregate by proxy" for CIDR-incapable
regional peers;
- the NSFNET will announce aggregates (from either of the
above sources) to regional peers.
Merit proposed the service of Aggregate Registry to aid
midlevel/regionals and other service providers in coordinating
CIDR aggregates and deployment. (See the RFC for details.)
(2) GATED Support of CIDR
Dennis Ferguson, ANS, Jeff Honig, Cornell
This session presented the capabilities of gated with respect to
CIDR. In particular the BGP implementation and status were
described, as well as the configuration capabilities of gated
with BGP-4.
(3) Registration Issues for IP Aggregates
Mark Knopper, Merit, Scott Williamson, Mark Kosters,
InterNIC/NSI
Cooper [Page 35]
Internet Monthly Report July 1993
The registration of aggregates into the various databases, e.g.
Merit/NSFNET, RIPE and InterNIC, requires some changes to the
way contact and organizational information is associated with
network number/name. This discussion covered the changes
necessary to the databases. The session suggests that further
discussions are necessary to further address sereval
registration issues, especially the issue of ip number
"ownership".
(4) Proposals for Representation and Sharing of Routing
Policy Information
Peter Ford
Daniel Karrenberg and Enke Chen presented an overview of RIPE-81
paper and RPDL paper, respectively. The discussion at the
meeting seemed to suggest that the "AS path" selection may not
be needed soon, but network level filtering is needed (such as
the current NSFNET policy). Also, these two representions need
to be combined. RIPE and Merit agreed to implement compatible
database access and representations such that routing registry
tools will be compatible across the two databases.
(5) Route Server Deployment
Elise Gerich, Merit, Andrew Partan, AlterNet
Deployment of route servers at the MAE-East "experimental NAP"
is taking place, and the status of this cooperative effort were
given in this session. The routing plan for each of the route
servers was covered, along with configuration issues. RIPE and
Merit are operating route servers at MAE-East, with Alternet/CIX
planning deployment of another route server.
(6) NSFNET Policy Routing Database Implementation Status
Andy Adams, Merit, Enke Chen, Merit
Andy Adams presented an overview of the design and
implementation of the Merit/NSFNET policy based routing database
system that is now being used to configure the NSFNET backbone.
Enke Chen summarized Merit's work on improving the NSFNET
configuration process, including NACR 7.0 and the NACR Server
program.
(7) NSFNET Solicitation Status
Dan Jordt, NorthWestNet
Quite a few questions were raised and discussed about the
Solicitation. Some issues were further clarified by Peter Ford
and Priscilla Huston who represented NSF. Many regional techs
Cooper [Page 36]
Internet Monthly Report July 1993
expressed concerns about the transition schedule and urged NSF
to allow adequate time for a smooth and stable transition. Peter
Ford emphasized that the NSF would do whatever it takes to
ensure a stable transition, and the NSF sincerely wecomes
suggestions.
(8) ANSNET Backbone Status Report
Jordan Becker, ANS
The T3 backbone status was covered including recent and planned
deployment of new software and hardware for the backbone
routers.
IV. IETF BGP-Deployment Working Group:
Jessica (Jie Yun) Yu chaired the BGP Deployment Working Group at
the July IETF at Amsterdam to discuss CIDR deployment. At the
meeting, the initial CIDR deployment plan and routing
aggregation rules developed at the March Network Service
Providers' CIDR meeting and Merit NSFNET Regional-Tech meetings
were discussed and enhanced.
The initial deployment plan:
Step 1. Deploy BGP4 without aggregation
Step 2. Advertise test aggregated route
Step 3. Aggregate at site level OR single policy level
whichever with a smaller block
|->Step 4.-| Understand more
|--Step 5.<- Aggregate more
Step 4 and step 5 are recursive until CIDR is fully
implemented.
Rules of Aggregation at Initial deployment stage:
o Aggregate based on manual configuration
o Proxy aggregation allowed (but agree by advertiser)
o Holes in aggregates allowed
o IGP/IBGP carry aggregation within a domain
o Coordination: bi-lateral and overall
o Aggregate Routing Registry needed
o No aggregation without informing others
o No de-aggregation
Engineers from 3com, ANS, cisco, EuropaNet, Proteon and
Wellfleet reported the status of BGP4/CIDR implementation. Some
of them have beta version software already and some of them
Cooper [Page 37]
Internet Monthly Report July 1993
project to have implementation by the beginning of the next
year. Interoperability test strategies were also discussed.
Analysis on CIDR's impact on IPv4 ROAD (Routing and Addressing)
was also discussed and a group of volunteers would produce a
paper on the subject.
See BGPDepl WG Jul IETF minutes for more detailed information.
V. IETF TUBA working group
Mark Knopper chaired two TUBA working group meetings at the
IETF, one of which was a joint meeting with the NOOP working
group and the RARE CLNS working group. Merit and ANS also
participated in the TUBA demonstration. Several TUBA hosts were
set up in Ann Arbor, including a pair of modified BSD/386
systems and a PC running NCSA Telnet.
Significant agreements resulting from the meetings included:
RIPE NCC agreed to host a routing registry for CLNP networks.
The ISO network layer standards will be released as RFCs. The
TUBA documents were recommended by the groups to go forward for
the Internet standards track.
VI. IDRP implementation status
In June Merit held a seminar for participants in the ATN
(Aeronautical Telecommunications Network), including a status
report and tutorial on our IDRP (in gated) implementation. The
IDRP implementation supports both IP and CLNP routing. It is
currently in test/debug and is available -- for experimentation
purposes only! -- on request from John Scudder or Sue Hares
(jgs at merit.edu or skh at merit.edu). We expect to make the
implementation generally available later this year.
The first year of the FAA grant for IDRP implementation was
completed, and funding has been approved for an additional 18
months. This funding has allowed Merit to join the GateD
Consortium.
Mark Knopper (mak at merit.edu)
Cooper [Page 38]
Internet Monthly Report July 1993
MERIT/NSFNET INFORMATION SERVICES
---------------------------------
Network Information Center (NIC) Profiles, a database of
information on existing NICs designed to be easily accessible via
the Internet, is available via Merit's Gopher server at
nic.merit.edu port 70, or indirectly through the international
Gopher tunnels. By default, NICs are displayed in alpha order by
commonName. X.500 search options currently include the database
attributes commonName, contactName, servicesOffered and
publicationsOffered. Still in a beta version, NIC Profiles is
subject to further refinement, with efforts especially directed
toward expanding options to a more flexible search mechanism.
NIC Profiles is a project initiated by the Network Information
Services Infrastructure (NISI) working group of the IETF. Pat
Smith, Merit Network Information Services and co-chair of NISI,
Rick Schmalgemeier and Chris Weider of Merit, and Tim Howes of the
University of Michigan were responsible for the Internet
availability of this project.
Indonesia became the newest international site with announcement to
the NSFNET backbone during July. Foreign networks now number 5,827
of the total 14,121 networks announced to the NSFNET backbone.
Growth as reflected in the number of domestic and foreign networks
having announcement to the NSFNET infrastructures, as well as
network distribution by country over the term of the NSFNET project
are available for Anonymous FTP from the host nic.merit.edu as
/nsfnet/statistics/history.netcount
and
/nsfnet/statistics/nets.by.country
respectively. These files may also be received via electronic
mail query. The message should be sent to
nis-info at nic.merit.edu
with the first line of text (not subject)
send history.netcount
A new directory on nic.merit.edu, conference.proceedings, contains
the proceedings from network related conferences. Papers presented
at the Public Access to the Internet Symposium, held at the Kennedy
School of Government on May 25 and 26, 1993, are available in the
subdirectory /conference.proceedings/harvard.pubaccess.symposium
Cooper [Page 39]
Internet Monthly Report July 1993
Other new information available on nic.merit.edu via Anonymous FTP,
e-mail query and Gopher:
The revised version of HR 1757, the National Information
Infrastructure bill introduced by Representative Boucher, courtesy
of the CPSR Internet Library. Available as
/nren/nii.1993/hr1757.txt
Result of U.S. House of Representatives vote on HR 1757, as
published on the mailing list nren-discuss at psi.com. Available as
/nren/nii.1993/hr1757.status
"Aggregation Support in the NSFNET Policy-Based Routing Database"
by Mark Knopper and Steven J. Richardson of Merit has been
published as RFC 1482. This document describes the proposed
support of route aggregation, as specified in Classless Inter-
Domain Routing (CIDR) and the BGP-4 protocol by the NSFNET Backbone
Network Service. Available as /internet/documents/rfc/rfc1482.txt
Growth as reflected in the number of computers and domain names on
the Internet as reported in the Internet Domain Survey by SRI
International. Available as /nsfnet/statistics/history.hosts
Chris Weider of the IETF WNILS working group, is proceeding with
development of the Whois++ Internet directory tool. Server code is
expected to be available for release in mid-August.
Representatives of the National Archives and Records Administration
came to Ann Arbor for a two-day intensive course on Internet tools
and resources by Merit Information Services staff. Intensive
hands-on sessions with WAIS, Gopher and X-Mosaic, were interspersed
with discussions of the issues facing information providers.
Merit staff traveled to Amsterdam, The Netherlands, to participate
in IETF proceedings and chair several working groups. Merit
Internet Engineering was represented by Mark Knopper, Sue Hares,
Jessica Yu, Laurent Joncheray and John Scudder; Dale Johnson
attended on behalf of Network Management Systems; Ellen Hoffman,
Pat Smith and Chris Weider represented the interests of Merit's
Information Services.
Ellen Hoffman and Pat Smith were invited to the Library of Congress
to speak on Internet tools and resources by the Federal Library and
Information Center Committee of the Library of Congress. The
content was designed for the audience of federal librarians from
various agencies, and included a new discussion by Hoffman,
"Publishing on the Internet," how to implement Internet tools and
design information resources for ease of use. Elise Gerich, of
Cooper [Page 40]
Internet Monthly Report July 1993
Merit Internet Engineering, spoke on IP address allocation at the
Third Russian Forum: Electronic Communication Technology of the
90's held in Moscow, Russia. Issues of Internet connectivity were
addressed by Gerich at the Russian Space Science Institute (IKI)
while in Moscow.
Jo Ann Ward (jward at merit.edu)
NEARNET (NEW ENGLAND ACADEMIC AND RESEARCH NETWORK)
---------------------------------------------------
NEARnet Membership Update
-------------------------
As of July 30, 1993, NEARnet has grown to a total of 235
member organizations.
NEARnet Transitions to BBN Technology Services, Inc.
----------------------------------------------------
On July 1, John Rugo, the NEARnet Project Manager, sent a
message announcing the NEARnet transition to several
NEARnet-specific e-mail lists. A copy of the transition
press release is available via anonymous FTP on
ftp.near.net, in the file:
docs/nearnet-transition-press-release-txt.
In his message John mentioned that BBN Technology Services
Inc. has assumed responsibility for NEARnet activities.
This is an organizational change; NEARnet services will
continue to be provided by the same staff within BBN.
NEARnet Conference Participation in July
----------------------------------------
Sean Kennedy of the NEARnet Network Analysis Group attended
the IETF in Amsterdam, July 12-16.
Alanna MacDonald <macdonal at nic.near.net>
NORTHWESTNET
------------
Representatives from US West, Pacific Bell, Bellcore, and
NYNEX spent time with NorthWestNet staff learning about the
Internet and, more specifically, about the mission, goals,
programs, and services of NorthWestNet. During their visit,
they met with project leaders at NorthWestNet member sites
Cooper [Page 41]
Internet Monthly Report July 1993
including the University of Washington, Boeing, National
Oceanic Atmospheric Agency/Pacific Marine Environmental
Labs, XKL Systems, and the Bush School. Conversations
between the groups were both stimulating and enlightening.
The visitors from Bellcore, the Regional Bell Operating
Companies and NorthWestNet agreed to meet again this autumn
to craft a standard glossary of network terminology to
facilitate future discussion and promote cooperation.
Ken Kay, executive director of the Computer Systems Policy
Project, and Karen Christensen, attorney for National Public
Radio, spent a four-day sabbatical with NorthWestNet's User
Services group learning about the Internet, its tools,
resources, and services. In particular, they focused on
applications related to government documents, civil rights,
K-12, and broadcasting. They were introduced to Gopher,
World Wide Web, WAIS, archie, Xmosaic, and Usenet along with
the standard tools of e-mail, FTP, and Telnet.
Eric Hood and Dan Jordt, director of Technical Services,
gave an invited presentation at a meeting of the Association
of Computer and Information Sciences/Engineering Departments
at Minority Institutions in Washington, D.C. This meeting
focused on the vision for Internet connectivity to minority
institutions.
New NorthWestNet member organizations during the month of
July included: Group Health Cooperative, Kalispell Regional
Hospital, Merle West Medical Center, Providence Hospital,
and George Fox College.
NorthWestNet
------------
info at nwnet.net 15400 SE 30th Place, Suite 202
Phone: (206) 562-3000 Bellevue, WA 98007
Fax: (206) 562-4822
Dr. Eric S. Hood, Executive Director
Jan Eveleth, Director of User Services
Dan L. Jordt, Director of Technical Services
Anthony Naughtin, Manager of Member Relations
by Jan Eveleth <eveleth at nwnet.net>
Cooper [Page 42]
Internet Monthly Report July 1993
PREPNET
-------
PREPnet New Members:
--------------------
Buckeye Pipe Line Co. Emmaus, PA
Law School Admission Services Newtown, PA
Hampton Township School District Allison Park, PA
Quaker Valley School District Sewickley, PA
Beaver Area School District Beaver, PA
Steel Valley School District Munhall, PA
Bethel Park School District Bethel Park, PA
Shaler Area School District Glenshaw, PA
Crawford Central School District Meadville, PA
With these new additions, PREPnet has a current total of 133
members.
PREPnet News:
-------------
On July 27, PREPnet conducted a training session for
Allegheny Intermediate Unit (Pittsburgh, PA). Topics
covered by the session included:
* Introduction to the Internet and PREPnet
* TCP/IP protocol suite
* Extended services and Internet utilities
For information regarding connectivity options in the
Commonwealth of Pennsylvania, contact the PREPnet NIC:
305 S. Craig St. E-Mail: nic at prep.net
2nd Floor Telephone: (412) 268-7870
Pittsburgh, PA 15213
PREPnet NIC (prepnet+ at andrew.cmu.edu)
UCL
----
The MICE demonstration at the Internet Engineering Task Force
(IETF) at the RAI Conference Centre, Amsterdam, July 11-16 1993
Mark Handley, Angela Sasse, Stuart Clayman, Atanu Ghosh, Peter
Kirstein and Tony Ballardie attended. Jon Crowcroft and a cast of
several jugglers attended virtually from London.
Cooper [Page 43]
Internet Monthly Report July 1993
Mice demonstrated:
the Conference Multiplexing and Management Centre (CMMC)
interworking between hardware codecs, software codecs and
ISDN codecs
interworking between conference rooms and workstations
integration of multi-way shared workspace applications
interworking with both European and US sites.
Sites involved were:
UCL (London) - Conference Room, CMMC
Amsterdam, Terminal Room at the IETF, RAI
GMD Conference room, Darmstadt
RUS, Stuttgart
University of Oslo
Norwegian Telecom Research
Lawrence Berkeley Labs, California
Univ. of Hawaii (Sunrise only:-)
This software allows an H221/H261 serial line codec, such as are
currently available in many organisations videoconferencing suites,
to be used over unreliable packet networks. It removes the H.221
protocol and the accompanying error correction codes in software,
ready from transmission using RTP, and reinserts H.221 and the CRC
at the receiver and pads the stream to achieve a valid synchronous
fixed bit rate stream despite damage caused by packet loss. If is a
key building block of the CMMC, and will be integral to the
reference conference room. It should be noted that generating the
CRC in software is expensive, and is the most limiting factor in
determining the data rate supportable with a particular
workstation. For instance, the current limit for a SparcStation 2
(as used at GMD) is around 192Kb/s for a full duplex link. Further
work will improve the situation a little, but being able to disable
the CRC checking in the codec would greatly alleviate this problem
This software is still under development, but the version exhibited
proved to be exceptionally stable. The links between London,
Amsterdam and GMD stayed up for a number of days continuously, with
the codecs never losing synchronisation due to packet loss. This
software was successfully also used to interface the CMMC to
software codecs using the INRIA IVS software, so that a number of
sites without hardware codecs, such as Van Jacobson in California
and the Univerisity of Hawaii, could communicate with a conference
(London-Amsterdam-GMD) ran at much higher frame rates than software
codecs can currently support.
The end-to-end delay experienced between London and Amsterdam was
around 1.5 seconds, and was considered to be usable. The end-to-end
delay experienced from GMD was considerably larger, but as less
Cooper [Page 44]
Internet Monthly Report July 1993
time had been spent on configuring this link, and an older version
of the software was in use. Currently a number of parameters in
the software are manually configurable. As we gain experience with
their configuration, we can expect to reduce these delays further.
There is however a tradeoff between stability and minimum delay,
and for demonstration purposes we chose to opt for maximum
stability. As we better understand the complex interactions
involved, much of this configuration will be performed
automatically, thus reducing the delays without sacrificing
stability.
This software currently has to manually ran at both sending and
receiving sites, although it can be run remotely, for example the
Amsterdam, the GMD and the three UCL CMMC codecs were all
controlled from Amsterdam for some of the time, along with the
video switch at UCL. As the CMMC develops, the need for manual
intervention will be reduced, as the codec control systems are
integrated into higher level conference control software.
Inria Videoconferencing System (IVS) (used at Amsterdam (2nd video
channel), RUS, Oslo, LBL, Hawaii): This is a software
implementation of an H.261 video codec. It was demonstrated at
JENC, and has been documented extensively. However, this is the
first we have demonstrated the interworking of software and high
performance hardware codecs, so the sites without full conferencing
rooms can participate in this sort of conference.
The end-to-end delays experiences by sites with software codecs
communicating with the hardware codecs of the CMMC varied
enormously depending of the load on the machine involved. On an
otherwise unloaded SparcStation 10 in Amsterdam, the delay between
the video received on the hardware codec and that received on the
workstation was less than one second. However it was noted that if
the processing power to decode the video exceeds that available,
network input buffers to IVS start to fill up and the delay
increases enormously. Clearly this isn't a problem when IVS sends
to and IVS on a similar machine, and thus this effect hasn't
emerged before. However a small amount of experimentation and
tuning should greatly reduce this effect.
The version of IVS used in the demonstration was slightly modified
to achieve compatibility with the UCL codec software. This was due
to the version of the network protocol implemented by UCL being
slightly older than that implemented by INRIA. This was known well
before the demonstration, and did not prove to be a problem, but
will be resolved as soon as possible.
Cooper [Page 45]
Internet Monthly Report July 1993
LBL Visual Audio Tool (vat) (used at all sites, and used by more
than 500 people to listen to the IETF conference itself)
We observed that problems with audio quality are not always due to
packet loss; we tried to gather statistics whenever problems with
the audio occurred, and found that in some cases, the problems were
due to local problems with microphones and speakers, or the way in
which the participants were using VAT. This highlights the
importance of making sure that the peripherals (mikes, speakers,
cameras etc.) are set up and used properly. At this stage, some
audio/visual expertise is extremely useful. Further diagnostic
tools and procedures are required, knowledge on these needs to be
pooled and made available, e.g. in the form of catalogues on what
equipment works with what other equipment instruction on how to
synchronise volume levels
Various whiteboard programs from other projects were also tested -
these will no doubt be reported elsewhere.
John Crowcroft (j.crowcroft at CS.UCL.AC.UK)
Cooper [Page 46]
Internet Monthly Report July 1993
CALENDAR
--------
Readers are requested to send in dates of events that are appropriate
for this calendar section. Please send your submissions to
(cooper at isi.edu).
1993 CALENDAR
Aug 1-6 Multimedia '93, Anaheim, CA
Aug 17-20 INET93, San Francisco,
(Request at inet93.stanford.edu)
Aug 23-27 INTEROP93, San Francisco
Dan Lynch (dlynch at interop.com)
Sep 13-17 SIGCOMM 93, San Francisco
Sep ?? 6th SDL Forum, Darmstadt
Ove Faergemand (ove at tfl.dk)
Sep 8-9 ANSI X3S3.3, Boulder, CO
Sep 13-17 OIW, NIST, Gaithersburg, MD
Sep 14 -? IFIP TC6. GMD-Fokus, 2nd Intl Conf. on
Open Distributed Processing ICODP12, Berlin
Sep 20-31 ISO/IEC JTC1/SC6, Seoul, Korea.
Sep 28-29 September RIPE Technical Days, TBC
Oct INTEROP93, Paris, France
Oct 5-6 IFIP WG 6.6 Intl Workshop on Distributed Systems:
Operations and Management DSOM'93.
Oct 12-14 Conference on Network Information Processing,
Sofia, Bulgaria; Contact: IFIP-TC6
Oct 18-22 TCOS WG, Atlanta, GA (tentative)
Nov 1-5 IETF Houston, TX.
Nov 2-4 ANSI X3S3.3, TBD
Nov 2-4 EMAIL World
Contact: Einar Steffurd <stef at nma.com>
Nov 9-13 IEEE802 Plenary, Crown Sterling Suites,
Ft. Lauderdale, FL
Nov 15-19 Supercomputing 93, Portland, OR
Dec 6-10 OIW, NIST, Gaithersburg, MD
1994 CALENDAR
Feb 3-4 ISOC Symposium on network and Distributed
System Security, San Diego, (nessett at llnl.gov)
Mar 28-Apr 1 IETF Meeting - Seattle, Washington (tentative)
May 2-6 NetWorld+INTEROP 94, Las Vegas, Nevada
Dan Lynch (dlynch at interop.com)
Jun 1-3 IFIP WG 6.5 ULPAA, Barcelona, Spain
Einar Stefferud (stef at nma.com)
Jul 25-29 IETF Meeting - Toronto, Canada (tentative)
Cooper [Page 47]
Internet Monthly Report July 1993
Aug 28-Sep 2 IFIP World Computer Congress
Hamburg, Germany; Contact: IFIP
Sep 12-14 NetWorld+INTEROP 94, Atlanta, Georgia
Dan Lynch (dlynch at interop.com)
1995 CALENDAR
Sep 18-22 INTEROP95, San Francisco, CA
Dan Lynch (dlynch at interop.com)
1996 CALENDAR
Sep 2-6 14th IFIP World Computer Congress
Canberra, Australia Contact: IFIP
========================================================================
Cooper [Page 48]
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02776;
14 Aug 93 14:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02769;
14 Aug 93 14:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa16739;
14 Aug 93 14:11 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02749;
14 Aug 93 14:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02633;
14 Aug 93 14:02 EDT
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa16399;
14 Aug 93 14:02 EDT
Received: by interlock.ans.net id AA13240
(InterLock SMTP Gateway 1.1 for ietf at CNRI.Reston.VA.US);
Sat, 14 Aug 1993 13:58:28 -0400
Received: by interlock.ans.net (Internal Mail Agent-2);
Sat, 14 Aug 1993 13:58:28 -0400
Received: by interlock.ans.net (Internal Mail Agent-1);
Sat, 14 Aug 1993 13:58:28 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Dennis Ferguson <dennis at ans.net>
Message-Id: <199308141801.AA94188 at foo.ans.net>
To: Christian Huitema <Christian.Huitema at sophia.inria.fr>
Cc: yakov at watson.ibm.com, jnc at ginger.lcs.mit.edu, ietf at CNRI.Reston.VA.US
Subject: Re: Now is the time for radical thinking...
In-Reply-To: (Your message of Fri, 13 Aug 93 08:52:34 GMT.)
<199308130852.AA04756 at mitsou.inria.fr>
Date: Sat, 14 Aug 93 14:01:30 -0500
Christian,
> The Internet is just like that water lily. Suppose we come to the point where
> all of C is allocated, and the Internet is still doubling size every year (as
> we hope it will). Just how long does it take to use a space equivalent to the
> current space of class C? Or to three times that space?
>
> Answer: one year for doubling once; two years for doubling twice...
>
> So I would say that this idea of using the class A space could give us some
> breathing space if we have not found anything better in the interval. But this
> will have a cost (all those oldies that still believe in classes). And it
> cannot be the "final answer".
I am pretty certain it is true that the number of hosts on the Internet
is doubling sort of yearly, and that if this implied that the consumption
of address space was also doubling yearly then the best we could expect
from making the entire class A space available for reassignment would be
less than two years beyond the time that the current class B and C space
is gone. The assumption I would question here is that a doubling of the
number of hosts on the Internet can only be accomodated by a doubling of
the amount of allocated address space. I would suggest that there is at
least one other way in which growth can be, and is being, accomodated,
independent of new address allocation.
As of about 10 minutes ago a poll of a router with a fairly full
Internet forwarding table produced routes to 20 class A, 3344 class B
and 7017 class C networks (this is also not a complete sample, I've
seen the forwarding table on the router a couple of hundred networks
fuller than this and routing policy often makes the view from any
particular spot on the Internet incomplete). Ignoring the class A
networks, this amount of class B+C address space is large enough
to accomodate 220 million hosts if entirely populated (i.e. 65534 hosts
per class B network, 254 hosts per class C). Yet the best estimate
we have is that the number of hosts actually attached to the Internet
is more like 2 million. This suggests that our efficiency of use of the
address space already assigned is on the order of 1%.
I hence think there is also room for improvement in the efficiency of
use of both the currently allocated, and the to-be-allocated, address
space. I think even just the back pressure applied by making address
space harder to get will help encourage this, and I think the classless
routing at the local level (e.g. allowing one to vary the size of
subnet addresses appropriately for the number of hosts on a particular
subnet) provides tools which make better efficiency easier to accomplish.
I don't know what efficiency of utilization is reasonable to expect, but
even an improvement to 10% efficiency, instead of the 1% we see now,
would be enough to accomodate between 3 and 4 years of yearly doubling
with no futher address allocation at all. Adding in the 4-or-so yearly
doublings the class-A-reclaimed address space might accomodate would hence
put the crunch out to 7 or 8 years of sustained growth, still not that far
but not so bad when you are living on a yearly-doubling exponential curve.
The only problem is that there are a lot of "I think"s in the above,
with very little in the way of quantitative evidence. And the
even bigger problem is that everyone else's articles on the topic
also have (or should have) a lot of "I think"s all over them too. We
continue to periodically have long intellectual discussions about the
merits and uncertainties of CIDR which are mostly devoid of authoritative
quantitative evidence (at least I have never seen it, I admit I do not
read everything in my mail box) derived from the CIDR-suggested changes
to our address space allocation strategy in support of any position, even
though the allocation policy has been in place for several years and the data
should be available to give us some idea of how successful this has been.
I would like to see some quantitative data, if only to help me personally
make up my mind about whether the "sky-is-falling-let's-do-something-now"
camp, or the "there's-no-crisis,-let's-wait-a-couple-of-years" camp is
likely to be closer to the mark. To restate, we have an Internet
which by our best measure has been doubling in size, in terms of things
attached to it, in periods of somewhat more than a year, fairly
consistantly for a fairly long time, and still is. We have good reason
to believe that this growth was, prior to CIDR, pretty much accomodated
entirely by address space allocation. If the CIDR allocation policies
have been at all successful we should have moved to a state where at
least some of this growth is now being accomodated by greater
efficiency, i.e. the rate of growth in assigned and utilized address
space should have dropped below the rate of growth of the Internet
as a whole. If this has indeed happened I would perhaps gain some
comfort that CIDR has given us some time to contemplate navels, but
if it has not then I would be far more tempted to join the camp that
is viewing this with suspicion.
It should be possible to evaluate this by looking at pre- and post-CIDR
address utilization data. The problem is that the only graphs of
historical data I have seen are presented with time on the X-axis
and number of networks on the Y-axis, and while these graphs suggest
the problem they are illustrating is actually getting worse post-CIDR,
the problem they are illustrating (the size of a forwarding table in
a classful router) is not particularly relevant to an evaluation of
the expected benefits of classless routing.
What I would like to see instead is the people who produce plots
of historical data to change the Y-axis on those graphs from number
of networks to, say, percent of the total allocatable address space.
In the latter units a class C network is worth 0.0000068%, a class
B network is worth 0.00174% and a class A network 0.446%. If the
CIDR allocation policies we've implemented so far are worth a damn
a log-linear plot of this data (both allocated and NSFnet-routed
address space) should show a change in slope for the better since
the introduction of CIDR-suggested allocation policies, and knowing
if this knee exists would help greatly in evaluating whether
CIDR-lovers really have something or are just talking through
their hats.
In any case, I think we'd be better off talking about real numbers
than our expectations of what the real numbers might be. I personally
don't think our consumption of address space is doubling yearly
any more, even though your note suggests you seem to. Real numbers
would help settle the issue.
Dennis Ferguson
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15291;
15 Aug 93 16:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15284;
15 Aug 93 16:04 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa25336;
15 Aug 93 16:04 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15260;
15 Aug 93 16:04 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15217;
15 Aug 93 16:01 EDT
Received: from sadye.emba.uvm.edu by CNRI.Reston.VA.US id aa25295;
15 Aug 93 16:01 EDT
Received: by sadye.emba.uvm.edu id AA16342
(5.65/1.23); Sun, 15 Aug 93 16:01:09 -0400
Date: Sun, 15 Aug 93 16:01:09 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: wollman at uvm-gen.emba.uvm.edu
Message-Id: <9308152001.AA16342 at sadye.emba.uvm.edu>
To: Craig Partridge <craig at aland.bbn.com>
Cc: Valdis Kletnieks <valdis at black-ice.cc.vt.edu>, ietf at CNRI.Reston.VA.US,
Big-Internet mailing list <big-internet at munnari.oz.au>
Subject: Re: address sizes
Reply-To: Big-Internet mailing list <big-internet at munnari.oz.au>
In-Reply-To: <9308120033.AA09964 at aland.bbn.com>
References: <9308120033.AA09964 at aland.bbn.com>
Note cross-posting! I have redirected replies to B-I...
<<On Wed, 11 Aug 93 17:33:39 -0700, Craig Partridge <craig at aland.bbn.com> said:
> One of my concerns is that folks are talking about *big* and *variable*
> length addresses as the solution. A discussion earlier this month suggested
> that while variable was OK, mixing variable sizes with potentially large
> sizes is has disturbing performance implications.
Only if you must remain wedded to the mask-and-match model. Certainly
I don't think Pip suffers from this problem; ``ordinary'' forwarding
operations will involve grabbing a single 16-bit number out of the
header, salting away the two least-significant bits, and using the
rest as a table index. I would expect that, for this ``usual'' case,
a Pip router which was optimized to the same degree as an IP router
would perform better than for IP (because mask-and-match is completely
eliminated). (Pip as other problems right now, most notably ARP.)
-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 aa25637;
16 Aug 93 8:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25630;
16 Aug 93 8:17 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa18459;
16 Aug 93 8:17 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25618;
16 Aug 93 8:17 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25559;
16 Aug 93 8:14 EDT
Received: from sics.se by CNRI.Reston.VA.US id aa18351; 16 Aug 93 8:14 EDT
Received: from hanuman.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4)
with SMTP id AA12155; Mon, 16 Aug 93 14:15:28 +0200
Message-Id: <9308161215.AA12155 at sics.se>
To: Craig Partridge <craig at aland.bbn.com>
Cc: ietf at CNRI.Reston.VA.US
Subject: Re: address sizes
In-Reply-To: Your message of "Wed, 11 Aug 1993 15:42:12 PDT."
<9308112242.AA09358 at aland.bbn.com>
Date: Mon, 16 Aug 1993 14:15:27 +0200
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Mats Brunell <matsb at sics.se>
Craig,
I have a feeling that the boarderline between this discussion and the
teleoperators discussions on a new numberingplan (yes such projects
are also running in the telephone services area) are getting rather thin.
What is a phone tomorrow? A "walkstation"?
What is a mobile computer - a extended mobile phone?
I would guess the answer depends on who you ask.
I have seen most of the requirements (and perhaps all solutions in
fractions too:-) passing. Who can come up with a proposal (which of
course will be shot down) for:
- about 3 x 10 billion units 1 unit at home, 1 at the office, on
mobile x 10 billion potential users
- support mobility
- support multiple "service providers", routes or homes
--mats
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa29556;
16 Aug 93 9:49 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21172;
16 Aug 93 9:49 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29533;
16 Aug 93 9:49 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa29395;
16 Aug 93 9:45 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-houttuin-rfc1327-tutor-04.txt, .ps
Date: Mon, 16 Aug 93 09:45:41 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308160945.aa29395 at IETF.CNRI.Reston.VA.US>
--NextPart
A Revised Internet Draft is available from the on-line Internet-Drafts
directories.
Title : A tutorial on gatewaying between X.400 and Internet mail
Author(s) : J. Houttuin
Filename : draft-houttuin-rfc1327-tutor-04.txt, .ps
Pages : 39
There are many ways in which X.400 and Internet (RFC 822) mail systems can
be interconnected. Addresses and service elements can be mapped onto each
other in different ways. From the early available gateway implementations,
one was not necessarily better than any other, but the sole fact that each
handled the mappings in a different way led to major interworking problems,
especially when a message (or address) crossed more than one gateway. The
need for one global standard on how to implement X.400 - Internet mail
gatewaying was satisfied by the Internet Request For Comments 1327,
"Mapping between X.400(1988)/ISO 10021 and RFC 822."
This tutorial was produced especially to help new gateway managers find
their way into the complicated subject of mail gatewaying according to
RFC 1327. The need for such a tutorial can be illustrated by quoting the
following discouraging paragraph from RFC 1327, chapter 1: "Warning: the
remainder of this specification is technically detailed. It will not make
sense, except in the context of RFC 822 and X.400 (1988). Do not attempt
to read this document unless you are familiar with these specifications."
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-houttuin-rfc1327-tutor-04.txt".
Or
"get draft-houttuin-rfc1327-tutor-04.ps".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-houttuin-rfc1327-tutor-04.txt".
Or
"SEND draft-houttuin-rfc1327-tutor-04.ps".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-houttuin-rfc1327-tutor-04.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-houttuin-rfc1327-tutor-04.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 aa29962;
16 Aug 93 10:01 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21672;
16 Aug 93 10:01 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa29950;
16 Aug 93 10:01 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa29433;
16 Aug 93 9:46 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at ucdavis.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-pppext-isdn-01.txt
Date: Mon, 16 Aug 93 09:46:18 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308160946.aa29433 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 Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : PPP over Circuit-Switched ISDN
Author(s) : W. Simpson
Filename : draft-ietf-pppext-isdn-01.txt
Pages : 6
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
This document describes the use of PPP over Integrated Services Digital
Network (ISDN) switched circuits.
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-pppext-isdn-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-pppext-isdn-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-pppext-isdn-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-isdn-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08779;
16 Aug 93 16:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08757;
16 Aug 93 16:53 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03890;
16 Aug 93 16:53 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08741;
16 Aug 93 16:53 EDT
Received: from sprintf.merit.edu by IETF.CNRI.Reston.VA.US id aa08591;
16 Aug 93 16:47 EDT
Received: by sprintf.merit.edu (5.64/1123-1.0-X.500)
id AA23116; Mon, 16 Aug 93 16:47:50 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: SUE.YU at sprintintl.sprint.com
Received: by sprint.com (SXG 6.0/scanf.7) with X.400
id 00gPz9gGI001; 16 Aug 93 20:46:29 UT
Date: 16 Aug 93 16:45:09-0400
To: ietf at IETF.CNRI.Reston.VA.US
Cc: SHEILA.R.KINDERMAN at sprintintl.sprint.com,
ALBERT.T.CHOU at sprintintl.sprint.com
Subject: Seeking FTP Software Info
Message-Id:
<"XGJD-5448-4154/27"*/PN=SUE.YU/O=SPRINTINTL/ADMD=TELEMAIL/C=US/@sprint.com>
Please pardon me if this is not the appropriate group to ask --
I'm looking for FTP source code for a work-related project.
We need the source code to handle reliable FTP, specifically
block mode and record structure, either with a minimal free
or free for unlimited licenses. If anyone knows of ANY site/source
for such FTP code, please inform me directly. Your help is greatly
appreciated!
Tanx in advance!
===============================================================
Sue Yu | Voice: (703) 689-6295
Alcatel Data Networks | Internet: sue.yu at sprintintl.sprint.com
===============================================================
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09219;
16 Aug 93 17:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04459;
16 Aug 93 17:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09191;
16 Aug 93 17:07 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09119;
16 Aug 93 17:05 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at ucdavis.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-pppext-hdlc-framing-01.txt
Date: Mon, 16 Aug 93 17:05:28 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308161705.aa09119 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 Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : PPP HDLC Framing
Author(s) : W. Simpson
Filename : draft-ietf-pppext-hdlc-framing-01.txt
Pages : 19
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
This document describes the use of HDLC for framing PPP encapsulated
packets.
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-pppext-hdlc-framing-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-pppext-hdlc-framing-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-pppext-hdlc-framing-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-hdlc-framing-01.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 aa09224;
16 Aug 93 17:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa04461;
16 Aug 93 17:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09193;
16 Aug 93 17:07 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09081;
16 Aug 93 17:05 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-ppp at ucdavis.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-pppext-lcpext-03.txt
Date: Mon, 16 Aug 93 17:05:06 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308161705.aa09081 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 Point-to-Point Protocol
Extensions Working Group of the IETF.
Title : PPP LCP Extensions
Author(s) : W. Simpson
Filename : draft-ietf-pppext-lcpext-03.txt
Pages : 22
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
PPP defines an extensible Link Control Protocol (LCP) for establishing,
configuring, and testing the data-link connection. This document defines
several additional LCP features which have been suggested over the past
year.
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-pppext-lcpext-03.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-pppext-lcpext-03.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-pppext-lcpext-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pppext-lcpext-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa00895;
17 Aug 93 6:57 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id ae00863;
17 Aug 93 6:57 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa01080; 17 Aug 93 5:05 EDT
Received: by bitsy.MIT.EDU
id AA14952; Tue, 17 Aug 93 04:41:15 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA14946; Tue, 17 Aug 93 04:41:14 EDT
Received: from zergo.demon.co.uk by MIT.EDU with SMTP
id AA21690; Tue, 17 Aug 93 04:40:52 EDT
Date: Mon, 16 Aug 93 16:51:57 BST
Message-Id: <115 at zergo.com>
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Leach <leach at zergo.com>
Reply-To: leach at zergo.com
To: cat-ietf at mit.edu
Subject: GSS-API
Lines: 26
X-Mailer: PCElm 3.01 (1.4 DIS)
The IETF Common Authentication Technology WG
I have a copy of the November 1992 Internet Draft of the GSS-API.
I see that the document expired on 31 May 1993, and would like to
know what has happened to the GSS-API since then. Has it been
upgraded to an RFC, is it being redrafted, and what timescales
before I can obtain a current document?
I have tried to reach John Linn on Linn at erlang.enet.dec.com but
they do not seem to know of him there. I even tried the
telephone, god forbid, but got the same response from the
Digital switchboard.
Any and as much information as you can provide would
be very much appreciated.
John Leach
--
Zergo Limited John Leach leach at zergo.com
Communications House ZZZZZZ
Winchester Road INFORMATION SECURITY Z ZZ
BASINGSTOKE CONSULTANCY ZZ
RG22 4AA SYSTEMS ZZ
Tel 0256 818800 & ZZ Z
Fax 0256 812901 PRODUCTS ZZZZZZ
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01038;
17 Aug 93 7:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01031;
17 Aug 93 7:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa03137;
17 Aug 93 7:08 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01019;
17 Aug 93 7:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa00863;
17 Aug 93 6:57 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa16424;
17 Aug 93 2:04 EDT
Received: from rodan.UU.NET by venera.isi.edu (5.65c/5.61+local-12)
id <AA09285>; Mon, 16 Aug 1993 23:05:08 -0700
Received: from relay2.UU.NET by rodan.UU.NET with SMTP
(5.61/UUNET-mail-drop) id AA10733; Tue, 17 Aug 93 02:05:06 -0400
Received: from cyberspace.com by relay2.UU.NET with SMTP
(5.61/UUNET-internet-primary) id AA26497; Tue, 17 Aug 93 02:05:02 -0400
Received: by cyberspace.com (5.67/1.37)
id AA12811; Mon, 16 Aug 93 23:05:23 -0700
To: info-ietf at uunet.uu.net
Path: cyberspace.com!not-for-mail
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Warren Victorian <warren at cyberspace.com>
Newsgroups: info.ietf
Subject: What are these?
Date: 16 Aug 1993 23:05:21 -0700
Organization: (CYBERSPACE) Public Internet 206.286.1600
Lines: 9
Message-Id: <24psf1$cg8 at cyberspace.com>
Cc:
I found these wierd international phone sex lines in a magazine the
otherday and I was just wondering how these people can offer a service
like this for free. It makes no sence to me. Anyways it is pretty hardcore
and anyone into that type of stuff should give it a shout.
011-239-129-2618
or
011-239-129-2620
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01926;
17 Aug 93 8:27 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01918;
17 Aug 93 8:27 EDT
Received: from BITSY.MIT.EDU by CNRI.Reston.VA.US id aa05208; 17 Aug 93 8:27 EDT
Received: by bitsy.MIT.EDU
id AA17425; Tue, 17 Aug 93 08:16:45 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA17419; Tue, 17 Aug 93 08:16:44 EDT
Received: from pad-thai.aktis.com by MIT.EDU with SMTP
id AA22606; Tue, 17 Aug 93 08:16:39 EDT
Received: from gza-server.aktis.com by pad-thai.aktis.com (8.5/) with SMTP
id <IAA07188 at pad-thai.aktis.com>; Tue, 17 Aug 1993 08:17:03 -0400
Received: by gza-server.aktis.com (4.1/4.7) id AA16671; Tue, 17 Aug 93 08:17:02 EDT
Message-Id: <9308171217.AA16671 at gza-server.aktis.com>
To: leach at zergo.com
Cc: linn at gza.com, cat-ietf at mit.edu
Subject: Re: GSS-API
In-Reply-To: Your message of "Mon, 16 Aug 1993 16:51:57 -0000."
<115 at zergo.com>
Date: Tue, 17 Aug 1993 08:17:01 -0400
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: John Linn <linn at gza.com>
John,
GSS-API and I are both still alive and well. As the attached message
from June indicates, the current versions of the Internet-Drafts (more
recent than the version you were looking at) have been approved for
RFC publication and should appear as numbered RFCs shortly, following
processing by the RFC editor.
--jl
Received: from BITSY.MIT.EDU by pad-thai.aktis.com (5.67/) with SMTP
id <AA28889 at pad-thai.aktis.com>; Tue, 29 Jun 93 08:22:37 -0400
Received: by bitsy.MIT.EDU
id AA09732; Tue, 29 Jun 93 08:14:58 EDT
Received: from MIT.MIT.EDU by bitsy.MIT.EDU with SMTP
id AA09726; Tue, 29 Jun 93 08:14:56 EDT
Received: from ietf.cnri.reston.va.us by MIT.EDU with SMTP
id AA12346; Tue, 29 Jun 93 08:14:47 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa01634;
29 Jun 93 8:13 EDT
To: IETF-Announce:;@CNRI.Reston.VA.US
Cc: Jon Postel -- RFC Editor <postel at isi.edu>
Cc: Internet Architecture Board <iab at isi.edu>
Cc: cat-ietf at MIT.EDU
Cc: The Internet Engineering Steering Group <IESG at IETF.CNRI.Reston.VA.US>
From: IESG Secretary <iesg-secretary at CNRI.Reston.VA.US>
Subject: Protocol Action: Common Authentication Technology Protocols
to Proposed Standard
Date: Tue, 29 Jun 93 08:13:35 -0400
Sender: jstewart at CNRI.Reston.VA.US
Message-Id: <9306290813.aa01634 at IETF.CNRI.Reston.VA.US>
The IESG has approved the Internet-Drafts:
o "Generic Security Service Application Program Interface"
<draft-ietf-cat-genericsec-04.txt>
o "The Kerberos Network Authentication Service (V5)"
<draft-ietf-cat-kerberos-02.txt, .ps>
o "Generic Security Service API : C-bindings"
<draft-ietf-cat-secservice-02.txt>
as a Proposed Standard. This document is the product of the Common
Authentication Technology Working Group. The IESG contact person is
Stephen Crocker.
Technical Summary
The top-level GSS-API document has been reviewed by three
independent individuals, all of whom provided comments that have been
accommodated by the document's editor. The GSS-API C bindings and
Kerberos V5 specifications have also been independently reviewed.
Each of the documents has been the basis for implementation
activities.
The publication of these specifications as Internet standards should
foster widespread deployment of authentication and integrity services
in connection-oriented protocols, e.g., TELNET and FTP. By insulating
protocols from the details of the security services, the CAT approach
frees them to focus on completing their task and assures that all
protocols benefit from the availability of robust and stable security
services,i.e., each protocol need not revisit the issues.
Technical Summary of <draft-ietf-cat-genericsec-04.txt>
This Generic Security Service Application Program Interface (GSS-API)
definition provides security services to callers in a generic
fashion, supportable with a range of underlying mechanisms and
technologies and hence allowing source-level portability of
applications to different environments. This specification defines
GSS-API services and primitives at a level independent of underlying
mechanism and programming language environment, and is to be
complemented by other, related specifications:
o documents defining specific parameter bindings for particular
language environments
o documents defining token formats, protocols, and procedures to be
implemented in order to realize GSS-API services atop particular
security mechanisms
The operational paradigm in which GSS-API operates is as follows. A
typical GSS-API caller is itself a communications protocol, calling
on GSS-API in order to protect its communications with
authentication, integrity, and/or confidentiality security services.
A GSS-API caller accepts tokens provided to it by its local GSS-API
implementation and transfers the tokens to a peer on a remote system;
that peer passes the received tokens to its local GSS-API
implementation for processing. The security services available
through GSS-API in this fashion are implementable (and have been
implemented) over a range of underlying mechanisms based on
secret-key and public-key cryptographic technologies.
The GSS-API separates the operations of initializing a security
context between peers, achieving peer entity authentication, from the
operations of providing per-message data origin authentication and
data integrity protection for messages subsequently transferred in
conjunction with that context. Per-message calls provide the data
origin authentication and data integrity services and also support
selection of confidentiality services as a caller option. Additional
calls provide supportive functions to the GSS-API's users.
The GSS-API design assumes and addresses several basic goals,
including:
o Mechanism independence: The GSS-API defines an interface to
cryptographically implement strong authentication and other
security services at a generic level which is independent of
particular underlying mechanisms. For example, GSS-API-provided
services can be implemented by secret-key technologies (e.g.,
Kerberos) or public-key approaches (e.g., X.509).
o Protocol environment independence: The GSS-API is independent of
the communications protocol suites with which it is employed,
permitting use in a broad range of protocol environments. In
appropriate environments, an intermediate implementation "veneer"
which is oriented to a particular communication protocol (e.g.,
Remote Procedure Call (RPC)) may be interposed between applications
which call that protocol and the GSS-API, thereby invoking GSS-API
facilities in conjunction with that protocol's communications
invocations.
o Protocol association independence: The GSS-API's security context
construct is independent of communications protocol association
constructs. This characteristic allows a single GSS-API
implementation to be utilized by a variety of invoking protocol
modules on behalf of those modules' calling applications. GSS-API
services can also be invoked directly by applications, wholly
independent of protocol associations.
o Suitability to a range of implementation placements: GSS- API
clients are not constrained to reside within any Trusted Computing
Base (TCB) perimeter defined on a system where the GSS-API is
implemented; security services are specified in a manner suitable
to both intra-TCB and extra-TCB callers.
Technical Summary of <draft-ietf-cat-secservice-02.txt>
This draft document specifies C language bindings for the Generic
Security Service Application Program Interface (GSS-API), which is
described at a language-independent conceptual level in the preceding
draft. It has been the basis for multiple prototyping and
implementation activities, and has been refined as a result of the
experience gained.
Technical Summary of <draft-ietf-cat-kerberos-02.<txt,ps>>
This document gives an overview and specification of Version 5 of the
protocol for the Kerberos network authentication system. Version 4,
described elsewhere, is presently in production use at MIT's Project
Athena, and at other Internet sites.
Working Group Summary
The CAT Working Group was chartered to create the GSS-API
specifications and specifications for supporting mechanisms; the
current set of documents represent substantial work, working group
consensus, and have been available as Internet-Drafts since 1992. It
is recognized, and was recognized when the WG was chartered, that API
definition is an unusual activity for (traditionally
protocol-oriented) IETF WGs; the fact that this API is targeted for
consumption by IETF-standardized protocols as a means for integrating
security into those protocols provides rationale for carrying out
this work in the IETF environment. The current Kerberos V5
specification as proposed for advancement represents the culmination
of many years' implementation and specification effort. It is
expected that additional CAT mechanisms will be documented in
Internet standards-track and experimental specifications.
Protocol Quality
The documents are well-written and easy to understand.
It is the belief of the WG that this set of specifications will be
sufficient to support independent implementations, and indeed the set
has served as the basis for several prototype and development
activities. While no implementations available at this time are
wholly complete and updated to match the current document versions,
it is anticipated that advancement of the specifications to Proposed
Standards will engender broadened and intensified development
efforts.
--jl
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02091;
17 Aug 93 8:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02084;
17 Aug 93 8:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05382;
17 Aug 93 8:30 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02041;
17 Aug 93 8:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01944;
17 Aug 93 8:28 EDT
Received: from venera.isi.edu by CNRI.Reston.VA.US id aa05222;
17 Aug 93 8:28 EDT
Received: from godot.lysator.liu.se by venera.isi.edu (5.65c/5.61+local-12)
id <AA16162>; Tue, 17 Aug 1993 05:28:48 -0700
Received: from astrid.lysator.liu.se (pen at astrid.lysator.liu.se [130.236.254.156]) by godot.lysator.liu.se (8.5/8.5) with ESMTP id OAA12449; Tue, 17 Aug 1993 14:28:44 +0200
Received: from localhost (pen at localhost) by astrid.lysator.liu.se (8.5/8.5) id OAA01760; Tue, 17 Aug 1993 14:28:37 +0200
Date: Tue, 17 Aug 93 14:28:33 MET DST
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Peter Eriksson <pen at lysator.liu.se>
To: ietf at isi.edu
Subject: Standardizing/Extending the RMT (Remote MagTape) Protocol
Message-Id: <CMM.0.90.0.745590513.pen at astrid>
There are protocol in the TCP/IP suite to do remote logins, to do
file transfers, email transfer, remote printing, time syncronization,
news transfer, and much more - but as far as I know there is no standard
protocol to do remote tape device access!
Yes, there exists the 4.3BSD "rmt" protocol program but it isn't standardized
anyway (except in the source code) and it also has the problem of requireing
a remote login on the machine that have the tape device just to start the
protocol engine.
I've been working on a small program to allow me to connect to a well-known
TCP port and talk directly to the "rmt" protocol engine instead. This has
the added benefit of allowing non-UNIX systems to easily be able to provide
remote tape device access without ugly hacks in some sort of rshd/rexecd
server.
Of course the RMT protocol needs some extension to provide some kinds
of authentication of the remote users and things like that but it isn't
all that difficult to add. And there are a few other things in the RMT
protocol that needs to be fixed too.
I suppose ideally things like these should be discussed in some kind of
IETF working group or so. Anybody else but me that is interrested in
this issue? (How do one go about to create an IETF working group?
I've tried reading RFC's until my eyes started bleeding but...)
Attached below is my first attempt at an RMT protocol specification
which tries to follow the way the RMT protocol is implemented in the
4.3BSD "/etc/rmt" program.
(The "XXX" port number should be replaced with a well known TCP port
below 1024)
/Peter
------------------------------ CUT - HERE ------------------------------
Remote MT Protocol
Peter Eriksson <pen at lysator.liu.se>
16 Aug 1993
Status of this Memo
This document attempts to define a protocol for the Internet
community, and requests discussion and suggestions for improvements.
Distribution of this memo is unlimited.
1. INTRODUCTION
The Remote MT Protocol (a.k.a., "rmt", a.k.a., the "RMT Protocol")
provides a means for users to access remote tape devices without
requiring them to login on the remote machine.
The protocol described in this document is the same as used by the
"rmt" Unix program, with the addition of a well known port to which
remote users can connect to get RMT service. Authentication of
remote users is NOT handled by this protocol in this version.
2. OVERVIEW
This is a connection based application on TCP. A server listens for
TCP connections on TCP port XXX (decimal). Once a connection is
established, the servers reads lines of data which specifies the
commands for manipulation of the magnetic tapes, performs the
commands and then responds with a status indication. All command
and reply codes are in ASCII.
3. NOTATIONAL CONVENTIONS
In the protocol description that follows below the following
notational conventions are used:
<....> Denotes a field of information.
[....] Denotes that what is contained within the
brackets is optional and may or may not be
present.
\n Denotes an ASCII LineFeed (LF, code 10 (decimal))
character.
4. BASIC QUERY/RESPONSE FORMAT
The server accepts simple one-letter ASCII commands (with
optional arguments) of the form:
<command-letter>[<opt-arg1>\n[<opt-arg2>\n][<opt-data]]
where <opt-arg1> and <opt-arg2> are ASCII decimal number, and
<opt-data> is a sequence of bytes. If an unknown <command-letter>
is received the server will drop the connection without returning
an error reply. Some examples:
O/dev/rmt8\n0\n
L100\n1\n
R5\n
All responses are in ASCII and in one of two forms. Successful
commands have responses of:
A<retval>\n[<opt-data>]
where <retval> is the ASCII representation of a decimal number,
and [<opt-data>] may or may not be present, depending on the
command this is a reply to. For example:
A5\nHELLO
A3\n
Unsuccessful commands are responded to with:
E<error-number>\n<error-message>\n
where <error-number> is a system dependant error number,
and <error-message> is a corresponding ASCII error message
string. For example:
E2\nNo such file or directory\n
E6\nNo such device or address\n
The protocol consists of the following commands:
O<pathname>\n<mode>\n
Open the specified <pathname>. The <mode>
is an ASCII decimal value specifying the
mode for opening it. It can be one of:
0 Read-Only
1 Write-Only
2 Read-and-Write
C<pathname>\n
Close the currently open device. The
<pathname> argument is required, but
currently ignored. Client implementations
should use the same pathname as they
used in the "O" command.
L<offset>\n<whence>\n
Perform a seek on the currently open
device, if the device supports random
access. The <offset> argument is a
ASCII decimal number, whose meaning depends
on the <whence> argument. <whence> can be
one of the following:
0 Seek <offset> bytes from
the beginning of the file open
on the device.
1 Seek <offset> bytes relative
the current position.
2 Seek <offset> bytes relative
the end of the current file
open.
On a successful operation, the <retval> returned
is the new position.
W<count>\n<data>
Write <count> bytes to the currently open
device. The bytes of <data> to be written
are sent immediately after the newline (\n)
of this command. On a successful write,
the <retval> returned is the actual number
of bytes written.
R<count>\n
Read up to <count> bytes of data from the
currently open device. If the read is successful,
the <retval> is the number of bytes read and
[<opt-data>] is the actual data read.
I<operation>\n<count>\n
Perform a device control operation on the
currently open device. <operation> can be
one of:
0 Write <count> EOF marks.
1 Forward space over <count>
EOF marks.
2 Space backwards over <count>
EOF marks.
3 Forward space over <count>
records.
4 Space backwards over <count>
records.
5 Rewind. <count> is ignored.
6 Rewind and place device offline.
<count> is ignored.
S\n Return the status of the currently open device
On a successful operation, <retval> will contain
the size of the system dependant binary structure
returned in [<opt-data>].
5. SECURITY CONSIDERATIONS
This protocol contains no provisions what so ever with regard to
authenticating users using it. Currently all authentication will
have to be done outside this protocol.
6. ACKNOWLEDGEMENTS
Acknowledgement is given to Mike St. Johns, who's IDENT RFC I've
used as a sort-of basis for this document.
Acknowledgement is also given to W. Richard Stevens whose invaluable
book 'Unix Network Programming' gave insight into the RMT protocol.
Other sources for the information in this document is the 4.3BSD "rmt"
program sources and manual pages.
Author's Address
Peter Eriksson
Lysator ACS, c/o ISY
Universitetet
S-581 83 Linkvping
Sweden
Phone: +46-13-126498
EMail: pen at lysator.liu.se
------------------------------ CUT - HERE ------------------------------
Peter Eriksson pen at lysator.liu.se
Lysator Academic Computer Society ...!uunet!lysator.liu.se!pen
University of Linkvping, Sweden <Something boring>
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03213;
17 Aug 93 9:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06640;
17 Aug 93 9:09 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03147;
17 Aug 93 9:09 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02952;
17 Aug 93 9:05 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: imap at cac.washington.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-imap-imap2bis-00.txt
Date: Tue, 17 Aug 93 09:05:25 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308170905.aa02952 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 Interactive Mail Access
Protocol Working Group of the IETF.
Title : INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2bis
Author(s) : M. Crispin
Filename : draft-ietf-imap-imap2bis-00.txt
Pages : 46
Abstract not provided.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-imap-imap2bis-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-imap-imap2bis-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-imap-imap2bis-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-imap-imap2bis-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 aa03219;
17 Aug 93 9:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa06650;
17 Aug 93 9:09 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03146;
17 Aug 93 9:09 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02949;
17 Aug 93 9:05 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: hostmib at andrew.cmu.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-hostmib-resources-03.txt
Date: Tue, 17 Aug 93 09:05:21 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308170905.aa02949 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 Host Resources MIB Working
Group of the IETF.
Title : Host Resources MIB
Author(s) : Pete Grillo, Steven Waldbusser
Filename : draft-ietf-hostmib-resources-03.txt
Pages : 43
This memo defines a MIB for use with managing host systems. The term "host"
is construed to mean any computer that communicates with other similar
computers attached to the internet and that is directly used by one or more
human beings. Although this MIB does not necessarily apply to devices whose
primary function is communications services (e.g., terminal servers,
routers, bridges, monitoring equipment), such relevance is not explicitly
precluded. This MIB instruments attributes common to all internet hosts
including, for example, both personal computers and systems that run
variants of Unix.
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-hostmib-resources-03.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-hostmib-resources-03.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-hostmib-resources-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-hostmib-resources-03.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
--OtherAccess--
--NextPart--
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09040;
17 Aug 93 11:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09033;
17 Aug 93 11:14 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11076;
17 Aug 93 11:14 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09011;
17 Aug 93 11:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa08975;
17 Aug 93 11:11 EDT
Received: from ux1.cso.uiuc.edu by CNRI.Reston.VA.US id aa10997;
17 Aug 93 11:11 EDT
Received: from panix.com by ux1.cso.uiuc.edu with SMTP id AA20001
(5.67a8/IDA-1.5 for <info-ietf at ux1.cso.uiuc.edu>); Tue, 17 Aug 1993 10:11:57 -0500
Received: by panix.com id AA16616
(5.65c/IDA-1.4.4 for info-ietf at ux1.cso.uiuc.edu); Tue, 17 Aug 1993 11:12:26 -0400
To: info-ietf at ux1.cso.uiuc.edu
Path: not-for-mail
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "uh..Clem" <gordy at panix.com>
Newsgroups: info.ietf
Subject: Re: What are these?
Date: 17 Aug 1993 11:12:25 -0400
Organization: PANIX Public Access Internet and Unix, NYC
Lines: 7
Message-Id: <24qsgp$g76 at panix.com>
References: <24psf1$cg8 at cyberspace.com>
This is a "moderated" newsgroup? Then what on earth does this have
to do with the IETF? Who's minding the store, and allowing scams like this
in?
--
Gordy Thompson -=0=- Nothing is real.
gordy at panix.com -=0=- -- John Lennon
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10572;
17 Aug 93 13:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10568;
17 Aug 93 13:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15516;
17 Aug 93 13:36 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10556;
17 Aug 93 13:36 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10552;
17 Aug 93 13:36 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15511;
17 Aug 93 13:36 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10547;
17 Aug 93 13:35 EDT
To: IETF-Announce: ;
Cc: IESG <IESG at CNRI.Reston.VA.US>
cc: hostmib at andrew.cmu.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: Host Resources MIB to Proposed Standard
Date: Tue, 17 Aug 93 13:35:57 -0400
X-Orig-Sender: jstewart at CNRI.Reston.VA.US
Message-ID: <9308171335.aa10547 at IETF.CNRI.Reston.VA.US>
The IESG has received a request from the Host Resources MIB
Working Group to consider "Host Resources MIB"
<draft-ietf-hostmib-resources-03.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 31 August.
John Stewart
IESG Secretary
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13704;
17 Aug 93 15:33 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19885;
17 Aug 93 15:33 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13687;
17 Aug 93 15:33 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13589;
17 Aug 93 15:30 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19768;
17 Aug 93 15:30 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa13583;
17 Aug 93 15:30 EDT
To: IETF-Announcement: ;
Subject: IETF: MARCH '94 IETF Confirmed
Date: Tue, 17 Aug 93 15:30:36 -0400
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Megan Davies Walnut <mwalnut at CNRI.Reston.VA.US>
Message-ID: <9308171530.aa13583 at IETF.CNRI.Reston.VA.US>
Spring 1994: 29TH IETF
Seattle, Washington
NorthWestNet
Host: Dan Jordt
March 28 - April 1, 1994
Status: CONFIRMED
The IETF Secretariat is happy to announce that the 29th Internet
Engineering Task Force (IETF) meeting will be held at the Sheraton
Seattle Hotel & Towers in Seattle, Washington in March of 1994.
This information along with a listing of proposed meeting dates and sites,
is available via the remote directories (see retrieval instructions below).
In addition, information on future IETF meetings which are not yet confirmed
is also available.
FTP Access
==========
IETF Information is available by anonymous FTP from several sites.
East Coast (US) Address: ds.internic.net (198.49.45.10)
West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22)
Europe Address: nic.nordu.net (192.36.148.17)
Pacific Rim Address: munnari.oz.au (128.250.1.21)
To retrieve this information via FTP, establish an anonymous FTP
connection, then login with username ``anonymous''. Use your email
address as the password. When logged in, change to the directory of
your choice with one of the following commands:
cd ietf
Individual files can then be retrieved using the GET command:
get 0mtg-sites.txt
Future IETF Meeting Sites
Fall 1993
Houston, Texas
SESQUINET and Rice University
Host: Bill Manning
November 1-5, 1993
Status: CONFIRMED
Spring 1994
Seattle, Washington
NorthWestNet
Host: Dan Jordt
March 28 - April 1, 1994
Status: CONFIRMED
Summer 1994
Toronto, Canada
University of Toronto
Host: Warren Jackson
July 25-29, 1994
Status: TENTATIVE
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09321;
18 Aug 93 14:41 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09317;
18 Aug 93 14:41 EDT
Received: from timbuk.cray.com by CNRI.Reston.VA.US id aa19420;
18 Aug 93 14:41 EDT
Received: from hemlock.cray.com by cray.com (4.1/CRI-MX 2.19)
id AA26407; Wed, 18 Aug 93 13:42:20 CDT
Received: by hemlock.cray.com
id AA01106; 4.1/CRI-5.6; Wed, 18 Aug 93 13:42:14 CDT
Received: from cray.com (timbuk.cray.com) by hemlock.cray.com
id AA01101; 4.1/CRI-5.6; Wed, 18 Aug 93 13:42:09 CDT
Received: from MCIGATEWAY.MCIMail.com by cray.com (4.1/CRI-MX 2.19)
id AA25578; Wed, 18 Aug 93 13:30:09 CDT
Received: from mcimail.com by MCIGATEWAY.MCIMail.com id am21936;
18 Aug 93 18:12 GMT
Date: Wed, 18 Aug 93 18:16 GMT
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Robert G. Moskowitz" <0003858921 at mcimail.com>
To: Multiple recipients of list TN3270-L <TN3270-L%RUTVM1.BITNET at pucc.princeton.edu>
To: Bill Kelly <kellywh at mail.auburn.edu>
To: cvg <cvg at oc.com>
To: Multiple recipients of list TN3270E <TN3270E at list.nih.gov>
To: Multiple recipients of list IBMTCP-L <IBMTCP-L at pucc.princeton.edu>
Cc: telnet ietf <telnet-ietf at cray.com>
Cc: Megan Davies Walnut <mwalnut at CNRI.Reston.VA.US>
Subject: TN3287 technology demo
Message-Id: <45930818181654/0003858921NA2EM at mcimail.com>
TN3270E Working Group announces:
a BOF and Technology demonstration at INTEROP.
There will be a TN3287 IBM printing technology demo by several vendors
during the INTEROP show August 25 - 27 in San Francisco. The demonstration
will show implementations of the TN3270E working groups draft on TN3287
printing and LUNAME selections. Vendors demonstrating interoperable
implementations of the draft will include WRQ, DCA, ACS, and OCS. The draft
which is planned to be submitted as an Experimental RFC shortly after INTEROP
provides the capability to make TN3270 emulators capable of connecting
directly to specific IBM host Resource Names typically called LUNAMES. The
document also includes protocols to make it possible for TN3270 emulators to
attach as Printers to IBM host applications.
This technology demonstration will allow users of IBM host systems
which need 3270 printing support to be implemented on TCP/IP networks which
will make it possible for workstations running TN3270 Client Emulators to
also attach as printers at the same time, making possible direct CICS and
JES printing solutions, to local or remote workstation printing devices.
The TN3270E working group is also preparing documents on the present
TN3270 practices, and a new document which will significantly extend the
capabilities of TN3270 into the capabilites of SNA. All of the activities
will be reviewed during a BOF at INTEROP 7:30 Thursday evening.
Robert Moskowitz
Chrysler Corporation
TN3270E Working Group Chair
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09634;
18 Aug 93 15:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09627;
18 Aug 93 15:11 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa20339;
18 Aug 93 15:11 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09612;
18 Aug 93 15:11 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa09519;
18 Aug 93 15:00 EDT
Received: from apple.com by CNRI.Reston.VA.US id aa20093; 18 Aug 93 15:00 EDT
Received: by apple.com with SMTP (5.61/19-Jul-1993-eef)
id AA26423; Wed, 18 Aug 93 12:01:23 -0700
for 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: "Erik E. Fair" (Your Friendly Postmaster) <fair at apple.com>
Subject: IP address traceability
To: ietf at CNRI.Reston.VA.US
Date: Wed, 18 Aug 93 12:01:19 -0700
Message-Id: <26413.745700479 at apple.com>
X-Orig-Sender: fair at apple.com
When the Internet was small and collegial, we could and did trust each
other to do the right thing w.r.t. to system security, not spoofing
protocols, and otherwise behaving like civilized people.
The Internet is no longer small, and since it encompasses a much more
representative sample of the people of the earth, we've got some less
than benevolent people online, along with everyone else.
There are lots of ways to attack a host over the network, particularly
if the attacker is satisfied with denial of service. Some attacks can
be repelled with terminal defenses. However, there exist attacks which
there is no defense against, save tracing the attacker to the source,
and stopping it there.
Being able to trace attacks easily depends upon being able to assume
that the return IP address is at least correct in its network/subnet
portion, and following the routing system backward. This also assumes
that the routing system itself has not been compromised. Fortunately,
every IP network service vendor I've ever run into is extremely
conservative with his/her routing system w.r.t. what information they
will accept from particular sources - my impression is that primarily
this concern stems from a desire to keep the system stable for reliable
operation rather than security, but it has the desired effect for the
purpose of this discussion.
However, there exist a set of attacks which do not require that the
source IP address on the packets be even vaguely related to its network
of origin, because two-way communication is not necessary to the
success of the attack. For some subset of these attacks, there is no
effective host-based defense. In order to stop the attack, one must be
able to identify the attacking host, and stop the attack there.
In order to preserve traceability of an IP address in this scenario, I
propose that all IP network service providers filter their network
links to their clients, such that the clients are only allowed to
inject packets into the Internet which have an IP source address within
the known allocated IP network numbers for that client. Most
commercially available IP routers have the capability to filter IP
packets as I suggest - it is simply one more filter list to manage on a
per-client basis, like which IP network numbers they are allowed to
inject into the routing system.
It may also be fruitful to examine adding an option to IP router
requirements that they can be configured to drop packets for which
there is no explicit route to the source address in their tables. This
could be used to simplify the administration of filtering at the edges
of the Internet.
Please do not construe this missive as advocating authentication by IP
address. I eagerly await deployment of strong crypto-authentication
systems on an Internet-wide basis, so that we can trust our systems to
do things that we do not trust them to do today. However, most of the
attacks that I want to be able to trace will not require authentication
and I'm trying to suggest that we, to use a Milo Medin phrase, "harden"
the network.
Erik E. Fair apple!fair fair at apple.com
Postmaster & Internet Guy
Engineering Computer Operations
Apple Computer, Inc.
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10736;
18 Aug 93 16:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10729;
18 Aug 93 16:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa21969;
18 Aug 93 16:08 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10717;
18 Aug 93 16:08 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10692;
18 Aug 93 16:06 EDT
Received: from qualcomm.com by CNRI.Reston.VA.US id aa21928; 18 Aug 93 16:06 EDT
Received: from servo.qualcomm.com by qualcomm.com; id AA02040
sendmail 5.65/QC-main-2.1 via SMTP
Wed, 18 Aug 93 13:03:36 -0700 for ietf at CNRI.Reston.VA.US
Received: by servo; id AA00611
sendmail 5.67/QC-subsidiary-2.1
Wed, 18 Aug 93 13:07:06 -0700 for ietf at CNRI.Reston.VA.US
Date: Wed, 18 Aug 93 13:07:06 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Phil Karn <karn at qualcomm.com>
Message-Id: <9308182007.AA00611 at servo>
To: fair at apple.com
Cc: ietf at CNRI.Reston.VA.US, mobile-ip at parc.xerox.com
In-Reply-To: "Erik E. Fair" (Your Friendly Postmaster)'s message of Wed, 18 Aug 93 12:01:19 -0700 <26413.745700479 at apple.com>
Subject: IP address traceability
>In order to preserve traceability of an IP address in this scenario, I
>propose that all IP network service providers filter their network
>links to their clients, such that the clients are only allowed to
>inject packets into the Internet which have an IP source address within
>the known allocated IP network numbers for that client. Most
>commercially available IP routers have the capability to filter IP
>packets as I suggest - it is simply one more filter list to manage on a
>per-client basis, like which IP network numbers they are allowed to
>inject into the routing system.
This is completely unacceptable. First of all, it breaks mobile-IP.
All of the proposed mobile IP schemes depend on the inherent ability
of the current Internet to allow a mobile host to send packets with
the mobile's permanent IP address in the source field of the packet,
without regard for the mobile's current location within the Internet.
Requiring that packets with a given IP address be originated within
the network to which that IP address is assigned effectively mandates
"triangle routing" from the mobile host back through its home network.
Avoiding triangle routing in the other direction (fixed host to mobile
host) has been *the* subject of many hundreds of person-hours within
the IETF Mobile IP working group. Now you're recommending that we
create the same problem for the other direction, and make it
unsolvable. Unacceptable.
Second, despite your claims to the contrary, you *are* advocating
authentication by IP address. This is bogus. The solution is twofold:
first remove all implied authentication by IP address within existing
hosts, and two, speed up definition and deployment of strong
network-layer cryptographic security in the Internet. Why don't you
join the ip-sec working group and help out?
Phil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11207;
18 Aug 93 16:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11200;
18 Aug 93 16:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa22876;
18 Aug 93 16:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11185;
18 Aug 93 16:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11148;
18 Aug 93 16:27 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa22824;
18 Aug 93 16:27 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA13979; Wed, 18 Aug 93 13:27:17 -0700
Message-Id: <9308182027.AA13979 at Mordor.Stanford.EDU>
To: Phil Karn <karn at qualcomm.com>
Cc: fair at apple.com, ietf at CNRI.Reston.VA.US, mobile-ip at parc.xerox.com
Subject: Re: IP address traceability
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Wed, 18 Aug 93 13:07:06 -0700. <9308182007.AA00611 at servo>
Date: Wed, 18 Aug 93 13:27:16 -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
Phil,
How would strong crypto prevent the kind of denial-of-service
one-way attack that Erik is citing?
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11393;
18 Aug 93 16:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11386;
18 Aug 93 16:40 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa23109;
18 Aug 93 16:40 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11373;
18 Aug 93 16:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa11341;
18 Aug 93 16:38 EDT
Received: from tadpole.Tadpole.COM by CNRI.Reston.VA.US id aa23067;
18 Aug 93 16:38 EDT
Received: by tadpole.tadpole.com (4.1/SMI-4.1)
id AA27579; Wed, 18 Aug 93 15:38:53 CDT
Date: Wed, 18 Aug 93 15:38:53 CDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Jim Thompson <jim at tadpole.com>
Message-Id: <9308182038.AA27579 at tadpole.tadpole.com>
To: fair at apple.com, karn at qualcomm.com
Subject: Re: IP address traceability
Cc: ietf at CNRI.Reston.VA.US, mobile-ip at parc.xerox.com
> >In order to preserve traceability of an IP address in this scenario, I
> >propose that all IP network service providers filter their network
> >links to their clients, such that the clients are only allowed to
> >inject packets into the Internet which have an IP source address within
> >the known allocated IP network numbers for that client. Most
> >commercially available IP routers have the capability to filter IP
> >packets as I suggest - it is simply one more filter list to manage on a
> >per-client basis, like which IP network numbers they are allowed to
> >inject into the routing system.
>
> This is completely unacceptable. First of all, it breaks mobile-IP.
> All of the proposed mobile IP schemes depend on the inherent ability
> of the current Internet to allow a mobile host to send packets with
> the mobile's permanent IP address in the source field of the packet,
> without regard for the mobile's current location within the Internet.
While technically correct, shouldn't you mention that at least one
of the proposed schemes encapsulates (tunnels) the datagram inside an
IP header with a source address that Erik's proposed scheme would pass?
Jim
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12893;
18 Aug 93 18:35 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12884;
18 Aug 93 18:35 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26683;
18 Aug 93 18:34 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12871;
18 Aug 93 18:34 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12833;
18 Aug 93 18:31 EDT
Received: from qualcomm.com by CNRI.Reston.VA.US id aa26631; 18 Aug 93 18:31 EDT
Received: from servo.qualcomm.com by qualcomm.com; id AA21980
sendmail 5.65/QC-main-2.1 via SMTP
Wed, 18 Aug 93 15:29:01 -0700 for ietf at CNRI.Reston.VA.US
Received: by servo; id AA00990
sendmail 5.67/QC-subsidiary-2.1
Wed, 18 Aug 93 15:32:28 -0700 for fair at apple.com
Date: Wed, 18 Aug 93 15:32:28 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Phil Karn <karn at qualcomm.com>
Message-Id: <9308182232.AA00990 at servo>
To: dcrocker at mordor.stanford.edu
Cc: fair at apple.com, ietf at CNRI.Reston.VA.US, mobile-ip at parc.xerox.com
In-Reply-To: Dave Crocker's message of Wed, 18 Aug 93 13:27:16 -0700 <9308182027.AA13979 at Mordor.Stanford.EDU>
Subject: IP address traceability
Dave Crocker says:
>How would strong crypto prevent the kind of denial-of-service
>one-way attack that Erik is citing?
Easy. With a network layer security protocol that cryptographically
authenticates each datagram, you simply drop any incoming datagrams
that arrive without a valid authenticator before they reach the TCP
level.
Ideally this is done on each host on an end-to-end basis, but not
necessarily so; one could easily build special "border security
gateways" that accept incoming IP datagrams encapsulated inside the
network layer security protocol. The border gateway verifies the
security protocol authenticator. If it passes, it unwraps the inner IP
packet and forwards it onto the internal network.
The nice thing about this "border security gateway" is the relative
ease with which you could install it on an existing corporate network
and open up a path in the network's firewall router so it can accept
secure packets from any external site. This allows authorized users
(with valid crypto keys) to have logically direct IP connectivity to
everything on the internal network. This is something not now possible
with router firewalls, which do not discriminate much between
illegitimate and legitimate external users. Eventually, after you
install the IP security mechanism on each of your hosts, you no longer
need your router firewalls and you can take them down.
We need to standardize and deploy mechanisms like this before more
well-meaning people further hobble the Internet in the elusive quest
for security, Berlin Wall style.
Phil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12996;
18 Aug 93 18:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12989;
18 Aug 93 18:43 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa26879;
18 Aug 93 18:43 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12977;
18 Aug 93 18:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12945;
18 Aug 93 18:41 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa26840;
18 Aug 93 18:41 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA14960; Wed, 18 Aug 93 15:41:28 -0700
Message-Id: <9308182241.AA14960 at Mordor.Stanford.EDU>
To: Phil Karn <karn at qualcomm.com>
Cc: fair at apple.com, ietf at CNRI.Reston.VA.US, mobile-ip at parc.xerox.com
Subject: Re: IP address traceability
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Wed, 18 Aug 93 15:32:28 -0700. <9308182232.AA00990 at servo>
Date: Wed, 18 Aug 93 15:41:28 -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
Phil,
---- Included message:
>How would strong crypto prevent the kind of denial-of-service
>one-way attack that Erik is citing?
Easy. With a network layer security protocol that cryptographically
authenticates each datagram, you simply drop any incoming datagrams
that arrive without a valid authenticator before they reach the TCP
level.
The process of inspecting and dropping packets takes resources. To
have the recipient network (border gateway, end-system, whatever...)
have to incur this does not strike me as the right model in a
diverse world. Fundamentally, it does not sound like it is
stopping the deprivation of service attack, merely potentially
moving it to a different part of the victim's service.
I believe that Erik's suggestion also does not eliminate the attack.
But it moves it to the interface between the abuser and their
service provider. I bet the provider will detect and correct continued
occurrence quite well, then.
We need to standardize and deploy mechanisms like this before more
well-meaning people further hobble the Internet in the elusive quest
for security, Berlin Wall style.
We also need to be careful in characterizing issues and suggestions.
In the scheme of serious security, this suggestion isn't a player.
And it isn't trying to be. But between unbridled openness and
serious security, there are milder forms of "accountability". One
might characterize this as facilitating network management, rather than
attending to network security.
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13063;
18 Aug 93 18:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13056;
18 Aug 93 18:48 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27172;
18 Aug 93 18:48 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13043;
18 Aug 93 18:47 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa12768;
18 Aug 93 18:17 EDT
Received: from Valinor.Stanford.EDU by CNRI.Reston.VA.US id aa26296;
18 Aug 93 18:17 EDT
Received: by Valinor.Stanford.EDU (5.65/inc-1.0)
id AA02523; Wed, 18 Aug 93 15:18:24 -0700
Date: Wed, 18 Aug 93 15:18:24 PDT
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Vince Fuller <vaf at valinor.stanford.edu>
To: "Erik E. Fair" (Your Friendly Postmaster) <fair at apple.com>
Cc: ietf at CNRI.Reston.VA.US
Office: Spruce Hall F15, (415) 723-6860
Usmail: Pine Hall 115, Stanford, CA, 94305-4122
Subject: Re: IP address traceability
In-Reply-To: Your message of Wed, 18 Aug 93 12:01:19 -0700
Message-Id: <CMM.0.90.2.745712304.vaf at Valinor.Stanford.EDU>
In order to preserve traceability of an IP address in this scenario, I
propose that all IP network service providers filter their network
links to their clients, such that the clients are only allowed to
inject packets into the Internet which have an IP source address within
the known allocated IP network numbers for that client. Most
commercially available IP routers have the capability to filter IP
packets as I suggest - it is simply one more filter list to manage on a
per-client basis, like which IP network numbers they are allowed to
inject into the routing system.
Eric,
I thought about this one quite a long time ago but decided that it was not
feasable in all cases: consider a provider which learns many routes from a
client site. In this case, it may well be feasable to filter the routing
information but not the forwarded traffic. The problem is, of course, one of
performance - filtering routing updates is fairly low-cost, since the filter
need only be examined when a routing update is received. Filtering of forwarded
packets, on the other hand, can be very expensive, since it needs to be done in
the main part of the forwarding operation (and it's particularly expensive to
filter on source addresses, since lookups on them are typically not optimized
as for routing destinations). So, while it would be a small matter to configure
appropriate traffic filters to match the routing filters, I am concerned that
this may not be feasable for sites which posses a large number of discontiguous
networks. It probably would be a good idea to do this for simple sites, where
a single expression may be used to match all sources within the site, but even
then, I'd be leary of implementing this everywhere until the performance impact
was well known.
It may also be fruitful to examine adding an option to IP router
requirements that they can be configured to drop packets for which
there is no explicit route to the source address in their tables. This
could be used to simplify the administration of filtering at the edges
of the Internet.
I.e. "reverse-path filtering". I've heard this discussed before, and believe
that at least one router vendor may already be able to do this (though I don't
remember who), but I may have imagined that...
--Vince
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13256;
18 Aug 93 19:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13249;
18 Aug 93 19:07 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa27734;
18 Aug 93 19:07 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13235;
18 Aug 93 19:07 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13202;
18 Aug 93 19:06 EDT
Received: from apple.com by CNRI.Reston.VA.US id aa27690; 18 Aug 93 19:06 EDT
Received: by apple.com with SMTP (5.61/19-Jul-1993-eef)
id AA01949; Wed, 18 Aug 93 16:06:39 -0700
for 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: "Erik E. Fair" (Your Friendly Postmaster) <fair at apple.com>
Subject: Re: IP address traceability
In-Reply-To: <9308182241.AA14960 at Mordor.Stanford.EDU>
References: <9308182232.AA00990 at servo>
To: Dave Crocker <dcrocker at mordor.stanford.edu>
X-Return-Path: dcrocker at Mordor.Stanford.EDU
Cc: Phil Karn <karn at qualcomm.com>, ietf at CNRI.Reston.VA.US,
mobile-ip at parc.xerox.com
Date: Wed, 18 Aug 93 16:06:37 -0700
Message-Id: <1934.745715197 at apple.com>
X-Orig-Sender: fair at apple.com
Phil, believe me when I say that I believe that I am on the side of
Truth, Beauty, and The Internet Way - I want to give everyone at Apple
Computer and our associated companies desktop Internet connectivity,
so that we can participate more fully in the community.
However, my corporate masters require that I balance that desire
against protecting our computing and data resources.
We're already letting a whole lot more hang out than most places, and
we're proceeding to open up at a sometimes frightening pace - quite a
contrast with what I found when I got here five years ago: Apple was
physically secure. Internet? Oh, that's on that lone VAX over there in
the corner...
I understand that I don't get security from this. I'm waiting
patiently (along with many others, I'm sure) for the nirvana of strong
authentication. However, in the mean time, I have a network to operate.
I specifically cast this in terms of being able to trace where IP
packets are coming from as a first approximation. Investigation (and
appropriate administrative action) proceeds from there.
Clearly, if someone is determined, they can physically attack an
intermediate network link, and tell lies from there. I'm simply trying
to suggest that until crypto-nirvana comes about, that we raise the
ante a little higher for would-be liars.
Erik E. Fair apple!fair fair at apple.com
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13743;
18 Aug 93 19:54 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13736;
18 Aug 93 19:54 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa29196;
18 Aug 93 19:54 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13722;
18 Aug 93 19:53 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13686;
18 Aug 93 19:52 EDT
Received: from Mordor.Stanford.EDU by CNRI.Reston.VA.US id aa29160;
18 Aug 93 19:52 EDT
Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0)
id AA15571; Wed, 18 Aug 93 16:53:17 -0700
Message-Id: <9308182353.AA15571 at Mordor.Stanford.EDU>
To: Vince Fuller <vaf at valinor.stanford.edu>
Cc: "Erik E. Fair" (Your Friendly Postmaster) <fair at apple.com>,
ietf at CNRI.Reston.VA.US
Subject: Re: IP address traceability
Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205
In-Reply-To: Your message of Wed, 18 Aug 93 15:18:24 -0700. <CMM.0.90.2.745712304.vaf at Valinor.Stanford.EDU>
Date: Wed, 18 Aug 93 16:53:17 -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
Performance. Oh yeah. If only we didn't have to worry about that...
As an off-the-wall response to your point, I found myself
wondering about developing a diagnostic mechanism, whereby
network managers could request that routers look for a SINGLE
address pair and report where it came from. This would allow
someone to try to trace the derivation of a misbehaving datagram,
by successively querying each router back in the chain. (Each
such query would have to wait for the next bad packet to be sent,
since the router's monitoring would be transient.)
This would be a sort-of "active" traceroute.
As I said, off the wall...
d/
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14224;
18 Aug 93 21:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14217;
18 Aug 93 21:21 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02156;
18 Aug 93 21:21 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14204;
18 Aug 93 21:21 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14166;
18 Aug 93 21:19 EDT
Received: from qualcomm.com by CNRI.Reston.VA.US id aa02041; 18 Aug 93 21:19 EDT
Received: from servo.qualcomm.com by qualcomm.com; id AA15527
sendmail 5.65/QC-main-2.1 via SMTP
Wed, 18 Aug 93 18:16:24 -0700 for ietf at CNRI.Reston.VA.US
Received: by servo; id AA01451
sendmail 5.67/QC-subsidiary-2.1
Wed, 18 Aug 93 18:19:51 -0700 for fair at apple.com
Date: Wed, 18 Aug 93 18:19:51 -0700
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Phil Karn <karn at qualcomm.com>
Message-Id: <9308190119.AA01451 at servo>
To: dcrocker at mordor.stanford.edu
Cc: fair at apple.com, ietf at CNRI.Reston.VA.US, mobile-ip at parc.xerox.com
In-Reply-To: Dave Crocker's message of Wed, 18 Aug 93 15:41:28 -0700 <9308182241.AA14960 at Mordor.Stanford.EDU>
Subject: IP address traceability
>The process of inspecting and dropping packets takes resources. To
>have the recipient network (border gateway, end-system, whatever...)
>have to incur this does not strike me as the right model in a
>diverse world. Fundamentally, it does not sound like it is
>stopping the deprivation of service attack, merely potentially
>moving it to a different part of the victim's service.
Sure it takes resources to inspect packets. This is true whether you
filter on the basis of IP source addresses, or filter on the basis of
a cryptographic authenticator. Note that there are hybrid
public/private key methods that can make the the authentication of
"regular" packets quite efficient, with most of the complexity in a
key-exchange protocol that is executed only occasionally.
Now it's true that this also moves the opportunities for
denial-of-service attacks to the key-exchange protocol, but even here
it could be designed to be fairly effective at filtering out overload
attacks (e.g., authenticate each of these with a static shared
password). In any event, you're still well ahead because you've
provided some meaningful protection without permanently crippling the
utility of the network to legitimate users.
Remember that in any shared, public network, the denial-of-service
attack is perhaps the most difficult of all security threats to deal
with. In some networks (e.g., a cellular system), it's all but
impossible, so you just accept it. Even in wired networks you only
have to go out and look for those AT&T/MCI/Sprint markers above
underground fiber routes that effectively say "Attention, terrorists!
Dig Here!" Fortunately, accidental fiber cuts still far outnumber
intentional ones.
I do like your idea of a distributed packet capture feature, but to
deal with routine, non-malicious problems, not sophisticated attacks.
Network management, as you say.
Off and on, I've thought about ways of applying some of the principles
the "cypherpunks" have been using in their anonymous remailers to
providing anonymity at the IP level. Not because I want to facilitate
malicious attacks, but because I believe optional anonymity is a
socially useful feature of traditional communication systems that
ought to be preserved in the Internet. If this also happens to thwart
somebody's misguided attempt to build security roadblocks within the
Internet instead of fixing broken host security mechanisms (or adding
them in the first place), so much the better.
Phil
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14467;
18 Aug 93 21:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14460;
18 Aug 93 21:50 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa02843;
18 Aug 93 21:50 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14447;
18 Aug 93 21:50 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14418;
18 Aug 93 21:48 EDT
Received: from WLV.IIPO.GTEGSC.COM by CNRI.Reston.VA.US id aa02776;
18 Aug 93 21:48 EDT
Received: by WLV.IIPO.GTEGSC.COM (5.65/1.35)
id AA01884; Wed, 18 Aug 93 18:49:17 -0700
Date: Wed, 18 Aug 93 18:49:17 -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: <9308190149.AA01884 at WLV.IIPO.GTEGSC.COM>
To: dcrocker at mordor.stanford.edu, fair at apple.com
Subject: Re: IP address traceability
Cc: ietf at CNRI.Reston.VA.US, karn at qualcomm.com, mobile-ip at parc.xerox.com
Erik:
There are several vendors that have systems that provide the type of security
that you are describing. Their products are directed toward the DoD market-
place. They are generally available for IBM PC and clones which might limit
your management's interest in this form of security. ;-)
The products generally use the RIPSO option as part of the security mechanism
along with DNSIX labeling and Trusted Session Protocol (TSP). There are alos
router products with similar products. Some employ encryption for traversing
unclassified networks (the Internet for example).
Merton Campbell Crockett
GTE Government Systems
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01999;
19 Aug 93 8:30 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01989;
19 Aug 93 8:29 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa07665;
19 Aug 93 8:29 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01969;
19 Aug 93 8:29 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01795;
19 Aug 93 8:19 EDT
Received: from cpmx.SAIC.COM by CNRI.Reston.VA.US id aa07322; 19 Aug 93 8:19 EDT
Received: from cpqm.SAIC.COM by cpmx.saic.com id SMTP-0012c737178008879; Thu, 19 Aug 93 05:26:32 -0700
Date: 19 Aug 1993 08:23:07 U
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Scott Hilton <Scott_Hilton at cpqm.saic.com>
Subject: ATM Forum
To: ietf <ietf at CNRI.Reston.VA.US>
Message-ID: <9308190819.aa07322 at CNRI.Reston.VA.US>
Subject: Time:17:44
OFFICE MEMO ATM Forum Date:8/18/93
I am interested in joining the ATM Forum or a general ATM mailing list. Are
there suggestions on which to join and the address.
Related to the first point, are the ATM Forum specifications available for
download from an FTP server?
Thanks for your assistance,
Scott Hilton
Scott_Hilton at cpqm.saic.com
703-827-4744
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03727;
19 Aug 93 9:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03719;
19 Aug 93 9:52 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa11179;
19 Aug 93 9:52 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03694;
19 Aug 93 9:52 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa03651;
19 Aug 93 9:48 EDT
Received: from [130.85.1.4] by CNRI.Reston.VA.US id aa11040; 19 Aug 93 9:48 EDT
Received: by umbc4.umbc.edu id AA25048
(5.65c/IDA-1.4.4 for ietf at CNRI.Reston.VA.US); Thu, 19 Aug 1993 09:48:21 -0400
Date: Thu, 19 Aug 1993 09:48:21 -0400
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: "Dr. Deepinder Sidhu (CMSC)" <sidhu at umbc.edu>
Message-Id: <199308191348.AA25048 at umbc4.umbc.edu>
To: ietf at CNRI.Reston.VA.US
Subject: ATM Forum
Cc: sidhu at umbc.edu
Please add me to ATM Forum related mailing list(s). Pleae use the
following email address
sidhu at umbc.edu
Thank you.
Deepinder Sidhu
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa04804;
19 Aug 93 11:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13704;
19 Aug 93 11:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04764;
19 Aug 93 11:08 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04569;
19 Aug 93 11:00 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: iafa at cc.mcgill.ca
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-iafa-publishing-00.txt
Date: Thu, 19 Aug 93 11:00:09 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308191100.aa04569 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 Internet Anonymous FTP
Archives Working Group of the IETF.
Title : Publishing Information on the Internet with Anonymous
FTP
Author(s) : P. Deutsch, A. Emtage
Filename : draft-ietf-iafa-publishing-00.txt
Pages : 27
This document specifies a range of information that your site may wish to
make available on your Anonymous FTP Archive to the Internet user
community. Automatic archive indexing tools have been created that can
gather and index this information, thus making it easier for users to find
and access it. It also may be used by the general user community for
extracting information about the archive itself, or about material
contained on the archive.
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-iafa-publishing-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-iafa-publishing-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-iafa-publishing-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-iafa-publishing-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 aa04806;
19 Aug 93 11:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13706;
19 Aug 93 11:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04766;
19 Aug 93 11:08 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04592;
19 Aug 93 11:00 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: iafa at cc.mcgill.ca
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-iafa-templates-00.txt
Date: Thu, 19 Aug 93 11:00:49 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308191100.aa04592 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 Internet Anonymous FTP
Archives Working Group of the IETF.
Title : Data Element Templates for Internet Information Objects
Author(s) : P. Deutsch, A. Emtage
Filename : draft-ietf-iafa-templates-00.txt
Pages : 7
This document describes full definitions of templates defined in the
companion document "Publishing Information on the Internet with Anonymous
FTP" and are an initial attempt a providing a consistent naming scheme for
indexing information for Internet information "objects" such as documents,
services and site information.
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-iafa-templates-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-iafa-templates-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-iafa-templates-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-iafa-templates-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 aa04832;
19 Aug 93 11:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13725;
19 Aug 93 11:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04792;
19 Aug 93 11:08 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04655;
19 Aug 93 11:03 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: tn3270e at list.nih.gov
Sender:ietf-announce-request at IETF.CNRI.Reston.VA.US
From: Internet-Drafts at CNRI.Reston.VA.US
Reply-to: Internet-Drafts at CNRI.Reston.VA.US
Subject: ID ACTION:draft-ietf-tn3270e-enhancements-01.txt
Date: Thu, 19 Aug 93 11:03:49 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308191103.aa04655 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 Telnet TN3270 Enhancements
Working Group of the IETF.
Title : TN3270 Enhancements
Author(s) : B. Kelly
Filename : draft-ietf-tn3270e-enhancements-01.txt
Pages : 29
This document describes a protocol that more fully supports 3270 devices
than do the existing tn3270 practices. Specifically, it defines a method
of emulating both the terminal and printer members of the 3270 family of
devices via Telnet; it provides for the ability of a Telnet client to
request that it be assigned a specific device-name (also referred to as "LU
name" or "network name"); finally, it adds support for a variety of
functions such as the ATTN key, the SYSREQ key, and SNA response handling.
This protocol would be negotiated and implemented under a new Telnet Option
and would be unrelated to the Telnet 3270 Regime Option as defined in RFC
1041.
Internet-Drafts are available by anonymous FTP. Login with the
username "anonymous" and password "guest". After logging in,
Type "cd internet-drafts".
"get draft-ietf-tn3270e-enhancements-01.txt".
Internet-Drafts directories are located at:
o East Coast (US)
Address: ds.internic.net (198.49.45.10)
o West Coast (US)
Address: ftp.nisc.sri.com (192.33.33.22)
o Pacific Rim
Address: munnari.oz.au (128.250.1.21)
o Europe
Address: nic.nordu.net (192.36.148.17)
Internet-Drafts are also available by mail.
Send a message to: mail-server at nisc.sri.com. In the body type:
"SEND draft-ietf-tn3270e-enhancements-01.txt".
For questions, please mail to internet-drafts at cnri.reston.va.us.
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the Internet Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mail-server at nisc.sri.com"
Content-Type: text/plain
SEND draft-ietf-tn3270e-enhancements-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-tn3270e-enhancements-01.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 aa04858;
19 Aug 93 11:08 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa13740;
19 Aug 93 11:08 EDT
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04846;
19 Aug 93 11:08 EDT
Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04699;
19 Aug 93 11:04 EDT
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-822 at dimacs.rutgers.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-822ext-direction-00.txt
Date: Thu, 19 Aug 93 11:04:44 -0400
X-Orig-Sender: cclark at CNRI.Reston.VA.US
Message-ID: <9308191104.aa04699 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 Internet Message Extensions
Working Group of the IETF.
Title : Handling of Bi-directional Texts in MIME
Author(s) : H. Nussbacher
Filename : draft-ietf-822ext-direction-00.txt
Pages : 3
This document describes the format and syntax of the "direction"
keyword to be used with bi-directional texts in MIME.
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-822ext-direction-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-822ext-direction-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-822ext-direction-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-822ext-direction-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 aa05452;
19 Aug 93 12:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05448;
19 Aug 93 12:09 EDT
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa15563;
19 Aug 93 12:09 EDT
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05435;
19 Aug 93 12:09 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa05368;
19 Aug 93 12:07 EDT
Received: from ics.uci.edu by CNRI.Reston.VA.US id aa15514; 19 Aug 93 12:07 EDT
Received: from nma.com by q2.ics.uci.edu id ac05881; 19 Aug 93 8:46 PDT
Received: from localhost by odin.nma.com id aa18082; 19 Aug 93 8:31 PDT
To: "Robert G. Moskowitz" <0003858921 at mcimail.com>
cc: ietf <ietf at CNRI.Reston.VA.US>
Subject: Re: Now is the time for radical thinking...
In-reply-to: Your message of "Tue, 10 Aug 1993 11:23:00 GMT."
<52930810112325/0003858921NA2EM at mcimail.com>
Reply-to: Stef=ietf at nma.com
X-Orig-Sender:ietf-request at IETF.CNRI.Reston.VA.US
Sender:ietf-archive-request at IETF.CNRI.Reston.VA.US
From: Einar Stefferud <Stef=ietf at nma.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 19 Aug 1993 08:31:48 -0700
Message-ID: <18080.745774308 at odin.nma.com>
X-Orig-Sender: stef at nma.com
I want to correct an error in reference, just to keep the record straight.
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.
