The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: TCP-IP Distribution List - Archives (1990)
DOCUMENT: TCP-IP Distribution List for June 1990 (495 messages, 294957 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1990/06.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 00:35:40 GMT
From:      ddl@husc6.harvard.edu  (Dan Lanciani)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <57952@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes:
> In article <118@ultrix.uhasun.hartford.edu>, jbloom@uhasun.hartford.edu
> (Jon Bloom) writes:
> > In article <57875@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes:
> > > We also have strict standards on quality of service, and we
> > > do not wish to compromise these standards in offering less costly access,
> ...
> 	All this adds up to quite a chunk of change.  Makes UUCP look pretty
> good, eh?      :-)

	One of the reasons that UUCP does indeed look good in this comparison
is that the current structure of UUCP networks (last I looked!) still allows
a site to join the network at as low a cost and with as poor service as it
can tolerate.  In many cases, e.g., a local phone call, that service can
be pretty good and pretty cheap.
	Many regional internet service providers forbid "third party"
connections and nets-behind-nets because they see such access as depriving
them of the revenue they would obtain from a directly-connected customer.
While this may be a valid business concern, and while it has the side effect
of allowing the regional to enforce a certain quality of service, it can
preclude some interesting and potentially cost-effective (at least for the
customers) structures.
	A more standard and quantitative method of charging for internet
service, e.g., per-packet accounting (sigh), might allow the existence of
low-end sub-service providers without threatening the income of the regionals.
That is, a regional need not worry whether two customers pay for 100
packets each or one subcontractor pays for 200.  Competition could then
drive the price of service down to a point where even an individule can
afford a connection...

				Dan Lanciani
				ddl@harvard.*
-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 09:17:08 PDT
From:      art@opal.acc.com (Art Berggreen)
To:        dheeraj@cs.umd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Duplicate packets in Internet.
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Duplicate packets in Internet.
Summary: 
Expires: 
References: <24688@mimsy.umd.edu>
Sender: 
Reply-To: art@opalacc.com (Art Berggreen)
Followup-To: 
Distribution: na
Organization: Advanced Computer Communications, Santa Barbara, California
Keywords: 

In article <24688@mimsy.umd.edu> dheeraj@cs.umd.edu (Dheeraj Sanghi) writes:
>
>I wonder if people have noticed duplicate IP packets in
>any study. Is there any possibility of duplication apart
>from because of some bug in the gateway software?

The most common source would be from unneccessary transport level
retransmissions.  This is usually due to rapid build up of congestion.
This is aggravated by non adapting retransmission strategies.
The most famous situation is the "congestion collapse" first described
(I believe) by Nagle.

>Any pointers in this regard would be much appreciated.
>
>Thanks,
>
>-dheeraj
>
>--
>Dheeraj Sanghi			(h):301-794-6247	(o):301-454-1516
>Internet: dheeraj@cs.umd.edu	UUCP: uunet!mimsy!dheeraj
>If you want to judge the culture and civilization of a people you can find
>that out by the status and conditions of the women of the country. - Nehru

Art Berggreen
ACC

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 02:56:22 GMT
From:      dheeraj@mimsy.umd.edu  (Dheeraj Sanghi)
To:        tcp-ip@nic.ddn.mil
Subject:   Duplicate packets in Internet.

I wonder if people have noticed duplicate IP packets in
any study. Is there any possibility of duplication apart
from because of some bug in the gateway software?

Any pointers in this regard would be much appreciated.

Thanks,

-dheeraj

--
Dheeraj Sanghi			(h):301-794-6247	(o):301-454-1516
Internet: dheeraj@cs.umd.edu	UUCP: uunet!mimsy!dheeraj
If you want to judge the culture and civilization of a people you can find
that out by the status and conditions of the women of the country. - Nehru
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 02:57:18 GMT
From:      decvax.dec.com!ima!minya!jc@mcnc.org  (John Chambers)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dealing with systems without nameservice.
In article <9005230215.AA10732@ucbvax.Berkeley.EDU>, 08071TCP@MSU.BITNET (Doug Nelson) writes:
> From Stan Stead:
> >        We are running 4.3 BSD.  We currently use nameservice.  However,
> >a site that we wish to exchange mail and files, while connected to the
> >internet, does not use nameservice.  We can access the site by internet
> >number, but not by name.  Is there anyway to "hot-wire" an address
> >(perhaps via /etc/hosts).  Currently, the only way /etc/hosts is read
> >is if named is not running.
> 
> The real answer is for them to set up name service.  I can't think of
> any good reason for sites attached to the internet to not be running
> name service, or to find a site that can run name service for them.

Gee, I can think of several reasons off the top of my head.  For instance,
I'm working in a network testing lab in which we are constantly fiddling
with the wiring, setting up new networks for a few hours, interconnecting
them at random, changing host names and IP addresses, and all the other
things you need to do to test stuff.  It's not even vaguely reasonable
to expect a nameserver administrator to keep track of all our fiddlings,
and usually we only tell them about the couple of "main" machines that
hold the source, or where we want to send/receive mail.  The rest we take
care of by editing /etc/hosts as needed.

An example of how difficult things can be is our couple of DOS machines
with tcp/ip.  They don't have a local hosts file, and must get all addresses
from a nameserver.  The result is that tests on DOS are *much* slower, since
we must go through a nameserver, which means telnetting to the nameserver,
editing files, and all that.

Another nameserver gotcha turned up a couple of months ago, when people
decided to rename and renumber all of the "main" machines in the lab.
The nameserver had the wrong IP address (two digits interchanged) for
the mainest of the machines (the one with all the source on it), and 
it took about a month to persuade the (badly overworked) administrator
of the nameserver to correct the typo.  /etc/hosts came in very handy
during this period.

Yeah, I know, these are all pathological cases that "shouldn't happen"
to many users.  My main response to that sort of criticism is that I've
never yet worked on a machine that wasn't unusual in some major respect.
(I keep looking for one; I assume they must exist somewhere... ;-)  If
you want to get your job done, you often have to find ways around all 
the broken software, and nameservers are often broken with respect to
some subset of the machines on the network.  So you use it if you can,
and learn to live without it when you must.

-- 
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc
--
If you're not part of the solution, you're part of the precipitate.
[Kiel oni ^ci tiun diras esperante?]
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 03:28:36 GMT
From:      van-bc!sl@ucbvax.Berkeley.EDU  (Stuart Lynne)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <3103@husc6.harvard.edu> ddl@husc6.harvard.edu (Dan Lanciani) writes:
>While this may be a valid business concern, and while it has the side effect
>of allowing the regional to enforce a certain quality of service, it can
>preclude some interesting and potentially cost-effective (at least for the
>customers) structures.
>	A more standard and quantitative method of charging for internet
>service, e.g., per-packet accounting (sigh), might allow the existence of
>low-end sub-service providers without threatening the income of the regionals.

It also provides a way for people to try things out. A sys admin can hook
into van-bc for example simply by agreeing to attempt to make some donations
to help us run things. So he can hook up, usually with existing resources
and then after a few months demonstrate to management that it's a good
thing. And then get authorization to do it and make some donations.

We also see people using the uucp service for a while and then deciding to
move up into SLIP service directly into the regional network. Again if they
hadn't had the opportunity to demonstrate the usefullness of the endeavour
they might not have been able to get management approval for the more
expensive regional network connection. 

-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 Jun 90 08:35:01 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject: Re: tcp/ip services <--> decnet connectivity, help wanted
>>The easiest thing to do would be to get a DECstation 3100 (or something
>>else running Ultrix) and use the DECnet-Internet gateway software. I
>
>I also spent a long time looking for a TCP/IP implementation for RSTS.
>After giving up on that, I looked at the solution described above, i.e.
>an Ultrix VAX as a gateway.  All you need to run on it is DECnet-Ultrix.
>This automatically does conversion between DECnet protocols and TCP/IP
>protocols (according to DEC). Get DEC's "Local Area Network Solutions
>Guidebook" and read page 74.

While this sounds like an easy solution, it may not really be so.  I have a
DECstation 3100 sitting here in front of me and I can assure you that it did
not come with any of the DECNET software.  I assume DECNET is an option and
based on the cost of the box alone, if you have to pay extra for the software
too, it's an awful expensive solution.

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 10:29:58 -0400
From:      Frank Solensky <solensky%interlan.interlan.com@RELAY.CS.NET>
To:        MAINT%asntsu.asn.net@RELAY.CS.NET
Cc:        tcp-ip@NIC.DDN.MIL
Yes, it is atypical.  I've been on the list for about a year and this is the
first time someone at, shall we say, "this level" (note indiscriminate use
of "O" and "0") has posted this type of thing.
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 11:14:31 PDT
From:      postel@venera.isi.edu
To:        dheeraj@mimsy.umd.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Duplicate packets in Internet.

Dheeraj:

Just run "ping" thru any NSS.  You get back more echo-replies than
echo-requests you sent.  Somebody is duplicating something somewhere.

--jon.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
% ping lcs.mit.edu
PING lcs.mit.edu: 56 data bytes
64 bytes from 18.26.0.36: icmp_seq=0. time=499. ms
64 bytes from 18.26.0.36: icmp_seq=1. time=360. ms
64 bytes from 18.26.0.36: icmp_seq=1. time=360. ms
64 bytes from 18.26.0.36: icmp_seq=2. time=340. ms
64 bytes from 18.26.0.36: icmp_seq=3. time=320. ms
64 bytes from 18.26.0.36: icmp_seq=4. time=360. ms
64 bytes from 18.26.0.36: icmp_seq=5. time=400. ms
64 bytes from 18.26.0.36: icmp_seq=5. time=440. ms
64 bytes from 18.26.0.36: icmp_seq=6. time=339. ms
64 bytes from 18.26.0.36: icmp_seq=6. time=339. ms
64 bytes from 18.26.0.36: icmp_seq=7. time=380. ms
64 bytes from 18.26.0.36: icmp_seq=8. time=340. ms
64 bytes from 18.26.0.36: icmp_seq=9. time=340. ms
64 bytes from 18.26.0.36: icmp_seq=10. time=380. ms
64 bytes from 18.26.0.36: icmp_seq=10. time=440. ms
64 bytes from 18.26.0.36: icmp_seq=11. time=340. ms
^C
----lcs.mit.edu PING Statistics----
12 packets transmitted, 16 packets received, -33% packet loss
round-trip (ms)  min/avg/max = 320/373/499
% 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 12:16 MST
From:      JOHN BOREN <JBOREN@cc.weber.edu>
To:        TCP-IP%NIC.DDN.MIL@CORNELLC.cit.cornell.edu
Subject:   REMOVE
REMOVE me from your list. Someone else got me on it and I dont want to be

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 09:35:46 EDT
From:      Pete Hickey <PETEHIC@ACADVM1.UOTTAWA.CA>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: LanTastic NOS and TCP/IP
Lantastic is Netbios based.  Wolongong's (sp?) product should run on
it, since it can put IP on netbios.  We have a Lantastic network
and may try that soon.

=======================================================================
Pete Hickey                     | This .signature is different from my
University of Ottawa            | old one, because rules say that it
Ottawa, Ontario, CANADA         | must be changed periodically.
(613) 564-7646                  |_____________________________________
    petehic@acadvm1.uottawa.CA      PETEHIC@UOTTAWA.BITNET
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 Jun 90 12:34:51 -0400
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        ddl@husc6.harvard.edu (Dan Lanciani)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities

 	Many regional internet service providers forbid "third party"
 connections and nets-behind-nets because they see such access as depriving
 them of the revenue they would obtain from a directly-connected customer.
 While this may be a valid business concern, and while it has the side effect
 of allowing the regional to enforce a certain quality of service, it can
 preclude some interesting and potentially cost-effective (at least for the
 customers) structures.

Revenue is only one issue, there are considerations of performance,
debugging, responsability and market perception:

PERFORMANCE:
	There are cutomers who opt for 9.6-19.2 Internet connectivity,
	who don't understand why their link is unusable after they
	feed a couple fortune 500 companies with UUCP behind it, then
	potentially they want to offload their DNS to their service
	provider, which most regionals do, but why do we do it, for them or
	for the companies behind them which we have no relationship with.

DEBUGGING:
	So the MX record doesn't work, so their sendmail.cf is misconfigured
	in doing this, so the side behind them calls the service
	provider to ask questions, get help, whatever.  For the
	regionals working with each other all the time, the  RIGHT
	assumption is that everyone is carrying each other at some
	level, and that the people at the ends are paying for
	the service.  A terminus uucp connection (which is the
	norm for the problem sites), pays nothing.

RESPONSABILITY:
	Who is responsible for that uucp connection, especially when
	friend system administrator A and University B moves onto
	make some big money at Commercial company C.

MARKET PERCEPTION:
	Maybe this is the largest issue of all, without even trying
	the service quality perception of network Z can be drawn
	down by a dozen bad uucp connections who's users think
	they are on ZNet and they tell their friends about how
	it isn't reliable, doesn't work, poor performance etc...


Some organizations including PSI/PSINet throughout the US and
CERFNet throughout California have simply decided that the
real solution is to establish local dialups everywhere they
are, and provide CHEAP UUCP connections and deal with this
directly.

Marty
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 07:43:48 GMT
From:      eru!luth!sunic!mcsun!hp4nl!ecn!bernards@BLOOM-BEACON.MIT.EDU  (Marcel Bernards)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP source wanted for HP9000/340
Hello NetReaders,

I'm looking for (PD) SLIP source for HP9000/340 series running HPUX 6.5 / 7.0.

We already got SLIP stuff for BSD/SUNOS based machines, but they cannot be
ported easily on HP's. Is there someone who has it or where I can FTP
the stuff ?? 

Please E-mail

Thanx in advance

Greetings,

-- 
Marcel Bernards, UNIX & Net sysadm Netherlands Energy Research Foundation ECN
P.O. Box 1, 1755 ZG Petten, PHONE: 09 312246 4579 EARN/BITNET:ESU0130@HPEENR51 
EMAIL: bernards@ecn.nl bernards%ecn@{nluug.nl,uunet.uu.net},hp4nl!ecn!bernards
SCREAMNet : AAAAAARGHH!HUH?? : Disclaimer: "The AntiChrist is the Computer !" 
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 11:56:15 EDT
From:      jas@proteon.com (John A. Shriver)
To:        MAINT@asntsu.asn.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   trash message from usenet (BIFF)
Actually, that message came in from usenet netnews.  It appears that
is was sent to every netnews mailgroup.  Dial-up access had nothing to
do with it.  (Anyone can send mail wherever they please from an
account anywhere on the Internet, and realistically, from anywhere in
usenet as well.)

The problem is the absolute complete and total lack of any sort of
security, trackability, or accountability in the netnews system that
runs on usenet (uucp) and over nntp.  The problem is that most of the
Internet mailing lists have been "gatewayed" to netnews mailgroups.  I
don't think that this was a good thing to do.  I don't like seeing
Internet mailing lists being brought down to the low level typical of
some of the netnews mailgroups.  I'd rather the "gateways" be made one
way (out from Internet only), or even non-existent.  (One could argue
that those "gateways" violate the access rules for the Internet, since
they cannot verify that the message came from an authorized user of
the Internet.)

I realize that this would deny netnews/uucp only sites access to the
Internet mailing lists, but if their umbrella organization (usenet)
cannot maintain professional standards of behavior, then that is their
loss.  By implementing a system without accountability, they create
that risk.

Another problem due to "gatewaying" has been consistent recurring
problems with mail loops through netnews.  About once a month one or
another of the mailing lists I'm on gets into a mail loop through
netnews.

I (and others) would welcome netnews being made properly accountable
and secure.  It is not, per-se, evil, and I understand that it is
efficient.  However, not building the Received: lines may make netnews
more efficient, but this removes all vestiges of accountability.  This
is a key problem.

The TCP-IP list has been quite consitently professional in its
conduct, as have most public Internet mailing lists.  Everything
unprofessional I have seen recently was "gatewayed" in from netnews.
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 Jun 90 13:17:34 CDT
From:      MAINT@ASNTSU.asn.net
To:        jas@proteon.com
Cc:        tcp-ip@nic.ddn.mil
In-Reply-To:  jas AT proteon.com   -- Fri, 1 Jun 90 11:56:15 EDT

John has made serveral good points but I was not aware that there was any
single point of contact for internet. I guess I thought anyone with sufficient
funds could connect to the internet. I guess part of the fault lies in the
apparent fact that there is no accountability requirement for internet
connections.

In any case it seems that the problem could be partly solved by the listserv
software itself. Simply reject any messages that do not have verifiable
Received: lines built. That wouldn't stop messages to non-listserv users but
those don't get distributed to hundreds of users. If the netnews folks want
their users to access internet lists then they can build Received: lines. If
they don't care then forget leave it the way it is. This type of problem is
cured in any event.

--------------------------------------------------------------------------------
Dennis Putnam, Service Manager
Boeing Computer Services
Alabama Supercomputer Network
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 08:38:00 GMT
From:      cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!uflorida!mlb.semi.harris.com!thrush.mlb.semi.harris.com!del@tut.cis.ohio-state.edu  (Don Lewis)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dealing with systems without nameservice.
In article <386@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>In article <9005230215.AA10732@ucbvax.Berkeley.EDU>, 08071TCP@MSU.BITNET (Doug Nelson) writes:
>> From Stan Stead:
>> >        We are running 4.3 BSD.  We currently use nameservice.  However,
>> >a site that we wish to exchange mail and files, while connected to the
>> >internet, does not use nameservice.  We can access the site by internet
>> >number, but not by name.  Is there anyway to "hot-wire" an address
>> >(perhaps via /etc/hosts).  Currently, the only way /etc/hosts is read
>> >is if named is not running.
>> 
>> The real answer is for them to set up name service.  I can't think of
>> any good reason for sites attached to the internet to not be running
>> name service, or to find a site that can run name service for them.
>
>Gee, I can think of several reasons off the top of my head.  For instance,
>I'm working in a network testing lab in which we are constantly fiddling
>with the wiring, setting up new networks for a few hours, interconnecting
>them at random, changing host names and IP addresses, and all the other
>things you need to do to test stuff.  It's not even vaguely reasonable
>to expect a nameserver administrator to keep track of all our fiddlings,
>and usually we only tell them about the couple of "main" machines that
>hold the source, or where we want to send/receive mail.  The rest we take
>care of by editing /etc/hosts as needed.

You could just create a "lab" subdomain and designate one of your
local machines as the server.  That way you don't have to bother
your overworked nameserver administrator (and you contain the damage).
Editing the zone files isn't that much harder than editing /etc/hosts,
and you don't have the bother of having to propagate the /etc/hosts
around, or do you just just use IP addresses everywhere.

>
>Another nameserver gotcha turned up a couple of months ago, when people
>decided to rename and renumber all of the "main" machines in the lab.
>The nameserver had the wrong IP address (two digits interchanged) for
>the mainest of the machines (the one with all the source on it), and 
>it took about a month to persuade the (badly overworked) administrator
>of the nameserver to correct the typo.  /etc/hosts came in very handy
>during this period.

Well, what if you sent your new (incorrect) /etc/hosts out all your
friends on the internet.  How much of a bother would it be to them
to have to incorporate this into their /etc/hosts files, and then
turn around and correct it.  And how much time is someone who missed
the correction (and someone at your end) going to spend debugging the
problem a six months from now when mail won't go through.
--
Don "Truck" Lewis                      Harris Semiconductor
Internet:  del@mlb.semi.harris.com     PO Box 883   MS 62A-028
Phone:     (407) 729-5205              Melbourne, FL  32901
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 13:41:45 EDT
From:      Bob Stewart <stewart@xyplex.com>
To:        ietf@isi.edu, ietf-hosts@nnsc.nsf.net, tcp-ip@nic.ddn.mil
Subject:   Special purpose Host Requirements WG Formed
Hi,

    This is to announce the creation of an IETF working group (WG) to apply the
host requirements RFCs to special purpose hosts.  See the attached preliminary
WG charter for more information.

	Bob Stewart
	Chair, IETF Special-purpose Host Requirements WG

--------
Special-purpose Host Requirements Working Group

Chairman:

	Bob Stewart/Xyplex  rlstewart@eng.xyplex.com

First Meeting:

	August, 1990

Mailing Lists:

	General discussion:  ietf-hosts@nnsc.nsf.net
	To subscribe:        ietf-hosts-request@nnsc.nsf.net

Description of Working Group:

	The Special-purpose Host Requirements working group is chartered to
clarify application of the Host Requirements RFCs (1122 and 1123) to systems
that are technically hosts but are not intended to support general network
applications.  These special-purpose hosts include, for example, terminal
servers (a "Telnet host"), or file servers (an "FTP host" or an "NFS host").

	The Host Requirements RFCs address the typical, general-purpose system
with a variety of applications and an open development environment, and gives
only passing consideration to special-purpose hosts.  As a result, suppliers
of special-purpose hosts must bend the truth or make excuses when users
evaluate their products against the Requirements RFCs.  Users must then decide
whether such a product is in fact deficient or the requirements truely do not
apply.  This process creates work and confusion, and undermines the value of
the RFCs.  The commercial success of the Internet protocols and their use in
increasingly unsophisticated environments exacerbates the problem.

	The working group must define principles and examples for proper
functional subsets of the general-purpose host and specifically state how such
subsets affect the requirements.  The working group must determine the balance
between an exhaustive list of specific special-purpose hosts and philosphy
that remains subject to debate.  For the most part, it should be possible to
base decisions on existing experience and implementations.  The
special-purpose requirements will be stated as differences from the existing
RFCs, not replacements, and will refer rather than stand alone.

	Since they define strict subsets of the Host Requirements RFCs, the
Special-purpose Host Requirements appear to be an easier job and can be
developed and stabilized within 8-12 months.  Most of the group's business can
be conducted over the Internet through email.

Goals and Milestones:

1.  July 1990:  mailing list discussion of charter and collection of concerns.

2.  August 1990: First IETF Meeting: discussion and final approval of charter;
    discussion and agreement on approach, including models, format, level 
    and type of detail.  Make writing assignments.

3.  October 1990:  First draft document.

4.  November 1990:  Second IETF Meeting:  review first draft document, 
    determine necessary revisions.  Follow up discussion on mailing list.

5.  January 1991:  Revised document.

6.  February 1991:  Third IETF Meeting:  make document an Internet Draft.  
    Continue revisions based on comments received at meeting and over e-mail.

7.  April 1991:  Final draft document.

6.  May 1991:  Fourth IETF meeting:  review final draft and if OK, give
    to IESG for publication as RFC.

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Fri, 01 Jun 90 14:38:16 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu>
To:        Dheeraj Sanghi <dheeraj@mimsy.umd.edu>, "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>
Subject:   Re: Duplicate packets in Internet.
>I wonder if people have noticed duplicate IP packets in
>any study. Is there any possibility of duplication apart
>from because of some bug in the gateway software?

I believe the NSFNet routers (NSS's) are the (primary?) culprit.
It's not clear that this is a bug - it can happen from a link level
retransmission.  Recall that any given retransmission algorithm can
result in either duplicated data or dropped data.  In general, IP
routers will drop data, but sometimes IP packets travel over various
strange and wonderful routes.  I think that X.25 is one of those
protocols that will duplicate data rather than drop it.

Doug Nelson
Network Software Manager
Michigan State University
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 12:52:31 GMT
From:      snorkelwacker!mintaka!chaos.cs.brandeis.edu!chaos!dnb@tut.cis.ohio-state.edu  (David N. Blank)
To:        tcp-ip@nic.ddn.mil
Subject:   looking for netwatch in all the wrong places

Greetings-
  I recently attempted to ftp netwatch from watcom (as directed by a
past poster to here and/or comp.archives) but it seems to be an
incomplete package.  There is no setup doc, despite the setup program
"config".  Could a kind soul out there point me to a more complete source of
documentation for the package that would give me a clue on how to
make this puppy work?  Thanks muchly in advance.
         Peace,
            dNb
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 17:12:22 EDT
From:      fks@vax.ftp.com (Frances Selkirk)
To:        MAINT@asntsu.asn.net, jas@proteon.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  trash message from usenet (BIFF)
The proper thing to do with babble is ignore it. The discussion about
one juvenile message has multiplied the wasted bandwith by six.

							(IMHO, oc.)

								-Frances

(Speaking for myself.)
-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 13:35:01 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: Re: tcp/ip services <--> decnet connectivity, help wanted
>>The easiest thing to do would be to get a DECstation 3100 (or something
>>else running Ultrix) and use the DECnet-Internet gateway software. I
>
>I also spent a long time looking for a TCP/IP implementation for RSTS.
>After giving up on that, I looked at the solution described above, i.e.
>an Ultrix VAX as a gateway.  All you need to run on it is DECnet-Ultrix.
>This automatically does conversion between DECnet protocols and TCP/IP
>protocols (according to DEC). Get DEC's "Local Area Network Solutions
>Guidebook" and read page 74.

While this sounds like an easy solution, it may not really be so.  I have a
DECstation 3100 sitting here in front of me and I can assure you that it did
not come with any of the DECNET software.  I assume DECNET is an option and
based on the cost of the box alone, if you have to pay extra for the software
too, it's an awful expensive solution.

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 18:35:33 EDT
From:      stev@vax.ftp.com
To:        MAINT@ASNTSU.asn.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   unauthorized hacking
"an unauthorized hacker"


my, what an interesting term. . . . . 

> Can I assume this is atypical of this list?

in general, tcp-ip seems pretty good in the light to heat index.


stev knowles
authorized hacker,
ftp software
stev@ftp.com


-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 16:17:10 GMT
From:      eplrx7!cristy@louie.udel.edu  (John Cristy)
To:        tcp-ip@nic.ddn.mil
Subject:   Unisys A-Series to Unix WorkStation Connectivity

  I need either a TCP/IP or BNA network solution that can connect a Unisys 
  A-Series to a Unix workstation (Sun, Dec 3100, etc).  Please Email
  recommendations to cristy@dupont.com.  Thanks in advance.
--
The UUCP Mailer
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 17:17:18 GMT
From:      kmeyer@decwrl.dec.com  (Kraig Meyer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: toll restrictors

||Andrew Heybey wrote:
||> ...on a unix system, telnet is a user program that opens a 
||> socket....Does your system not allow unprivilidged users to 
||> open network connections?  Are you relying on nobody knowing 
||> how to write/compile/etc their own program to use the net?  Or 
||> does your system have some other mechanism for controlling 
||> network access?

In article <@ocdis01.af.mil> robjohn@OCDIS01.AF.MIL (Robert Johnson) writes:
||...By 'turn off', I mean we change permissions so only a trusted group 
||of individuals can use it - not the user population at large.  We protect 
||telnet, ftp, cu, tip, and the compilers and debuggers this way.  We also 
||have daily reports showing who is using these functions...[this] maintains 
||full accountability of our connectivity with other systems.

Bob, I'm still curious whether the operating system you are using actually 
has a way of preventing a user from opening his or her own network connection.
Under unix and many other OS, opening a network connection does not require
any special privileges.  On such a system, taking away a user's ability to 
run your copy of telnet, ftp, etc. does not take away a user's ability to 
telnet, ftp, etc. by using his or her own program.

*****************************************************************************
Kraig Meyer                                                kmeyer@wrl.dec.com
On parole from the University of Southern California.     All views expressed
are my own and may or may not be the same as those of Digital Equipment Corp.
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 18:17:34 GMT
From:      MAINT@ASNTSU.ASN.NET
To:        comp.protocols.tcp-ip
Subject:   (none)

In-Reply-To:  jas AT proteon.com   -- Fri, 1 Jun 90 11:56:15 EDT

John has made serveral good points but I was not aware that there was any
single point of contact for internet. I guess I thought anyone with sufficient
funds could connect to the internet. I guess part of the fault lies in the
apparent fact that there is no accountability requirement for internet
connections.

In any case it seems that the problem could be partly solved by the listserv
software itself. Simply reject any messages that do not have verifiable
Received: lines built. That wouldn't stop messages to non-listserv users but
those don't get distributed to hundreds of users. If the netnews folks want
their users to access internet lists then they can build Received: lines. If
they don't care then forget leave it the way it is. This type of problem is
cured in any event.

--------------------------------------------------------------------------------
Dennis Putnam, Service Manager
Boeing Computer Services
Alabama Supercomputer Network

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 18:37:24 GMT
From:      nsc!pyramid!infmx!kwang@hplabs.hp.com  (Kwang Sung)
To:        tcp-ip@nic.ddn.mil
Subject:   Are you tired of working on top of TCP/IP ??

Hi...

	Are you tired of working on top of TCP/IP ??  Here is a good news
from our Informix SQL Access Group. My RDA (Remote Database Access, ISO/IEC
DP 9579-1) is now about to work. Currently, it is running on top of SunLink OSI
("pure" OSI stack) and on top of TCP/IP with RFC 1006 both as a loopback mode 
on my SPARCstation 1.

	Initially, I embedded it into ISODE-6.0 (== 50 MB, a public domain 
software which was developed under the contract from the U.S. Defense Advanced 
Research Projects Agency and the U.S. Air Force).

	Right now, my RDA is of a size with about 5 MB. It will be much bigger
than now. Still I need a long way to go for the final product. The source codes
are strictly confidential. We need to have someone starts working on the portion
of mapping SQL to RDA services so that our RDA can interface with ESQL/C.
We also need to have someone who can work RDA with me plus a testing guy as soon
as possible. 

	I hope we can replace our product with this OSI and TCP/IP-based
product in the near future. Thanks.


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Jun 90 22:55:50 EDT
From:      droms@sol.bucknell.edu (Ralph E. Droms)
To:        tcp-ip@nic.ddn.mil
Subject:   CFP SIGCOMM-SIGGRAPH Workshop on Graphics and Networking

			   Call for Participation
	    SIGCOMM-SIGGRAPH Workshop on Graphics and Networking*
			     16-18 January 1991
		  National Center for Atmospheric Research
			      Boulder, Colorado


      The  futures  of  graphics  and  networking  are  closely  linked
      together.  The spread of networked workstations with high-quality
      bit-map displays has  encouraged  the  creation  of  environments
      which  use  networks  to exchange graphics images.  The advent of
      fiber-optic networks, with gigabit data  bandwidths,  capable  of
      carrying  data  fast  enough to support real-time graphics, seems
      likely to encourage further integration of the two fields.

      The goal of this workshop is to bring together key members of the
      graphics and networking communities, including people involved in
      research, development and standards, to discuss  concerns  common
      to the two fields.  Topics of discussion are expected to include:
      What are the critical interactions between work in  graphics  and
      work  in  networking?  How will current and future graphics stan-
      dards affect  current  and  future  networking  protocols?   What
      effect  will  new  developments  in each field have on the other?
      Suggestions of additional topics are welcomed.

      The workshop format will be three days of plenary meetings,  with
      each  day  having  four  sessions.   Each session will start with
      brief presentations (5-10 minutes) by  selected  attendees,  fol-
      lowed  by  discussion.   A meeting report will appear in the SIG-
      GRAPH and SIGCOMM newsletters.

      How To Participate

      To ensure a good interaction between participants,  the  workshop
      is  limited to no more than 75 people.  We will try to give every
      attendee the opportunity to give a very short talk.  If  you  are
      interested  in  attending,  send a two paragraph application that
      describes your background, and the topic or topics you would like
      to discuss, to the program co-chairs by October 22:

      Dr. Ralph Droms          Dr. Robert Haber
      Computer Science Dept.   Dept of Theoretical and Applied Mechanics
      Bucknell University      University of Illinois
      323 Dana Engineering     111J Talbot Lab
      Lewisburg, PA 17837      104 South Wright St
			       Urbana, IL 61801
      +1 (717) 524-1145        +1 (217) 333-3826
      droms@bucknell.edu       haber@ncsa.uiuc.edu

      Conference Fees

      The conference fee will be $80 for SIG/ACM members and  $100  for
      non-members.   We expect a choice of hotels, with prices from $35
      to $60 a night.  The workshop itself will be held at the  facili-
      ties  of  the  National  Center for Atmospheric Research which is
      generously contributing the meeting space.

      Student Attendence

      There are spaces reserved for two graduate students to attend the
      workshop.   These  two  students will be asked to keep notes, and
      provide a workshop report which will be printed in  the  SIGGRAPH
      and  SIGCOMM  newsletters.  In return for this work, the workshop
      will provide up to $500 in travel funding for each student.  Stu-
      dents  interested  in applying for these positions should contact
      the conference co-chairs.

*ACM approval pending

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 20:34:32 GMT
From:      joltes@husc4.harvard.edu  (Richard Joltes)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: (none)
In article <9006011429.AA18394@interlan.interlan.com> solensky@INTERLAN.INTERLAN.COM (Frank Solensky) writes:
>Yes, it is atypical.  I've been on the list for about a year and this is the
>first time someone at, shall we say, "this level" (note indiscriminate use
>of "O" and "0") has posted this type of thing.

This article (title "COWABUNGA" and sent by someone called "BIFF") seems to 
have been posted to nearly every major newsgroup simultaneously, or nearly so.
I know it's appeared on:

comp.lang.fortran
comp.dcom.lan
comp.dcom.cisco
comp.os.vms
comp.sys.dec
comp.protocols.tcpip
rec.org.sca
rec.arts.startrek

I'm not sure about any others, but someone else said it'd been posted to one
of the security newsgroups as well.  Someone has tried replying and the mail
hasn't yet bounced, which leads me (at least) to believe that some idiot got
access to a friend's account and decided to play.

If anyone reading this is associated with CMU or PSUVM (both mentioned in the
article) they may want to do some checking.  Others already are...

This public service announcement brought to you by...

Dick Joltes					joltes@husc4.harvard.edu
Mgr. of Hardware & Facilities
Harvard University Science Center
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 22:26:43 GMT
From:      zaphod.mps.ohio-state.edu!usc!pollux.usc.edu@tut.cis.ohio-state.edu  (Gene Tsudik)
To:        tcp-ip@nic.ddn.mil
Subject:   Security services in border GWs (was: Suspicious Secure GW)

The inadequacies of the gateway-based filtering have been discussed in a number
of recent messages. To sum things up, it was pointed out (by Phil Karn) that
"..there is no substitute for each individual taking the responsibility for
his own local domain...".

It is hard to disagree with this point of view. However, the argument was in the
context of end-system protection. It is both inadequate and inappropriate for a
gateway to protect hosts that are subject to the outside exposure. Instead,
these hosts should be able to protect themselves.

However, another important issue is the protection of network resources other
than the end-systems. This includes internal gateways, bridges and links. It is
obviously undesirable to have unauthorized external traffic interfere with
local traffic. This is why internal network resources should be protected
from unauthorized use. Note that simply detecting bad packets at the
end-systems is inadequate since by the time unauthorized traffic reaches
an end-system, it has already consumed internal network resources. So, if
protection of network resources is desired, border GWs need to check incoming
packets for i) authenticity, ii) data integrity, and iii) replay.

Furthermore, when an organization connects to an internet, more often
then not, only a small number of select end-systems are exposed. Should all
other strictly-internal end-systems be expected to implement adequate security
measures? The answer is dependent on one's "religion". If one subscribes to

Phil Karn's point of view, there should be no such things as "unprotected "
end-systems in the first place. Alternatively, if there is a need to preclude
any kind of external access to strictly-internal end-systems, border
gateway-based mechanisms can be employed to restrict incoming traffic to
only exposed end-systems. This can be done with complete transparency to
the internal (unprotected) end-systems.

Note, that an intruder can still use the exposed end-systems as a conduit for
accessing the internal systems. However, using Phil Karn's argument above,
the exposed end-systems should ensure that this doesn't happen.

In summary, end-system controls are inadequate for protecting internal network
resources. To control access to such resources, border gateways need to
implement appropriate security mechanisms.

Gene Tsudik and Deborah Estrin

Computer Networks and Distributed Systems Laboratory
Computer Science Department
University of Southern California
Los Angeles, Ca
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      1 Jun 90 22:27:27 GMT
From:      zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!roy@tut.cis.ohio-state.edu  (Roy Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: trash message from usenet (BIFF)
jas@proteon.com (John A. Shriver) writes:
> if their umbrella organization (usenet) cannot maintain professional
> standards of behavior, then that is their loss.  By implementing a
> system without accountability, they create that risk.

	And there lies the heart of the problem; there is no umbrella
organization called usenet.  At best, usenet is a loose confederation of
cooperating sites.  At worst, it's a anarchy.  You can't blame it on "them"
because there is no "them" to blame it on.
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,cmcl2,rutgers,hombre}!phri!roy
"Arcane?  Did you say arcane?  It wouldn't be Unix if it wasn't arcane!"
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 00:17:53 GMT
From:      shemesh!ittai@nyu.edu  (Ittai Hershman)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: trash message from usenet (BIFF)
> The TCP-IP list has been quite consitently professional in its
> conduct, as have most public Internet mailing lists.  Everything
> unprofessional I have seen recently was "gatewayed" in from netnews.

Nonsense.  Witness the recent debate on the IETF mailing list, which
is not gatewayed to netnews, on the subject of tongue-in-cheek
messages.  The "problem" is very simply the price of success -- things
were a lot more professional back in the old days before we let just
anyone (tongue is definitely in cheek here) on the network.

The real problem is that our e-mail/conferencing user-agent paradigms
no longer fit the reality of the Internet.  On a personal level, I use
e-mail pretty much for one-to-one or one-to-small-ad-hoc-group
communication, and use netnews for all mailing-list/conferencing type
activities.  This was a step in the right direction, but the
user-agents are still far too primitive.  There are some intriguing
ideas being developed in the research community and I look forward to
trying them out as implementations are made available.

-Ittai
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 00:38:04 GMT
From:      portal!cup.portal.com!thinman@apple.com  (Lance C Norskog)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Trying to write a bootp client for Ultrix
You have a logical conundrum here.  You are trying to figure out how
to "turn on" IP, but you are trying to use IP to figure this out.

You have to send and receive your own raw Ethernet packets.  Ultrix
may have some technique for doing this.  System V has it's own scheme
where the Ethernet devices have their own /dev entries (jeeez wotta concept)
which you open and "bind" to a protocol number.

good luck.
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      Sat, 02 Jun 90 09:34:58 cst
From:      (strick) <strick@ttuvm2.ttu.edu>
To:        TCP-IP%NIC.DDN.MIL@pucc.PRINCETON.EDU
Cc:        File <snstr@ttuvm1.ttu.edu>
Subject:   tn3270 terminal server

>Does anybody know if anybody makes a terminal server that speaks
>both normal telnet and tn3270?

I understand that the MPG (WISC ware) is a combination terminal server and
IBM 7171.  You can contact Susan Bramhall at susan@yalevm.bitnet for more
information.
strick


-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 03:36:07 GMT
From:      umigw!mthvax!wb8foz@handies.ucar.edu  (David Lesher)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: trash message from usenet (BIFF)
Gee, the funny thing is, few of us on the Usenet side were 
bothered by this lid. Why? A responsible net_citizen cancelled
all the garbage before most people saw it. It's a pity your
maillist software won't handle cancels; then you would not have
been annoyed either. Maybe you should fix it. ;-} 

There are things that annoy me about maillist<-->newsgroup bridging.
The chief one is all the "PLEASE UNSUBSCRIBE ME" psotings that it
brings. Nothing is perfect; most of all Usenet. If you are really that
upset by this very unusual event, may I suggest you snag "filter"
from the elm distribution and set it up to bit_bucket all that "trash"
that comes from the bridge site.

I hope this bridge keeps working. I learn a lot reading this
group.



-- 
A host is a host from coast to coast.....wb8foz@mthvax.cs.miami.edu 
& no one will talk to a host that's close............(305) 255-RTFM
Unless the host (that isn't close)......................pob 570-335
is busy, hung or dead....................................33257-0335
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 05:21:22 GMT
From:      jacob@gore.com (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   Re: trash message from usenet (BIFF)

/ comp.protocols.tcp-ip / jas@proteon.com (John A. Shriver) / Jun  1, 1990 /
> I'd rather the "gateways" be made one
> way (out from Internet only), or even non-existent. [...]
> I realize that this would deny netnews/uucp only sites access to the
> Internet mailing lists,

You should also realize that this would deny people on the Internet mailing
list contributions from Usenet users.

> but if their umbrella organization (usenet)

It's not an organization.  It's a community.

> cannot maintain professional standards of behavior, then that is their
> loss.

Ah, I see.  Not your loss.  All the important people are on the mailing lists.

>  By implementing a system without accountability, they create
> that risk.

True.  Funny thing, though: this is what a lot of VMS/DECNET buffs were
saying about the Internet after the Morris Worm.  Until the DECNET worm a
few months later, that is...

> I (and others) would welcome netnews being made properly accountable
> and secure.

Certainly.

But what's so special about mailing lists?  It IS easy to fake Usenet
messages; but are you saying that it's hard to fake messages sent to a
mailing list?

> not building the Received: lines may make netnews
> more efficient, but this removes all vestiges of accountability.  This
> is a key problem.

One can start a mail message with a fake sequence of "Received:" lines just
as easily as starting a Usenet message with a fake "Path:" line (which is
what the cowabanga bozo did).

Jacob
--
Jacob Gore		Jacob@Gore.Com			boulder!gore!jacob

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 07:08:44 GMT
From:      van-bc!sl@uunet.uu.net  (Stuart Lynne)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: trash message from usenet (BIFF)
In article <1990Jun2.033607.9779@mthvax.cs.miami.edu> wb8foz@mthvax.cs.miami.edu (David Lesher) writes:
}Gee, the funny thing is, few of us on the Usenet side were 
}bothered by this lid. Why? A responsible net_citizen cancelled
}all the garbage before most people saw it. It's a pity your
}maillist software won't handle cancels; then you would not have
}been annoyed either. Maybe you should fix it. ;-} 

The other funny thing is that slightly more than half the traffic originates
on this side of the fence. I just did a simple straw poll, out of 88
articles in /usr/spool/news/comp/protocols/tcp-ip, only 34 had originated
from "The Internet".


-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      Sat, 2 Jun 90 13:49:53 EDT
From:      LiBai!tinker@ames.arc.nasa.gov (Don Tinker)
To:        tcp-ip@nic.ddn.mil
Subject:   Tsock available for ftp

Tsock, a socket testing/ network performance testing application, is
available for anonymous ftp from sol.ctr.columbia.edu [128.59.64.40]
as pub/net/tsock.tar.Z.

Beginning as "ttcp", a public domain socket-test program written by
Terry Slattery & Mike Muuss at BRL, it's essentially been completely
rewritten.  Like ttcp, tsock opens a socket (as a transmitter or a
reader) and shoves data into/reads data from it; but it includes the
capabilities to:

	o Spread the data over multiple child processes using the same
socket
	o Write data in user-specified buffer sizes (and read data in
user-specified buffer sizes if the underlying network permits this)
	o Send/receive data simultaneously over the same socket (full duplex)
	o Align the data on various memory boundaries
	o Randomize things like buffer sizes and data
	o Send/receive streams or datagrams

(some of these may be in ttcp also; if so, my aplogies to the authors).

And thanks to seth at columbia for providing the space.


Don Tinker				tinker@ultra.com
Senior Field Support Engineer		{core}!ames!ultra!tinker
UltraNetwork Technologies Inc. 		(703) 821-8393
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 11:02:18 GMT
From:      messy!mo@bellcore.com  (Michael O'Dell)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: trash message from usenet (BIFF)
The notion that mail or mailing lists on the Internet are either
"secure" or "accountable" is simply hysterical.
	-Mike
-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      Sat, 02 Jun 90 21:29:51 -0400
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        ka9q.bellcore.com!karn@bellcore.com (Phil Karn)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: What is the IAB?
> Indeed it seems
> that several other missteps within the Internet community can be traced to
> this same cause. The use of ASN.1 within SNMP, for example.

Whoa!  ASN.1 was used in SGMP the "experimental" predecessor of SNMP which
NO ONE from the OSI camp had any influence on, PERIOD.  Four people who's
healthy skeptism of ISO technology and politics are world known (you heard
me in Stockholm) needed a format and chose ASN.1 within the SGMP concept
and proved its workability.  The next generation SNMP kept the design
and tradition and use of ASN.1.  ASN.1 was a good choice, NOTHING has
proven this a bad choice.

About every six months there seems to be a little chinese fire drill,
it would appear initated by some of the iconic figures of the Internet,
who talk about performance problems with X,Y,Z areas of SNMP/ASN.1.
All of them have been proven false, and without merit.

SGMP and SNMP went through a very thorough process, of implementation,
review, implementation, review, implementation, review.  Lots and lots
of that good stuff called peer review.  If there was a technical problem
of that size it would have died on the vine.

Marty
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 15:34:58 GMT
From:      strick@TTUVM2.TTU.EDU (strick)
To:        comp.protocols.tcp-ip
Subject:   tn3270 terminal server


>Does anybody know if anybody makes a terminal server that speaks
>both normal telnet and tn3270?

I understand that the MPG (WISC ware) is a combination terminal server and
IBM 7171.  You can contact Susan Bramhall at susan@yalevm.bitnet for more
information.
strick

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 21:50:41 GMT
From:      ka9q.bellcore.com!karn@bellcore.com  (Phil Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: What is the IAB?

Yes, I should modify my earlier statement as follows: the IAB *usually*
follows a "fly before buy" policy regarding protocol standardization.  The
fact that political pressure from the OSI camp has occasionally corrupted
the process doesn't make this principle any less important. Indeed it seems
that several other missteps within the Internet community can be traced to
this same cause. The use of ASN.1 within SNMP, for example.

Phil
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      2 Jun 90 23:18:10 GMT
From:      ka9q.bellcore.com!karn@bellcore.com  (Phil Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Security services in border GWs (was: Suspicious Secure GW)
In article <25040@usc.edu> tsudik@pollux.usc.edu (Gene Tsudik) writes:
>In summary, end-system controls are inadequate for protecting internal network
>resources. To control access to such resources, border gateways need to
>implement appropriate security mechanisms.

Yes, your conclusion does follow from your premise. The question, though, is
whether this is a real problem. Most private corporate or campus networks
are "stubs" off the main Internet, so what can anyone gain by sending
traffic into such a network without access to a host on that network?
Sabotage of the private network itself is of course a possibility, but this
can be handled by turning on a gateway filter to block the offending
traffic.

I don't oppose filtering gateways per se. I just think they're like police
roadblocks: appropriate during emergencies, but too disruptive for routine
operations.

Phil
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 00:24:36 GMT
From:      ka9q.bellcore.com!karn@bellcore.com  (Phil Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <1990May29.191125.9800@portia.Stanford.EDU> morgan@jessica.stanford.edu (RL "Bob" Morgan) writes:
>
>Indeed, SMTP's assumption that everybody's connected all the time
>>doesn't work well with occasionally-connected hosts.  [...]

I'm also very interested in making the Internet protocols work well over
non-full-time paths. 

Here's an idea that I put into my KA9Q TCP/IP package a while ago.  It has a
UDP-based server that handles "kick" requests. These force retransmissions
on any TCP connections to the specified IP address (which defaults to the
sender of the kick message) and they also cause the remote SMTP daemon to
start sending any pending traffic to the destination.

This has turned out to be a useful feature when dealing with dialup links or
the long network outages that are characteristic of some experimental
amateur packet radio links. When the path is up, the person expecting mail
sends a kick request to the site(s) from which he expects his traffic, e.g.,
a mail exchanger. If there's any traffic waiting, it immediately starts to
flow. Also, because my TCP connections never time out (they just back way
off) the kick command lets you pick up a partial transfer right where you
left off when the path broke without having to restart it from the
beginning.

Perhaps it's time for an "intermittent connectivity" working group in the
IETF?

Phil
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 02:00:01 GMT
From:      usc!cs.utexas.edu!news-server.csri.toronto.edu!utgpu!utzoo!henry@ucsd.edu  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <36901@think.Think.COM> barmar@nugodot.think.com (Barry Margolin) writes:
>>Indeed, SMTP's assumption that everybody's connected all the time
>>doesn't work well with occasionally-connected hosts.  It would seem
>>that the time is ripe for some sort of extension to SMTP...
>
>No extension is needed: see the TURN command.  However, most SMTP
>implementation don't enable this command for security reasons...

TURN is the wrong tool for the job.  What is needed is the equivalent of
UUCP's callback facility:  A connects to B, says "call me", and hangs up.
B then makes the call -- which eliminates the authentication issue -- and
transfers the traffic.

People interested in infrequently-connected hosts would do well to study
how UUCP software and administrators deal with the problems.  There is
a large body of relevant experience there.

>However, I'm not sure why you need any of this.  What's wrong with the
>MX'ing host periodically trying to connect to the occasionally-connected
>hosts? [which is the way it already works] ...

It has the standard problem of any polling scheme:  frequent attempts eat
resources, infrequent attempts can miss "hitting the window" for a site
which is only connected occasionally.  As with most polling, the real
answer is to have the other end *tell* you "now would be a good time".

SMTP's approach assumes hosts that are on the network more or less
continuously, with partitioning and/or downtime a relatively rare and
transient phenomenon that can be dealt with in simplistic ways.  When
the connection, as opposed to the absence thereof, is rare and transient,
more sophisticated tactics are needed.
-- 
As a user I'll take speed over|     Henry Spencer at U of Toronto Zoology
features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 07:24:40 GMT
From:      unmvax!sci.ccny.cuny.edu!cucard!dasys1!cooper!phri!sci.ccny.cuny.edu!rpi!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!emv@ucbvax.Berkeley.EDU  (Edward Vielmetti)
To:        tcp-ip@nic.ddn.mil
Subject:   anonymous ftp, and the dangers thereof

from ftpd(8):
BUGS
     The anonymous account is inherently dangerous and should  be
     avoided when possible.

Despite this dire warning, there are over 500 systems on the internet
which support anonymous FTP.  There are known bugs in several versions
of ftpd which allow crackers to break in; word about this spread rather
quickly around some parts of the net just before the internet worm hit.
The worm didn't expose these vulnerabilities, so there's good reason
to believe that some people are still at risk.

ftpd identifies itself in the login banner like so:

220 stag.math.lsa.umich.edu FTP server (Version 5.55 Tue Apr 17 20:44:35 EDT 1990) ready.

so that a potential cracker need only retrieve this one piece of
information to see whether a system might be susceptible to attack.
There's no guarantee that the date in this banner is the actual
date that the code was fixed, nor does the version number seem to
mean much; but if the version is well known the means of entry can
be assured.  Any BSD'ish system with a date earlier than the berkeley
fixes posted 10/31/88 and 11/18/88 is an easy target, as are systems
for which vendors have supplied fixes.

I would estimate by a sampling of these banners that one host in 10
that does anonymous FTP is vulnerable.  

Some sites keep anonymous FTP directories to be world-writable,
letting any random internet user drop a file in a directory.  If you
see a file named GETMONEY.txt, makemoney.doc, or sex-bbs.doc (or
variations on same) in your FTP directory, this is why.  It is not
good practice to allow random anonymous users to scribble into
directories; several sensible systems have "upload" or "tmp"
directories for submissions, from which an archive manager will
move files into their real homes.  The problem of allowing remote
users to update archives which belong to them should be addressed
with ordinary passworded accounts.

Despite the widespread use of anonymous FTP, the internet RFC's
provide no guidelines to its use or configuration.  The conventions
that define anonymous FTP, its risks, and suggestions on how
to set up a good FTP site should be collected in the form of
an RFC on anonymous ftp.

--Ed

Edward Vielmetti, U of Michigan math dept.
emv@math.lsa.umich.edu
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 07:25:01 GMT
From:      hscfsas1!chrome@husc6.harvard.edu  (David C. Kovar)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <EMV.90Apr18204600@picasso.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:
>ftpd identifies itself in the login banner like so:
>
>220 xxxxxxxxxxxxxxxxxxxxxxx FTP server (Version 5.55 Tue Apr 17 20:44:35 EDT 1990) ready.
>

  I am not up on which versions of FTP are currently vulnerable but it
strikes me as quite irresponsible to use actual host names in an example.
If nothing else, you're going to get some people FTPing to it just to
see what the scoop is. (I just did to see if you really were using an
actual example.)

  I'm all for securing systems, but you've got to be somewhat intelligent
about doing it. If posts show up in this newsgroup that cause certain
systems to be broken into (ie, by attracting attention to them) then
the newsgroup will go away. Worse still, there is a small chance,
very small given current laws, that you will be held responsible for
any break in caused by your post.
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 07:25:23 GMT
From:      unmvax!sci.ccny.cuny.edu!cucard!dasys1!cooper!phri!sci.ccny.cuny.edu!rpi!zaphod.mps.ohio-state.edu!samsung!umich!srvr1!maize.engin.umich.edu!fozzy@ucbvax.Berkeley.EDU  (Eric Wines)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <2616@husc6.harvard.edu> chrome@hscfsas1.UUCP (David C. Kovar) writes:
>In article <EMV.90Apr18204600@picasso.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:
>>ftpd identifies itself in the login banner like so:
>>
>>220 xxxxxxxxxxxxxxxxxxxxxxx FTP server (Version 5.55 Tue Apr 17 20:44:35 EDT 1990) ready.
>>
>
>  I am not up on which versions of FTP are currently vulnerable but it
>strikes me as quite irresponsible to use actual host names in an example.
>If nothing else, you're going to get some people FTPing to it just to
>see what the scoop is. (I just did to see if you really were using an
>actual example.)
>

I think you are quite wrong.  To be on the internet these days your 
system had better be secure.  Your login accounts had better have good
passwords, your ftp had better be secure, etc.  It would extremely trivial
to query every entry in /etc/hosts for ftp version information.
If it is really a hole don't you think there are hacker's that have
exploited it?
  Would I be wrong to tell a co-worker that some idiot sysadmin at bozo.com
has root wide open without a password (just an example).  My company is not on
the internet.  We may be in the near future.  If this is to happen things
will have to be *extremely* secure on the machine that connects.
I have co-workers who don't really know what the internet is expressing
concern about security in the face of the the possibility of connecting to
it (from what they here on the news).

I think being on the internet is like having a home phone.  Anyone can call
you at anytime, even at 4AM.  You can unplug your phone but that's not really
a solution.  You can get an answering service for a phone to keep people from
bugging you, but for the internet, your system should be secure or you'd
better not care.
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 07:25:29 GMT
From:      snorkelwacker!bionet!hayes!wisner@think.com  (Bill Wisner)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
chrome@hscfsas1.harvard.edu (David C. Kovar) writes:

>								     it
>strikes me as quite irresponsible to use actual host names in an example.

He goes on to warn:

>			     Worse still, there is a small chance,
>very small given current laws, that you will be held responsible for
>any break in caused by your post.

Chill out, Dave. Ed used his *own machine* as an example. Really.

Bill Wisner <wisner@hayes.fai.alaska.edu> Gryphon Gang Fairbanks AK 99775
"Wisner, you're scum." -- Matt Crawford <matt@oddjob.uchicago.edu>
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 07:25:37 GMT
From:      ogicse!blake!Tomobiki-Cho!mrc@ucsd.edu  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <EMV.90Apr18204600@picasso.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:
>Despite the widespread use of anonymous FTP, the internet RFC's
>provide no guidelines to its use or configuration.  The conventions
>that define anonymous FTP, its risks, and suggestions on how
>to set up a good FTP site should be collected in the form of
>an RFC on anonymous ftp.

Just as a matter of history, on Tenex and TOPS-20, userid ANONYMOUS
could only write to the PS:<ANONYMOUS> directory (its home directory).
ANONYMOUS could only read files that were on PS:<ANONYMOUS>, group-
accessible to ANONYMOUS (generally never done), or world-readable.

Furthermore, passwords were never stored in any file readable by any
user, even in encrypted form.  The only way to read a password in any
form (including encrypted) was to do a privileged system call.  Anyone
who could do this system call had already broken security (had the
equivalent of root).

The operations which required passwords were system calls which took
the user's attempted password in plaintext.  The encryption algorithm
was in the operating system and there was no specific function to
return the encrypted form of a password (although with enough effort
someone could find out what the encryption algorithm was).  Failed
password attempts were counted, and an excessive failure rate was
cause to bump the user off the system.  Many systems considered *all*
password attempts to be failures at some point before the bump-off
point, so even a valid password would fail.

It worked pretty well.  Most Tenex/TOPS-20 sites had warm fuzzy
feelings about allowing ANONYMOUS and never had any security problems
because of it.  There are lessons to be learned, starting with the
abolishment of /etc/passwd and user access to the encryption
algorithm.
 _____   | ____ ___|___   /__   Mark Crispin           Atheist & Proud
 _|_|_  -|- ||   __|__   /  /   6158 Lariat Loop NE    R90/6 pilot
|_|_|_|  |\-++-  |===|  /  /    Bainbridge Island, WA  "Gaijin! Gaijin!"
 --|--  /| ||||  |___|    /\    USA  98110-2098        "Gaijin ha doko ka?"
  /|\    | |/\| _______  /  \   +1 (206) 842-2385      "Niichan ha gaijin."
 / | \   | |__|  /   \  /    \  mrc@CAC.Washington.EDU "Chigau. Gaijin ja nai.
kisha no kisha ga kisha de kisha-shita                  Omae ha gaijin darou."
sumomo mo momo, momo mo momo, momo ni mo iroiro aru    "Iie, boku ha nihonjin."
uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru    "Souka. Yappari gaijin!"
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 08:10:10 GMT
From:      network.ucsd.edu!celit!hutch@ucsd.edu  (Jim Hutchison)
To:        tcp-ip@nic.ddn.mil
Subject:   Passwords in the kernel (was Re: anonymous ftp, and ...)
In article <6721@blake.acs.washington.edu>
	mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>No.  We aren't talking about hiding passwords in a secret file.  Any
>file, once known, can be gotten at.  We are talking about hiding the
>password where only the kernel can get at them.  Granted, a program
>that does absolute disk reads can get at the passwords; but such a
>program (1) can't be run under FTP (2) can only be run by a privileged
>user (and hence the system is already violated).

An interesting idea, you want the kernel to maintain a password database
on a secondary storage device.  This database is not a user accessible
file system.  Nor is it mountable in a normal way, because if it were
it would be able to be left that way by the same careless sysadmin who
bungled the permission bits and ftp setup.

Among other things, who backs it up?  If root must back it up, then you've got
to set up the backup utilities to be run safely by operators...  If "operator"
is going to back it up, it has to be readable by the op.  This being the sort
of problem which seems to prompt people to slam in suid/sgid bits or chmod a+r
things.  Not my solution, but apparently a common one.

Sounds like a mini-nightmare to maintain, based on backing it up (securely!)
and restoring it in the event of a tragedy (one could no longer type it in
using /bin/cat and being able to remember root::0:0:&:/:/bin/sh).  At first
thought I'd think you could use /bin/cat to the raw device, but then you'd have
to remember the major/minor number of it for mknod, and it gets worse from
there.  This is demanding a lot of smart thinking from the sysadmin who is
having so much trouble securing the system.

>We are talking about setreuid() not requiring any privileges, but
>taking a password as an argument.  We are talking about no "setuid"
>programs; in its place are new unprivileged system calls which make
>the necessary checks.

So, the hacker now has to probe individual passwords instead of attacking
the database.  Not much of a win judging by the effectiveness of the
various worms and security studies involving password guessing.

>In other words, we're talking about making it harder for the system to
>be compromised simply by poor file protections!

Please revise, it still looks like "poor filesystem protections",
ftp> set binary
ftp> cd /dev
ftp> get r0xd0b
...

>Unix purists argue that this "adds a lot of junk to the kernel" and
>interferes with the beauty and elegance of Unix.  I hate to break it
>to them, but the Unix kernel hasn't been "small and beautiful" since
>PDP-11 days.

In view of the small gain involved, the massive cost in development,
standardization, and maintenance.  I'd say you hit the nail on the head
when you labeled this "junk".  It is a very interesting idea though.

Perhaps it would work better if the secondary storage device was something
more oriented to security, such as one of those password scratch-pads
I've heard the kerberos folks use on occasion.  Then it'd be an add-on
password library and a device driver.  You might be able to sell a few
million to the government and research facilities.  You could probably
interest Logicon in it, or some other company working on a secure Unix.

--
-
Jim Hutchison   	{dcdwest,ucbvax}!ucsd!fps!hutch
Disclaimer:  I am not an official spokesman for FPS computing
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 08:15:37 GMT
From:      unmvax!sci.ccny.cuny.edu!cucard!dasys1!cooper!phri!sci.ccny.cuny.edu!rpi!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!mailrus!b-tech!zeeff@ucbvax.Berkeley.EDU  (Jon Zeeff)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
All this emphasis on turning off tftp and waiting for shadow password 
files may be clouding the simpler and more effective solution.  Force 
users to pick good passwords!  Something with some non-alpha 
characters and mixed case (not the first letter capital).  

Neither turning off tfpd or even shadow passwords will protect you from 
local users or people who used to have root.
-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 08:28:48 GMT
From:      stan!dancer!imp@boulder.colorado.edu  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof

In article <6703@blake.acs.washington.edu>
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>... There are lessons to be learned, starting with the
>abolishment of /etc/passwd and user access to the encryption
>algorithm.

Sorry.  There are too may passwd files out there to do this.  Shadow
files might help, but then again they might not.  The algorithm for
password encryption is well known and available via anonymous ftp from
many site.  Even if it wasn't, you'd have to put something like this
into the kernel, and we all know that /vmunix is world readable.  That
and a good disassembler would totally defeat whatever you just
gained....

What is needed is a good guide to how to setup anonymous FTP correctly
so that nobody can steal any real files.

Also, while we're on the subject:  Remember what tftp gives the known
universe.  Access to all world readable files.  Turn it off or restrict
it at your site if you are connected to anything resembling the
ineternet.

In article <1990Apr20.192233.4092@utzoo.uucp> henry@utzoo.uucp (Henry
Spencer) writes:
>Ah yes, good old security-through-obscurity.  Where have we heard that
>before?

And it doesn't work.  Never has, never will.  The only people that you
will catch by this are the people too lazy to be inventive.  And those
are the people least likely to crack your system anyway.

>If OSI is the answer, what on
>Earth could be the question??

You really don't want to know .... :-)

-- 
Warner Losh					imp@solbourne.com
Excuse me sir, this is a spot check.  Can we see your clue please?
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 08:28:51 GMT
From:      crdgw1!sixhub!davidsen@uunet.uu.net  (Wm E. Davidsen Jr)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <1990Apr20.192233.4092@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
| In article <6703@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
| >... There are lessons to be learned, starting with the
| >abolishment of /etc/passwd and user access to the encryption
| >algorithm.
| 
| Ah yes, good old security-through-obscurity.  Where have we heard that
| before?

  I don't know that I have any objections to shadow password. WHy give
the show away? It's like having L.sys or Systems world readable. I
accept that I can't keep the encryption a secret, so why give the
encrypted passwords away. I don't see what this has to do with
security-through-obscurity here.
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me
-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 08:28:53 GMT
From:      crdgw1!sixhub!davidsen@uunet.uu.net  (Wm E. Davidsen Jr)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <6721@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
|                                    We are talking about no "setuid"
| programs; in its place are new unprivileged system calls which make
| the necessary checks.

  That's nice in the far future, but I'll take what I have and
understand, carefully used. I'm perfectly content to have user programs
use setuid (not to root, thanks) to control access to things like
databases and other user owned resources. I think you could get a few
good theses from thrying to design something better than having the
owner of the resource provide a setuid program to provide access.

  The problem has been that vendors have been to cheap, lazy, or
incompetent to provide services by means other than using setuid root
for things. I regard about 30% of what most vendors do as being the
result of lazyness (not that this implies a security hole in that many
cases, but a lack of elegance).
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 09:23:39 GMT
From:      unmvax!sci.ccny.cuny.edu!cucard!dasys1!cooper!phri!sci.ccny.cuny.edu!rpi!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!emv@ucbvax.Berkeley.EDU  (Edward Vielmetti)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <EMV.90Apr18204600@picasso.math.lsa.umich.edu> I wrote:

   from ftpd(8):
   BUGS
	The anonymous account is inherently dangerous and should  be
	avoided when possible.

   I would estimate by a sampling of these banners that one host in 10
   that does anonymous FTP is vulnerable.  

You log on to an anonymous FTP site and notice that their FTP appears
vulnerable.  What do you do?

1.  nothing.
2.  break in and do something nasty.
3.  contact the system manager and let them know what's wrong.
4.  break in and leave a note to the system manager to let them
    know what's wrong.
5.  break in, leave a note to the system manager to let them know
    what's wrong, and install a fix.
6.  notify CERT and ask for further guidance.

Option 1 is easy, option 2 also.  Option 3 requires tracking down a
person in charge, as worst you send mail to postmaster.  I won't
recommend options 4 or 5, though I suspect that exercising them
a couple of times would trigger option 6.

Suggestions on the wording of the message to the system manager
welcomed.

--Ed

Edward Vielmetti, U of Michigan math dept.
emv@math.lsa.umich.edu
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Sun, 3 Jun 90 17:23:01 -0400
From:      bzs@world.std.com (Barry Shein)
To:        messy!mo@bellcore.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   trash message from usenet (BIFF)

>The notion that mail or mailing lists on the Internet are either
>"secure" or "accountable" is simply hysterical.
>	-Mike

I agree, the loudest arguments here appear to be non-sequitars and
"truisms" searching desparately for some pre-determined conclusion.

What I suspect is really at work here is an underlying argument that
"dial-up UUCP is cheap, therefore it must be (security-wise)
inferior".

In fact, those dial-ups require valid login/password pairs before any
delivery is made in virtually every case. The problem actually stems
from abuse of internet software, SMTP and other protocols are
completely vulnerable in much the same way.

But so what?

So is your telephone, what stops me from rigging a box to dial
hundreds of homes in the area at 3AM and play a tape of obscenities?
Say from a pay phone or direct tap (which is analogous to this forgery
stuff), etc. Hell, people do similar things legally around here (those
auto-dialers that tell me to dial this 900 number right now to win my
"free prize"), tho not at 3AM (lord help me if I work nights,
however.)

In the end what we really have to deal with is what standards we are
willing to be measured by.

If we put forth the image that the only reasonable network is one
where it's impossible to post an obnoxious message, ever, and then
communicate that to the public as a minimum standard of viability,
then the technology is doomed, because we will never be able to
deliver that.

This is very critical, and I think many of these protests are
demanding undesirable expectations as if they were tacit and agreed to
by everyone.

They're not, and I still consider my house locked up when I have only
glass in my windows. And I'm willing to put up with the occasional
obnoxious phone call if it keeps phone service easy to use and
inexpensive, or at least deal with it on a per incident basis, etc.

Somewhere in here is a classic exercise in the trade-offs of freedom
vs. security.

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 15:21:18 GMT
From:      cunixf.cc.columbia.edu!shenkin@rutgers.edu  (Peter S. Shenkin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <PMY$TW?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:
>All this emphasis on turning off tftp and waiting for shadow password 
>files may be clouding the simpler and more effective solution.  Force 
>users to pick good passwords!  Something with some non-alpha 
>characters and mixed case (not the first letter capital).  

This suggestion has been mentioned many times on the net, but it also has
a problem.  If passwords are non-mnemonic, unpronounceable and non-suggestive 
(as all "good" passwords are), then they are easy for users to forget;  not 
daily users, but occasional users, such as, say, a biology graduate student 
who logs on once a month to do a DNA sequence search.  Such users often
constitute the vast majority of users on departmental systems.  These users 
then *WRITE DOWN* their passwords, compromising security differently, but 
perhaps as severely, as is now the case.

For a while I had an account on a VMS system which, in the interest of
security, expired my password periodically, and required me to change it.
I mostly used a UNIX system, but had to log into the MicroVAX occasionally
to access a connected array processor;  I was an occasional user.  Keeping
track of my password became such a pain that for a while I wrote it down
and kept it in an unobrusive place, though I didn't like doing that.  
Evenually I discovered that I could change it, then change it right back
to the usual, and the machine wouldn't complain.  I felt a bit guilty
putting something over on the poor machine, but I feel I saved it from itself.
Its security measures were actually compromising security.

Not that I have answers....

	-P.
************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb**************************
Peter S. Shenkin, Department of Chemistry, Barnard College, New York, NY  10027
(212)854-1418  shenkin@cunixc.cc.columbia.edu(Internet)  shenkin@cunixc(Bitnet)
***"In scenic New York... where the third world is only a subway ride away."***
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 17:56:14 GMT
From:      rochester!ken@rutgers.edu  (Ken Yap)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <1990Jun3.152118.4758@cunixf.cc.columbia.edu>:
|In article <PMY$TW?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:
|>All this emphasis on turning off tftp and waiting for shadow password 
|>files may be clouding the simpler and more effective solution.  Force 
|>users to pick good passwords!  Something with some non-alpha 
|>characters and mixed case (not the first letter capital).  
|
|This suggestion has been mentioned many times on the net, but it also has
|a problem.  If passwords are non-mnemonic, unpronounceable and non-suggestive 
|(as all "good" passwords are), then they are easy for users to forget;  not 

I once read a good suggestion for choosing a mnemonic, yet hard to
guess password: take a catchy phrase and turn it into an acronym,
capitalizing and inserting punctuation as necessary. For example "Hey
man, don't have a cow" becomes Hm,dhac. I can't take credit (or blame
:-)) for this, I wish I remember the poster who suggested this. If you
are out there, take a bow.

Don't blame me if everybody chooses a Simpsons phrase... :-)
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 20:16:13 GMT
From:      portal!cup.portal.com!Will@apple.com  (Will E Estes)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP Between PCs and Mainframes...What Physical Layers?
Using IBM's mainframe TCP-IP implementations and OS/2 Extended Edition's
TCP/IP, what physical layers can be used?  I assume Ethernet at minimum,
but what about token ring, and what about SDLC since that is how the
vast majority of PCs are linked to mainframes?  Also, what about the case
where a PC goes through a gateway that emulates a 3174 and is connected
by modem to a 3725?

Thanks,
Will Estes        (sun!portal!cup.portal.com!Will)
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      3 Jun 90 22:32:13 GMT
From:      decvax.dec.com!ima!minya!jc@mcnc.org  (John Chambers)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
> CSNET did this some time ago with MMDF2b.  Some of the dial-up sites run
> a script every night which brings up the dial-up line, and then opens
> a connection to a port on relay.cs.net and tells it to start delivering
> mail to the site.  The application at that connection starts up the
> appropriate MMDF channel (mmdf can have multiple SMTP delivery channels,
> where a channel typically has messages destined for a particular site),
> which delivers the mail to the site.  [Note there's no security problem
> here -- anyone can start up the channel, but the channel will only deliver
> to the proper remote system(s)]

How so?  What's to prevent me from running a script of the form:

	for h in foo bar bax glorph `hostname`
	do	hostname $h
		<<Connect to your machine and exchange mail>>
	done

Is there some mechanism for detecting such spoofing?  The only way I can 
think of is by noting info at the link level (Ethernet address, phone number, 
or some such) and comparing, but on most systems, this info isn't available 
to application-level processes.  For instance, how does a process started
from a modem login discover the caller's phone number?  UUCP uses callback 
(if you can figure out how to make it work ;-), but I didn't see any mention 
of that.  What am I missing?

(Yeah, I know I'll also have to run ifconfig for this to work across the
internet.  That's part of the <<code>; give me credit for some smarts! :-)

-- 
John Chambers ...!{harvard,ima,mit-eddie}!minya!jc
--
If you're not part of the solution, you're part of the precipitate.
[Kiel oni ^ci tiun diras esperante?]
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 03:37:17 GMT
From:      stan!dancer!imp@boulder.colorado.edu  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: trash message from usenet (BIFF)
In article <670006@gore.com> jacob@gore.com (Jacob Gore) writes:
>But what's so special about mailing lists?  It IS easy to fake Usenet
>messages; but are you saying that it's hard to fake messages sent to a
>mailing list?

	Jacob makes a good point.  SMTP mail is trivially easy for
anybody with an account on any internet machine to forge.  Details can
be found elsewhere.  The "good" thing about USENET news is that it
puts an explicit path on all messages, so they can be traced fairly
easily.  Given the current state of the art of SMTP daemons, it is
possible to create a message that can't be traced back to the
offending system, much less the user that posted it.

	Fortunately, there is some good working going on to help stop
this.  The new host requirements RFC helps some.  Other efforts are
also in the works.  Some of them are misdirected (like fingering the
"from" line or assuming ports below 1024 are secure), while others are
good (like using heuristics to place a "Warning, this may be bogus" in
the headers).

	Someday we will reach the state where it is not possible to
forge mail, or at the very least we will know where the forgery came
from.  Until that date, you must do what you do with your 50's and
100's today: Double Check them before you accept them.

-- 
Warner Losh		imp@Solbourne.COM
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      Mon, 04 Jun 90 13:46:29 EST
From:      Carol Herre <702CH%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   request list subscription
   I am interested in subscribing to the TCP-IP list.  Could you please
send me the necessary subscription procedures.  Thank you

Carol Herre
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Mon, 4 Jun 90 12:49:31 EDT
From:      jas@proteon.com (John A. Shriver)
To:        umigw!mthvax!wb8foz@handies.ucar.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   netnews gatewaying
I will admit that many peoples' counter arguments to me have been
interesting (many sent just to me), including a cute peice of forged
SMTP mail.  I appreciate the comments, and do admit a anti-netnews
bias.  Apologies to those offended.

However, I was glad to see that some comments came out that might
address the problem.  David noted that there is a cancel function in
netnews, and that it nabbed this message fairly quickly.  Maybe the
netnews/SMTP "gateway" agents could put in a delay, maybe an hour or
two, that would allow the "cancel" to do it's work.  Also, maybe there
should be a crude filter program.

I think that we should focus on how to improve this system, rather
than assert that complaining about problems is unfair or evil.  There
is a problem, let's not stick our heads on the sand.  Research is
under way on secure SMTP mail, maybe research is needed elsewhere.  Be
constructive. 

My concern, which I may not have made clear enough, is that the US
Government is potentially watching us.  If they don't like what is
being done with the money the subsidize the Internet with, they might
cut it off.  We live in a glass house, as Barry noted.  The fellow
with the *big* rock is in Washington, D.C., not some hacker.

By the way, my other point about the netnews gateway just came home to
roost.  There is a mail loop on this list, with a delay of over 6
weeks, that just kicked in.  Groan, will that be hard to find.
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 10:24:16 GMT
From:      uhccux!munnari.oz.au!ditmela!smart@ames.arc.nasa.gov  (Robert Smart)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: trash message from usenet (BIFF)
Somebody should get the political scientists on to the network news and
the Internet. They are very interesting and succesful examples of a form
of political organization whose name is quite discredited in the world
today, namely anarchy.

If you are interested in the concept of anarchy in a wider context you
should read "The Dispossessed" by Ursula Le Guin. It is a convincing
description of what an anarchy would be like. Not a picnic, that's for
sure. You will have no trouble recognizing the equivalents of people from
our network world, from the idealists who work hard with little thanks
for the common good to the idiots who take advantage of the anarchy's
freedom and don't contribute.

It is easy to see the glaring weaknesses of an anarchic arrangement. Little
incidents show this. But let's not give it away when nothing serious has
happened. The successes far outweigh the problems, and it isn't at all
clear that a more structured or controlled environment would be so
successful.

Bob Smart <smart@mel.dit.csiro.au>
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Mon,  4 Jun 90 19:32:58 -0400 (EDT)
From:      Aaron Wohl <aw0g+@andrew.cmu.edu>
To:        tcp-ip@nic.ddn.mil, VANCE@tgv.com (L. Stuart Vance)
Subject:   Re: Interesting uses of networking
I made up a SNMP module for the excel spread sheet.  You can make
up worksheets with data that lives in router or systems (we have a
unix snmp deamon that read /dev/kmem) anywhere on the net.

Glen Marcy (gm0w@cs.cmu.edu) hacked a finger server on a tops20 to
connect to an rs232 line to the airconditioning computer on the roof.
One could finger temperature@te.cc.cmu.edu.

Someone is cs (try laurence butcher@cs.cmu.edu) wired up the coke machine.
You could finger coke@something and see how cold the coke was.
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 13:06:18 GMT
From:      sdd.hp.com!cs.utexas.edu!execu!sequoia!rpp386!jfh@ucsd.edu  (John F. Haugh II)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <PMY$TW?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:
>All this emphasis on turning off tftp and waiting for shadow password 
>files may be clouding the simpler and more effective solution.  Force 
>users to pick good passwords!  Something with some non-alpha 
>characters and mixed case (not the first letter capital).  

Using "good" passwords is meaningless without some control over the
encrypted passwords, because as sure as the sun rises in the east,
people write down "good" passwords.

On the other hand, permitting crappy passwords and protecting the
access to the encrypted crappy password can be secure if the number
of possible trials per unit time is sufficiently small.  A common
feature of many [ including mine ] enhanced login schemes is a limit
to the number of consecutive failures, which limits the number of
failing login attempts on a port to a very small number per unit
time, while not increasing [ by way of using excessively complex
computation scams ] the time to login successfully.  Another feature
is to limit the number of failed attempts on an account before the
account is turned off.

Given this setup using the shadow login code I posted last year,

% faillog -u root -p -u jfh -p
Username        Failures    Maximum     Latest
root                   0          0     Sat May 26 13:49:38 1990 on tty1A
jfh                    1       1000     Mon Jun  4 07:57:21 1990 on tty01

my account will be expired after 1,000 failures.  After 1,000 failed
trials the bad guy will no longer be able to know whether the password
is good or bad.  If I were extremely paranoid I could lower this value
to 10 or so and use trivial english words such as "Cat" or "Dog" without
too much concern.

On my system the maximum failed login rate is on the order of 6 per
minute through the modems.  This is a factor 10,000 slower than
estimates of PCs, which many have stated at being near 1,000 per second.
However, since I control the access to my encrypted passwords, the
problem is serialized at my machine, while someone is perfectly free
to employ two or more other machines to parallelize the problem in an
unprotected environment.

Moral of the story, pester your vendor for shadow password support ...
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org

                                            Proud Pilot of RS/6000 Serial #1472
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 16:02:33 GMT
From:      usc!zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!adk@ucsd.edu  (Andrew D Kailhofer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: NFS for NCR TOWER
I don't know how much help this will be, but my spies tell me that the
software is not yet general deployment, although there are some CVT
sites, one of which I'm trying to be.

Also, I guess that the software is done out of SE-Copenhagen.

Hope this helps.

Andy

kailhofr@cs.uwm.edu
414/678-7793
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 16:04:18 GMT
From:      usc!snorkelwacker!bu.edu!bu-it!kwe@ucsd.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Security services in border GWs
In article <25040@usc.edu>, tsudik@pollux.usc.edu (Gene Tsudik) writes:
> 
> The inadequacies of the gateway-based filtering have been discussed in
a number
> of recent messages. ...
> 
> Phil Karn's point of view, there should be no such things as "unprotected "
> end-systems in the first place. Alternatively, if there is a need to preclude
> any kind of external access to strictly-internal end-systems, border
> gateway-based mechanisms can be employed to restrict incoming traffic to
> only exposed end-systems. This can be done with complete transparency to
> the internal (unprotected) end-systems.
> 

	What is the essential difference between "routing" (including policy-
based routing) and "access control lists"?  Might the boundary be slightly
fuzzy?  It seems so to me, at least as far as ip-address is concerned.

	For example, if there is a stub domain connected to some transit
routing domain, and the stub advertises routes for nets A and B to the 
transit net (and the transit accepts), should the transit network filter
source addresses to exclude all sources except nets A and B?  Source
address filtering is currently considered to be part of "access control"
and not of "routing" (at least it seems so to me from current implementations
and Requirements RFCs).

	If the transit domain does not include source addresses in
the routing decision, then the transit domain's routing policy can be
overridden by the stub domain, through back-doors and side-doors.  This
is, of course, a current problem in the Internet.

	If one were to say that source address filtering at borders
should be done, then I think we may have redefined a part of
"access control lists" into "routing".  

	Perhaps today's access control list feature is tomorrow's
Router Requirement?   (And so Gene and Phil are both right.)

	--Kent England
	  Boston University
-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 16:15:45 GMT
From:      sdd.hp.com!hp-pcd!hplsla!hpubvwa!davem@ucsd.edu  (Dave MacDonald)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip services <--> decnet connectivity, help wanted
Integrated Information Systems (IIS) which I believe is owned by CDC has
just ported a DECNET product for the HP9000 family.  I have seen it
working on both the 300 and 800 series, and it appears to be very
reasonably priced.

The only number I have for them is for the manager of Business Development
for that product.  He is Randall K. Barker at (513) 427-6379.


Dave MacDonald
Bellevue, WA CEC
davem@hpubvwa
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 17:56:33 GMT
From:      vixie!asylum!sharon@decwrl.dec.com  (Sharon Fisher)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for Unix TCP/IP users
I'm doing a story for Unix World about how users are using communications
standards to help them communicate with other systems.  I'm looking for
users of TCP/IP software other than that by FTP (because I already have
users from them) who are using it to communicate between Unix systems and
other systems.

If you're willing to be interviewed for the article, please email me or
phone me at (415) 664-8845.  Thanks!
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 18:46:29 GMT
From:      702CH@SCRVMSYS.BITNET (Carol Herre)
To:        comp.protocols.tcp-ip
Subject:   request list subscription


   I am interested in subscribing to the TCP-IP list.  Could you please
send me the necessary subscription procedures.  Thank you

Carol Herre

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 22:14:26 GMT
From:      cs.utexas.edu!oakhill!guri@tut.cis.ohio-state.edu  (Gurvinder Singh Ahluwalia)
To:        tcp-ip@nic.ddn.mil
Subject:   Access Control Lists (ACLs) on cisco

At what stage is ACL verification done for a session?
[Of course, it is done when a session is established]. 
I wouldn't like to think that every packet has to be 
ACL-verified. Does that sound right? If so, how are
packets decided "go/no-go" across cisco ONCE a session
has been established? How does the cisco relate to 
the concept of a session (for subsequent packets) AFTER 
a session has been authenticated at ACLs? Doing a per
packet ACL-verification sounds like tremendous overhead.

Secondly, what kind of search algorithm is implemented on
ciscos for an optimum and effective ACL search?

Gurvinder Ahluwalia
Phone		: 512/891-3310
Internet	: guri@apogee.sps.mot.com		(PREFERRED)
UUCP		: ...!oakhill!apogee@cs.utexas.edu
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 22:17:26 GMT
From:      hpcc01!hpccc!munjal@hplabs.hp.com  (Deepak Munjal)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP-IP Print Spooler

Does anyone know of a box that will take TCP/IP based Unix spooled 
printer output and convert it something an RS-232 printer can understand?

This is basically a network printer, but all the products I've seen in 
this area are on the Novell architecture.

Any info would be appreciated.

Deepak
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 22:31:20 GMT
From:      att!cbnewsh!wcs@ucbvax.Berkeley.EDU  (Bill Stewart 201-949-0705 erebus.att.com!wcs)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: abolishing /etc/passwd (was Re: anonymous ftp, and the dangers thereof)
In article <28764@ut-emx.UUCP> pmaniac@walt.cc.utexas.edu (Noah Friedman) writes:
]In article <6703@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
]>... There are lessons to be learned, starting with the
]>abolishment of /etc/passwd and user access to the encryption
]>algorithm.
]/etc/passwd is quite useful. A number of my programs use information
]in this database, including the password field, so that other users
]can use their own passwords for various options while running my programs. 
	/etc/passwd has become the traditional location for user-info
	other than passwords, so of course it needs to be kept,
	but I agree with the shadow-password approach that puts 
	(encrypted) passwords in a non-world-readable file.

	Yes, this means that YOUR software can't use the real
	password, but this is good - I'm not going to trust my real
	password to non-system software, because of the increased
	risk of trojan horses and insecurity; terminal-lockers and such
	get their own passwords.

]If DES is breakable, then a new algorithm needs to be implemented. And
]users should be encouraged to choose good passwords, otherwise it
]doesn't matter what encryption mechanism is used.

	The point of the modified-DES used by UNIX is that it isn't
	the same as the real DES, so a real-DES breaker won't work,
	and a fast hardware implementation of real-DES will make it
	hard to search for obvious passwords.  Unfortunately, though,
	people have gotten 10-fold speedups in password encryption
	through software, and hardware is 1-2 orders of magnitude
	faster than the old PDP-11 days (much more, if you have a
	network of machines to bum cycles off of).
	So DES isn't real secure enough either, given readable passwords.

-- 
				Thanks;  Bill
# Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs
# Actually, it's *two* drummers, and we're not marching, we're *dancing*.
# But that's the general idea.
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      4 Jun 90 22:47:55 GMT
From:      zaphod.mps.ohio-state.edu!uwm.edu!csd4.csd.uwm.edu!james@tut.cis.ohio-state.edu  (Jim Lowe)
To:        tcp-ip@nic.ddn.mil
Subject:   uWave, IP, Video info



	Our local TV people are in the process of setting up a microwave link
here on campus.  They are looking at 23 Ghz systems.  I would like to be able
to add IP traffic to their setup.

	As I understand things, the 23 Ghz systems use a 10 Mhz bandwidth.
DC to 4.5 Mhz is used for the video signal.  They usually put the audio
signal at 6.2 Mhz with a 75 Khz deviation.  They also use 5.8 Mhz (not so
good of an audio channel due to synch buzz) and have second audio channels
at 6.8 and 7.5 Mhz.

	They said we could use one of the second audio channels to run
data on -- using modems at 56kbps.  Personally I would like to use T1 or T2
which should fit in the extra bandwidth.  Unfortunatly the manufacture (Macom)
doesn't offer any T1 capablility -- as far as we know.

	It seems that where we want to have data they want to have video and
visaversa.  It would be real nice if we could find a microwave system that
did video, audio, and at least one T1.

	If you have any experience with running data over microwave links
with video I would like to hear from you.  I would be interested in any
horror stories, actual setups that you are using, manufactures of equipment,
etc...

	Thanks,
		-Jim
		james@csd4.csd.uwm.edu

--
	- Jim
Internet: james@uwm.edu				Uucp:	   uwm!james
Bitnet:	  james%uwm.edu@INTERBIT		Telephone: +1 (414) 229-6431
USmail:   Computing Services Division, P.O. Box 413, Milwaukee, WI  53201
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 00:19:29 GMT
From:      portal!cup.portal.com!thinman@apple.com  (Lance C Norskog)
To:        tcp-ip@nic.ddn.mil
Subject:   AT&T's RFS needs a TCP port number
Dear Friends,

AT&T has their own file sharing protocol, called Remote File Sharing or RFS.
It is included (along with NFS) in UNIX V.4.

Since AT&T doesn't seem on the ball about registering an official TCP/IP
port number for RFS, how can we get this going?  We just went through a lot
of pain getting a customer's site set up with RFS over our TCP talking to
RFS over another TCP.  This protocol has been out for three years, and has
built a major installation base.  Not having an official TCP/IP port number 
for it is an oversight that must be corrected.

Lance Norskog
Sales Engineer
Streamlined Networks
408-727-9909 
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 00:27:39 GMT
From:      pegasus!richard@humu.nosc.mil  (Richard Foulk)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
>>Ah yes, good old security-through-obscurity.  Where have we heard that
>>before?
>
>And it doesn't work.  Never has, never will.  The only people that you
>will catch by this are the people too lazy to be inventive.  And those
>are the people least likely to crack your system anyway.

But, there are probably alot more of the "too lazy to be inventive"
types around.

"Security-thourgh-obscurity" certainly isn't great.  But I haven't seen
or heard of any evidence that it's totally useless.

Multiple layers of security would seem to be better than one "perfect"
barrier.

-- 
Richard Foulk		richard@pegasus.com
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 00:42:09 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!ssw@ucsd.edu  (Steve Wallace)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Access Control Lists (ACLs) on cisco
In <3362@apogee.oakhill.UUCP> guri@oakhill.UUCP (Gurvinder Singh Ahluwalia) writes:


>At what stage is ACL verification done for a session?
>[Of course, it is done when a session is established]. 

IMHO, the cisco should have no notion of a session.  When it's
talking IP, everything is connectionless.  The cisco has to
examine every packet to decide where to route it.  Doesn't seem
like too much more overhead to check an ACL at the same time.
One would assume that they have some-sort-of hash table.

Of course, in the European OSI world things are different.


Steven Wallace
Indiana University
wallaces@ucs.indiana.edu
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jun 90 09:05:26 PDT
From:      postel@venera.isi.edu
To:        portal!cup.portal.com!thinman@apple.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   re:  AT&T's RFS needs a TCP port number
Hi.

Port Numbers, Protocol Numbers, etc, are issued by the Internet Assigned
Numbers Authority (IANA).  See RFC-1060 for details, or e-mail to IANA@ISI.EDU.

--jon.


----- Begin Included Message -----
Date: 5 Jun 90 00:19:29 GMT
From: portal!cup.portal.com!thinman@apple.com  (Lance C Norskog)
Subject: AT&T's RFS needs a TCP port number
Sender: tcp-ip-relay@nic.ddn.mil
To: tcp-ip@nic.ddn.mil,jkrey

Dear Friends,

AT&T has their own file sharing protocol, called Remote File Sharing or RFS.
It is included (along with NFS) in UNIX V.4.

Since AT&T doesn't seem on the ball about registering an official TCP/IP
port number for RFS, how can we get this going?  We just went through a lot
of pain getting a customer's site set up with RFS over our TCP talking to
RFS over another TCP.  This protocol has been out for three years, and has
built a major installation base.  Not having an official TCP/IP port number 
for it is an oversight that must be corrected.

Lance Norskog
Sales Engineer
Streamlined Networks
408-727-9909 
----- End Included Message -----

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jun 90 06:10:43 EDT
From:      perry@MCL.Unisys.COM (Dennis Perry)
To:        jas@proteon.com, umigw!mthvax!wb8foz@handies.ucar.edu
Cc:        perry@mcl.unisys.com, tcp-ip@nic.ddn.mil
Subject:   Re:  netnews gatewaying

	Date: Mon, 4 Jun 90 12:49:31 EDT
	From: jas@proteon.com (John A. Shriver)
 	
	My concern, which I may not have made clear enough, is that the US
	Government is potentially watching us.  If they don't like what is
	being done with the money the subsidize the Internet with, they might
	cut it off.  We live in a glass house, as Barry noted.  The fellow
	with the *big* rock is in Washington, D.C., not some hacker.
	
I might illustrate the above point with a true example from my experience
while I was at DARPA 'responsible' for the Arpanet.  It seems that a note
was posted to a netnews list.  The note requested that those interested 
in helping a certain central american country to volunteer their services.
Well, the help requested was for the side of the controversy that the U.S.
government was not interested in helping, at the time.  This note was
picked up by a distribution list on the Arpanet and was eventually collected
and read by certain people located in a certain place.  I was shortly
thereafter contacted by the DOD Inspector General's Office in the Pentagon.
There inital concern was to shut down the Arpanet.  After a more logical
discussion, a course of action was identified which amounted to an
educational experience for the person posting the note and the institution
passing the note on to the Arpanet.

The above details may not be totally correct, since this happened about
four years ago now, and I try not to remember the things that are unpleasant
in my life.

dennis

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Tue 5 Jun 90 10:35:24-PDT
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        hpcc01!hpccc!munjal@hplabs.hp.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP-IP Print Spooler
Any number of tcp terminal servers can be configured in various ways
to allow rs232 printers to talk to unix spooling systems.  The three
common ways are:

	1)  hack lpd to know about tcp connections.

	2) hack the printcap files so that the appropriate filters
	   do the actual data transmission instead of lpd.  This is
	   probably the easiest.

	3) various utilities will create a /dev/foo type device which opens
	   a tcp connection to an appropriate destination when accessed.


Bill Westfield
cisco Systems.
-------
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Tue, 05 Jun 90 10:02:29 EST
From:      Carol Herre <702CH%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Networking MacIntosh Machines
I am looking for information regarding the addition of Macs to an existing
TCP/IP network.  We have a Mac system on the net using NCSA Telnet, but we
would like to have the same features for the mac that are available for the
PC with Sun's PC-NFS.  We want to be able to transparently share files that
may reside on a DEC VAX running VMS, a DEC MicroVAX running Ultrix or a Sun
Workstation.  Your assistance is appreciated.  Thank you.

Carol Herre
University of Scranton
Scranton, PA
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jun 90 10:32:31 EDT
From:      williams@nardac-dc.navy.mil (bob williams)
To:        tcp-ip@nic.ddn.mil
Subject:   add to list

     Vivian , pls add me to the list & confirm reciept.

          thank you 
                   Bob Williams
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Tue, 05 Jun 90 14:50:33 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   PC NFS Clients
Are there any Public Domain or freely available NFS Client packages
around??   Source would be nice but I could live without it.  I have
a department that would like to see if NFS is the answer. Being as I
am not exactly sure what is the question, I would like to find a cheap
way to let them try it out.  I already have a PC NFS Server, and need
only Clients to start testing.


bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Tue, 05 Jun 90 21:50:17 -0700
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        kwang@infmx.UUCP
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
I think you've missed April Fools' Day by about 2 months and 4 days!
But, if you were serious, then you are probably 9 years, 9 months, and
26 days premature in sending your message.

The Internet suite of protocols is only now coming into its own.  This
"old" technology is quite vibrant and has a lot of life flowing into it.
It is also the only thing that works today across multiple vendor lines.
Further, when meaningful comparisons can be made, it also seems to be
best technology around, as evidenced by its wide deployment and ever-maturing
market.

If Korea and Japan really have thrown out TCP/IP (which I don't believe
for a second), then they've made a strategic error.  Certainly in
Europe, the bastion of OSI, they've determined that if you want to
actually do networking, as opposed to talk about networking, then you do
it with TCP/IP.  I know of several places in Europe where the phrase
"IP router" is utterred with reverence and occasionally awe!

Although I'm hopeful that someday OSI might produce competitive
technologies, I'm not going to hold my breath.  It is not enough to do
something different, you must do it better, a lot better.  Although
service for service, the OSI effort is more ambitious than the Internet
approach, the OSI pseudo-products on the market are, by and large, much
less functional and robust than their Internet competitors.  It is not
enough to have a standard for multi-media message handling (X.400), you
must implement it fully and ubiqiutously in order to displace a
omnipresent memo-based system (RFC822).  And yet, when I survey the
X.400 offerings on the market, I still find many lacking features found
in many of today's RFC822 implementations, and at prices that are truly
astounding.  The same is true, sadly, for FTAM, and VT.  (And this
really isn't the fault of the vendors!  OSI technology is extraordinarly
expensive to produce in terms of time and people.)  I have high hopes
for OSI Directory Services (X.500), since there really isn't a
competitor in the Internet suite; but, I fear that political problems
will make a global Directory improbable.

If you are interested in transition technology, there have been papers
and books printed on this subject for nearly a decade (you might start
with Green's paper on "Protocol Conversion" in IEEE Trans. on Comm.,
March, 1986).  There are also some things specific to Internet->OSI
transition, for example one popular book on OSI devotes about 90 pages
to the topic.

/mtr
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jun 90 15:16:59 EDT
From:      stev@vax.ftp.com
To:        stan!dancer!imp@boulder.colorado.edu  (Warner Losh)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
*>Ah yes, good old security-through-obscurity.  Where have we heard that
*>before?
*
*And it doesn't work.  Never has, never will.  The only people that you
*will catch by this are the people too lazy to be inventive.  And those
*are the people least likely to crack your system anyway.

i know alot of people who have used the ITS systems at MIT. i never recall
them telling me of problems with people "breaking in" and damaging
something. what security ITS had was based on obsurity. i would like to hear
from some of the ITS wizards about how security-through-obscurity wrked for
them. 


*>If OSI is the answer, what on
*>Earth could be the question??
*
it is a very stupid question . . .. .. 
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jun 90 15:17:54 EDT
From:      stev@vax.ftp.com
To:        tcp-ip@nic.ddn.mil
Subject:   IR/microwave links


(*sigh*) the usual sources of arcane knowledge have dried up. can you help
me? 

are you using an IR or Microwave link for bridging between two buildings?
are you happy? owuld you mail me the information you have (including someone
at the comany to call)?


muchly thanx.

stev knowles
stev@ftp.com

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 00:04:36 -0700
From:      sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz)
To:        att!cbnewsh!wcs@ucbvax.Berkeley.EDU, tcp-ip@nic.ddn.mil
Subject:   Re: abolishing /etc/passwd (was Re: anonymous ftp, and the dangers thereof)
>From: att!cbnewsh!wcs@ucbvax.Berkeley.EDU  (Bill Stewart erebus.att.com!wcs)
>References: <6703@blake.acs.washington.edu>, <28764@ut-emx.UUCP>
>
>	/etc/passwd has become the traditional location for user-info
>	other than passwords, so of course it needs to be kept,
>	but I agree with the shadow-password approach that puts 
>	(encrypted) passwords in a non-world-readable file.

	just a "thought" - if the (shadow)file is non-world readable and the
	system is administered "correctly" then why bother with
	encryption at all ;-)

	Steven
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Tue, 5 Jun 90 17:42:23 EDT
From:      dertke@gateway.mitre.org (Arthur Dertke)
To:        tcp-ip@nic.ddn.mil
Cc:        ddn-people@gateway.mitre.org, dertke@gateway.mitre.org, standards@gateway.mitre.org, w31@gateway.mitre.org
Subject:   Sun Survey

I am attempting to put together a listing of any hosts employing DoD
protocols (TCP/IP, SMTP, FTP, TELNET) that cannot interoperate with hosts
employing Sun's implementation (Version 1.2 for FTP/TELNET/SMTP or Version
1.1 for TCP/IP) of DoD protocols.  I require a response by COB 7 Jun 90.
Any information that can be forwarded, no matter how minor, would be
appreciated

		Arthur Dertke




-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 15:02:29 GMT
From:      702CH@SCRVMSYS.BITNET (Carol Herre)
To:        comp.protocols.tcp-ip
Subject:   Networking MacIntosh Machines

I am looking for information regarding the addition of Macs to an existing
TCP/IP network.  We have a Mac system on the net using NCSA Telnet, but we
would like to have the same features for the mac that are available for the
PC with Sun's PC-NFS.  We want to be able to transparently share files that
may reside on a DEC VAX running VMS, a DEC MicroVAX running Ultrix or a Sun
Workstation.  Your assistance is appreciated.  Thank you.

Carol Herre
University of Scranton
Scranton, PA

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 17:03:57 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: uWave, IP, Video info
In article <4297@uwm.edu>, james@csd4.csd.uwm.edu (Jim Lowe) writes:
> 
> 	Our local TV people are in the process of setting up a microwave link
> here on campus.  They are looking at 23 Ghz systems.  I would like to be able
> to add IP traffic to their setup.
> 
> ...
> 	They said we could use one of the second audio channels to run
> data on -- using modems at 56kbps.  Personally I would like to use T1 or T2
> which should fit in the extra bandwidth.  Unfortunatly the manufacture
(Macom)
> doesn't offer any T1 capablility -- as far as we know.
> 
> 	It seems that where we want to have data they want to have video and
> visaversa.  It would be real nice if we could find a microwave system that
> did video, audio, and at least one T1.
> 
	It can be tough sharing bandwidth between two separate organizations.
But it is doable, since we have done it on a campus broadband system.

	Rather than try to shoehorn data into TV bandwidth, what if you got
separate service?  You could share the antenna (using dual feed), but then
you could get your own non-competing bandwidth for data.  The advantage is
that you could buy Ethernet-on-microwave gear and get 10Mbps for less
than the cost of T1.

	That way you wouldn't have to try to run your LAN service on
someone else's mux gear.  Keep it simple.  Since it is a private network,
you have no technical reason to adhere to telco standard interfaces.

	Kent England
	Boston University
-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 17:37:50 GMT
From:      mcsun!unido!tub!coma!reiner@uunet.uu.net  (Reiner Petersen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP source wanted for HP9000/340
In article <1990Jun1.074348.7712@ecn.nl> bernards@ecn.nl (Marcel Bernards) writes:
[] Hello NetReaders,
[] I'm looking for (PD) SLIP source for HP9000/340 series running HPUX 6.5 / 7.0.
We are interested too.

-- reiner
-- 
Reiner Petersen, TU-Berlin	BITNET: reiner at db0tui62  
				UUCP:	reiner@coma
				path:	...!pyramid!tub!coma!reiner (overseas)
					...!unido!coma!reiner	    (Europe)
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 02:13:39 -0400
From:      der Mouse  <mouse@shamash.McRCIM.McGill.EDU>
To:        nntp-managers@ucbarpa.berkeley.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Growing sentiment against gateways
> The problem is the absolute complete and total lack of any sort of
> security, trackability, or accountability in the netnews system that
> runs on usenet (uucp) and over nntp.  The problem is that most of the
> Internet mailing lists have been "gatewayed" to netnews mailgroups.

Not really.  I could generate a letter here which appeared to come from
anyone I chose; the same lack of accountability has always existed on
the Internet too.  I think the reason the Internet hasn't suffered as
much is threefold: (a) it's somewhat more difficult to fake stuff on
the Internet, (b) it's less like the "bulletin board" atmosphere that
seems to breed twits like BIFF than usenet is, and (c) it costs more to
connect to the Internet (IMO this is probably the strongest of the
three).

> I'd rather the "gateways" be made one way (out from Internet only),
> or even non-existent.

About all I can say is, start your own mailing list.  If enough people
agree with you, it'll catch on.  (If nobody agrees with you, there's
not much chance of getting your way in any event.)

> (One could argue that those "gateways" violate the access rules for
> the Internet, since they cannot verify that the message came from an
> authorized user of the Internet.)

You mean there *are* access rules for the modern Internet?  This sounds
suspiciously as though you're thinking of the DARPA rules, which (it
seems to me) don't really apply, with the demise of the ARPAnet core.

> I realize that this would deny netnews/uucp only sites access to the
> Internet mailing lists, but if their umbrella organization (usenet)
> cannot maintain professional standards of behavior, then that is
> their loss.  By implementing a system without accountability, they
> create that risk.

There is no umbrella organization to usenet.  (This is at once one of
its great weaknesses and one of its great strengths.)  I wouldn't worry
about denying them access; most to all Internet mailing lists are
perfectly happy to subscribe addresses which happen to be on uucp-only
machines - I read sf-lovers that way myself for a while, back when I
had no other way.

> Another problem due to "gatewaying" has been consistent recurring
> problems with mail loops through netnews.

And I've seen plenty of mail white-holes on the Internet.  Proves
nothing.

> I (and others) would welcome netnews being made properly accountable
> and secure.  However, not building the Received: lines may make
> netnews more efficient, but this removes all vestiges of
> accountability.  This is a key problem.

Again, I can't say much but "if you find the game unacceptable then
don't play".  If you find netnews unacceptable, don't use it.  If you
can't stand the gatewaying of netnews into (say) the tcp-ip list, then
unsubscribe.  "But there's all that useful information!"  Yes.  But it
amounts to saying that there's useful information in a forum you find
intolerable, and all I can say is "too bad"....

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu
-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 19:41:15 GMT
From:      logicon.com!Makey@nosc.mil  (Jeff Makey)
To:        tcp-ip@nic.ddn.mil
Subject:   MILNET connectivity woes
It never occurred to me that the demise of the ARPANET (net 10) would
turn the MILNET into an Internet backwater, but that is what seems to
have happened.  After more than 24 hours of getting "destination
unreachable" messages whenever I try to connect to other parts of the
universe I called the MILNET trouble desk, only to learn that our link
to the NSFnet is down.  Somehow, I thought we were better connected
than that.

USENET traffic seems to be flowing well: a testimony to the advantages
of using truly redundant paths.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: All opinions are strictly those of the author.
    Internet: Makey@Logicon.COM    UUCP: {nosc,ucsd}!logicon.com!Makey
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 19:50:33 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   PC NFS Clients

Are there any Public Domain or freely available NFS Client packages
around??   Source would be nice but I could live without it.  I have
a department that would like to see if NFS is the answer. Being as I
am not exactly sure what is the question, I would like to find a cheap
way to let them try it out.  I already have a PC NFS Server, and need
only Clients to start testing.


bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 20:02:57 GMT
From:      nsc!pyramid!infmx!kwang@decwrl.dec.com  (Kwang Sung)
To:        tcp-ip@nic.ddn.mil
Subject:   A proposal on a new newsgroup "comp.protocols.migrate.to.iso"

Hi...

	I would like to propose to create a new newsgroup "comp.protocols.
migrate.to.iso" in order to discuss about migration from old TCP/IP technology
to new OSI technology. I've been working on TCP/IP almost 10 years now. I am 
so tired of it. Since the U.S. Government is getting so poor, they cannot 
afford to change their environments so quickly. Only thing they can think of
"Security, security !!", I guess. 

	I had a chance to go back to Korea about a year ago. Not many people  
wanted to talk about TCP/IP. They think it is now pretty old technology.
Wealthy countries like Korea, Japan, they quickly threw out the old TCP/IP
technology. I know Korea has sucked all of the highest technologies from all 
over the world. 

	Anyhow, I would like to propose to create such a new newsgroup. Thanx.


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

-------------------------------------------------------------------------------
Disclaimer: The above opinion was nothing to do with my employer.
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 21:31:52 GMT
From:      sdd.hp.com!samsung!cs.utexas.edu!execu!sequoia!rpp386!jfh@ucsd.edu  (John F. Haugh II)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <1990Jun5.002739.16450@pegasus.com> richard@pegasus.com (Richard Foulk) writes:
>"Security-thourgh-obscurity" certainly isn't great.  But I haven't seen
>or heard of any evidence that it's totally useless.

The most common example of "Security Through Obscurity" is hiding the
password encryption algorithm.  Read "Password Management Guidelines"
from the NCSC [ or Dod ] [ it is one of the green books in the rainbow
series ] for information on why this is a bad idea.  Other "obscurity"
techniques have similiar problems.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org

                                            Proud Pilot of RS/6000 Serial #1472
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 22:01:09 GMT
From:      ndsuvm1.bitnet!nu021172@cunyvm.cuny.edu  (Marty Hoag)
To:        tcp-ip@nic.ddn.mil
Subject:   LANWatch User List Formed

   We have set up an e-mail list for users of the FTP Software LANWatch
program.  If there are other users of LANWatch out there who would like
to be added to the list please let me know.

   While LANWatch has its roots in netwatch our idea is to focus the
discussion on this list to the LANWatch product specifically.  Possible
topics for discussion include sharing usage ideas, discussing possible
enhancements we would like to see, etc.

-----------
Marty Hoag
ND Higher Education Computer Network    US Mail: NDSU Computer Center
Phone: (701)-237-8639  Fax: (701)-237-8541       PO Box 5164 / UCCS
Bitnet:   nu021172@NDSUVM1    (NOTE 0 = ZERO)    Fargo, ND  58105
Internet: nu021172@VM1.NoDak.EDU
UUCP:    ...!uunet!plains!vm1.nodak.edu!nu021172
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      5 Jun 90 23:30:04 GMT
From:      zaphod.mps.ohio-state.edu!uwm.edu!bionet!turbo.bio.net!lear@tut.cis.ohio-state.edu  (Eliot)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: netnews gatewaying
John Shriver:

> ...maybe research is needed elsewhere.

You might be relieved to know that there are a number of us working on
the problem, most notably Stan Barber and Brian Kantor.
-- 
Eliot Lear
[lear@turbo.bio.net]
-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 00:15:37 GMT
From:      att!cbnewsh!wcs@ucbvax.Berkeley.EDU  (Bill Stewart 201-949-0705 erebus.att.com!wcs)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <1990May31.211414.8140@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
]The reason why a zoology department (!) was a major networking hub
]at U of T for some years was that everybody else was so obsessed with
]Internet (or better) performance that they wouldn't even look at silly
]ideas like networking via low-speed modems.  

]-- 
]As a user I'll take speed over|     Henry Spencer at U of Toronto Zoology
]features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu

It's nice to see that Henry does have a balanced view of things,
regardless of what his .signature may imply :-)  (Tanenbaum, aside
from any OSI politics, is the author of Minix, which was designed to
provide features at the cost of some speed on a machine where speed
was in short supply already - a successful and nice project.)

I've always been surprised at how much you could accomplish with UUCP;
my main disagreement with the SMTP approach, other than the
appalling overcomplexity of sendmail, is that it wants to make a
connection NOW, and send traffic the whole way, rather than settling
for store-and-foreward on a message basis.  While uucp was always a
pain to maintain, the major cause of problems seemed to be
inadequate numbers of modem ports.
-- 
				Thanks;  Bill
# Bill Stewart AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 erebus.att.com!wcs
# Actually, it's *two* drummers, and we're not marching, we're *dancing*.
# But that's the general idea.
-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 01:07:48 GMT
From:      amdahl!twg.com!david@sun.com  (David S. Herron)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities
In article <9005270423.AA19852@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:
> 	The plight of many small technical businesses is that we just cannot 
> 	justify spending $30K+...
> 	  Were access fees brought inline with the level of 
> 	service offered
>Somehow dialup Internet access and SMTP don't go hand and hand in my mind,
>my estimate is that your going to have keep a connection open for about 3 hours
>every day to have some probablity of synchronizing with all the SMTP
>agents pushing mail out of their queues for the site.  Realistically you'll
>be running uucp/tcp to a site like UUPSI who is MX'ing for your domain.

Hmm..  interesting discussion.

uucp/tcp isn't a good choice because the transition through rmail
loses information and bursts messages going to multiple recipients.
There's a bunch of CSNET like tricks that can be played to make this 
work out better.  For instance, a "relay" machine could be advertised
as a fairly low cost MX alternative for the true site causing mail to
be dropped at the relay.

Oh, but does sendmail choke a bit when it has lots of undeliverable
mail in its queue?  Sigh, such is life...  :-)


Count me in as a potential customer of low cost IP service.  It'd be
real nice, when travelling, to be able to reach my home site w/o problem.
For day-day work-at-home stuff I think I can manage to arrange something
local without too much expense, especially since my home line isn't charged
as a business line.  "On the road" is another matter entirely..  
-- 
<- David Herron, an MMDF weenie, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<- Sign me up for one "I survived Jaka's Story" T-shirt!
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Wed, 06 Jun 90 08:31:38 EDT
From:      "John P. McCarthy" <EOO104@URIACC.URI.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: tn3270 terminal server
Pete,

Cisco Systems is in the stages of developing a tn3270 terminal server.
It should be in Beta in a month or so.  The terminal server also
supports SLIP.

 ---------------------------------------------------------------------
| John P. McCarthy              < EOO104 @ URIACC >    U   U RRR  III |
| Data Communications Tech.                            U   U R  R  I  |
| Academic Computer Center                             U   U RRR   I  |
| University of Rhode Island    "That's all Folks!"     UUU  R  R III |
 ---------------------------------------------------------------------
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 05:04:16 GMT
From:      vixie!asylum!karl@decwrl.dec.com  (Karl Auerbach)
To:        tcp-ip@nic.ddn.mil
Subject:   Efficiency (or lack thereof) of ASN.1. Was: Re: What is the IAB?
In article <9006030129.AA00899@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:

>About every six months there seems to be a little chinese fire drill,
>it would appear initated by some of the iconic figures of the Internet,
>who talk about performance problems with X,Y,Z areas of SNMP/ASN.1.
>All of them have been proven false, and without merit.

I've often thought Chinese Fire Drills were fun.  Consequently:

I've worked with X.409 and ASN.1 for rather a few years now.  And it
can be a real pig.  In my SNMP code, my profilers indicate that an
overly large portion of the of cycles are spent in the ASN.1
encoder/decoder.  Maybe my code is inefficient -- although I doubt it.
It's just that while ASN.1 is good for representing things like
electronic mail/mixed-media mail and stuff, it is really a bad choice
for fast transactional things.

(Actually my complaint isn't so much against ASN.1 as it is against
the BER [Basic Encoding Rules].  A few months ago there was an article
in the the SIGCOMM Computer Communications Review about an improved,
alternative BER.)

It is my opinion that the TCP/IP community would be wise to avoid
ASN.1 for any but its (original) purpose: electronic mail.

				--karl--
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 13:23:58 -0400
From:      bzs@world.std.com (Barry Shein)
To:        stev@vax.ftp.com
Cc:        stan!dancer!imp@boulder.colorado.edu, tcp-ip@nic.ddn.mil
Subject:   anonymous ftp, and the dangers thereof

>i know alot of people who have used the ITS systems at MIT. i never recall
>them telling me of problems with people "breaking in" and damaging
>something. what security ITS had was based on obsurity. i would like to hear
>from some of the ITS wizards about how security-through-obscurity wrked for
>them. 

Far be it for me to represent myself as an ITS "wizard", but I did use
the system way back when (late 70's early 80's.)

I don't think "security-by-obscurity" was really the key to whatever
success they had (maybe a little), I'd say it was more a mixture of:

	a) those were different times, the community was far different.

	b) Detection was always a real possibility on ITS, I remember
	doing something dumb (like accidently looping myself thru a
	two-layered CRTSTY) and almost immediately getting a blast
	of "WHAT THE HELL ARE YOU DOING!?" on my screen.

	c) Coupled with (b) was the fact that so many of us on the
	machines were "tourists", guests, and losing access for being
	a nuisance was a real possibility. These were the days before
	you could say "so what, I'll just go home and play with my PC".
	A lot of us really needed our accounts (I was doing research
	that really benefitted from occasional, intense access to
	Macsyma, for example, and the e-mail and all that of course.)

	d) those were different times, it was a *lot* more likely
	that whoever you were the people you might be screwing knew
	you professionally and all that. Or could get to you thru
	one layer or so in the people network (e.g. if I had fouled
	the system and someone got ticked off I was just over at
	Harvard and how hard would it have been to have a prof at
	MIT call my boss, another prof, and make my life hell?)

Detection coupled with accountability seems to me to be the real
lesson.

Just like (uh-oh, he waxes philosophic) our inner cities have become
anonymous jungles where no one knows anyone very well and cares even
less what they do, so are our networks becoming.

Try living in a small town all your life and then suddenly start
living "well" with no obvious source of income to justify it and see
how long it is before people start taking an interest in finding out
how you do that. Try the same thing in a big city, no one will care
unless the bureaucrats happen to notice it.

Somewhere in there lies the lesson I think everyone is looking for.
When systems become big and anonymous people will abuse "the system",
the people that system represents become abstracted and unimportant.

It's the price of populist visions of success.

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 14:07:43 PDT
From:      infmx!moose!kwang@uunet.UU.NET (Kwang Sung)
To:        tcp-ip@nic.ddn.mil



>From: mrose@CHEETAH.NYSER.NET (Marshall Rose) wrote:

>I think you've missed April Fools' Day by about 2 months and 4 days!
>But, if you were serious, then you are probably 9 years, 9 months, and
>26 days premature in sending your message.

Yes. I am so serious. We need to create a new newsgroup "comp.protocols.
migrate.to.iso". For instance, recently I've designed and implemented RDA 
(ISO/IEC DP 9579-1) on top of SunLink OSI and TCP/IP with RFC 1006 on my 
SPARCstation 1. Actually, I've embedded it into ISODE 6.0.  However,
a lot of customers wanted to put it on top of lpp (RFC 1085). I have a trouble
with finding those specific bridges between RFC 1085 and "pure" OSI stack.
If we create those new newsgroup, then we can have an info on migration from
"old" TCP/IP technology, SNA, or other protocols to "new" OSI technology.
As far as I know, application gateways, transport gateways, network tunnels,
protocol tunnels, etc are the only primitive methods for the migration. 
Actual environment needs higher technology.

>The Internet suite of protocols is only now coming into its own.  This
>"old" technology is quite vibrant and has a lot of life flowing into it.
>It is also the only thing that works today across multiple vendor lines.
>Further, when meaningful comparisons can be made, it also seems to be
>best technology around, as evidenced by its wide deployment and ever-maturing
>market.

I don't quite agree with it. As I've explained, since the U.S. Government is
getting poorer, they can not afford to replace the "old" technology. Moreover,
they don't want have an error especially under tactical environments. That's
why TCP/IP technology is now getting matured. But I don't think it is "best"
technology. I would call it "old" technology.  About 1983, I had a chance to
design and implement DoD protocols with MIL STD for the U.S. Government.  
I've found a whole bunch of errors on MIL STD specs. I wrote a letter to
DCA about those errors. Still 1990, they are using the same MIL STD specs. 
Do you know why ?? Because they don't have enough money to revise it. Actually,
MIL STD were written by UNISYS under some contract. 

>If Korea and Japan really have thrown out TCP/IP (which I don't believe
>for a second), then they've made a strategic error.  Certainly in
>Europe, the bastion of OSI, they've determined that if you want to
>actually do networking, as opposed to talk about networking, then you do
>it with TCP/IP.  I know of several places in Europe where the phrase
>"IP router" is utterred with reverence and occasionally awe!

Marshall Rose...   

	If you are saying same words to Korea or Japan Government/Industries/
Universities, they are going to laugh. About a year ago, when I had a chance
to go back to Korea, I was invited from several institutions and Korea 
Government Organizations which are dealing with the highest technologies in 
the world. Not many people wanted to talk about TCP/IP. They were already
migrated to OSI world. In these days, I am envolved with the projects with
Euroupe. That's why I was interested in U.K. GOSIP. They are interested in
U.S. "old" TCP/IP technology, but I don't think they will change their 
existing systems for it.   

>Although I'm hopeful that someday OSI might produce competitive
>technologies, I'm not going to hold my breath.  It is not enough to do
>something different, you must do it better, a lot better.  Although
>service for service, the OSI effort is more ambitious than the Internet
>approach, the OSI pseudo-products on the market are, by and large, much
>less functional and robust than their Internet competitors.  It is not
>enough to have a standard for multi-media message handling (X.400), you
>must implement it fully and ubiqiutously in order to displace a
>omnipresent memo-based system (RFC822).  And yet, when I survey the
>X.400 offerings on the market, I still find many lacking features found
>in many of today's RFC822 implementations, and at prices that are truly
>astounding.  The same is true, sadly, for FTAM, and VT.  (And this
>really isn't the fault of the vendors!  OSI technology is extraordinarly
>expensive to produce in terms of time and people.)  I have high hopes
>for OSI Directory Services (X.500), since there really isn't a
>competitor in the Internet suite; but, I fear that political problems
>will make a global Directory improbable.

Some of your statements I agree. Evenif OSI technologies are still 
premature, I don't see 10 years. It's slow sometimes, but the whole world 
is rapidly moving into one OSI world.

>If you are interested in transition technology, there have been papers
>and books printed on this subject for nearly a decade (you might start
>with Green's paper on "Protocol Conversion" in IEEE Trans. on Comm.,
>March, 1986).  There are also some things specific to Internet->OSI
>transition, for example one popular book on OSI devotes about 90 pages
>to the topic.

Thank you for the good reference. Actually, I've enjoyed your "The Open
Book" and ISODE 6.0 source codes more. Again, I think we need to create
a new newsgroup "comp.protocols.migrate.to.iso"  Thanx.


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

------------------------------------------------------------------------------
Disclaimer: The above opinion was nothing to do with my employer.
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 11:12:00 EDT
From:      <FILLMORE%EMRCAN.bitnet@ugw.utcs.utoronto.ca>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Multiple IP networks on one Ethernet interface
I have a (perhaps) naive question for the TCP/IP gurus:

I know that the general philosophy in interconnecting IP networks is to use
a router with two interfaces.  I would like a cheaper solution and was wondering
if anyone has got this to work in practice:

We have several organizations with TCP/IP networks, and we have a class B
network number that we divided up into subnetworks (23 bit mask) and allocate
subnetworks to the organizations.  Now the organizations want to talk to each
other.  They are all on Ethernet networks.  I would like to know if any of
the commercially-available TCP/IP packages have the capability of either:

     1)  sending and receiving IP packets for more than one subnetwork
         over the same Ethernet interface.

 or: 2)  routing packets between two or more subnetworks over the
         same Ethernet interface.

We have several spare Ethernet bridges but only one router - a Cisco.
The Cisco documentation implies that each Ethernet interface can be
configured with more than one IP network address but I haven't actually
tried it.  Does this feature have any limitations?
We also run WIN/TCP for VAX/VMS and Control Data's TCP/IP product.  Can
either of these be configured for multiple subnets on one interface?

Thanks for any insight you can provide.

________________________
Bob Fillmore, Systems Software & Communications     BITNET:  FILLMORE@EMRCAN
  Computer Services Centre,                         BIX:     bfillmore
  Energy, Mines, & Resources Canada                 Voice:   (613) 992-2832
  588 Booth St., Ottawa, Ontario, Canada  K1A 0E4   FAX:     (613) 996-2953
-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 08:20:47 GMT
From:      mcsun!hp4nl!phcoms!roes@uunet.uu.net  (Aloys Roes)
To:        tcp-ip@nic.ddn.mil
Subject:   Serial line errors and their meaning
I posted this one before but did not see it on the net. Sorry if you get it
twice.

Please help us in solving the following problem:
We have a TCP/IP wide area network in place with 9.6, 14.4 and 64Kbps
lines. For the communication equipment we have standardized on cisco TCP/IP
routers. 
Most lines show quite good performance however a few lines have reasonable 
to high error counts. These error counts are stable and seem independent of 
network load. With these error statistics we asked our telecommunication
people to improve the line quality. Of course they doubted whether the
errors were real. Therefore they started with bit-error-rate tests. These tests
show that the lines are 'perfect' i.e. no single bit or block error in 24
hours. They used different bit patterns but did not get any error.

The next thing we did was to install a PC with a 64K serial interface in
parallel to the cisco router on both ends of one 64K link. The program in
the PC analyzes the packets and monitors the link. And this is where
we really get confused. The PC also finds errors. However these errors are
of a different class and different amounts.

The link that we monitored has an average of 6000 to 10000 errors per day
on one end and a few dozens of errors on the other end. We are now focused on
the end with the high error count;
According to the cisco the errors are mainly frame errors. The PC reports
mainly CRC (or FCS) errors.

Can anyone help us getting this sorted out? What is the best way to tackle
this problem. Is there any equipment that we can put on the line and realy
trust the test-results? Has anyone faced such a problem before? Please respond
to me directly. I will post a summary,

Thanks in advance,

Aloys Roes, Philips Components, Building BC-136, |  Tel. : + 31 40 72 30 62
P.O.Box 218, 5600 MD Eindhoven, The Netherlands  |  Email: roes@seri.philips.nl
-- 
     regards,

Aloys Roes, Philips Components, Building BC-136, |  Tel. : + 31 40 72 30 62
P.O.Box 218, 5600 MD Eindhoven, The Netherlands  |  Email: roes@seri.philips.nl
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 15:29 MST
From:      LISCHKA_J@CUBLDR.Colorado.EDU
To:        TCP-IP@NIC.DDN.MIL
Subject:   VMTP
I'm designing a network in which a host running UNIX System 5 and
using TCP-IP over Ethernet sends the same message to 16
workstations.  Rather than send the same message 16 times, would
like to broadcast the message to the workstations only once.
Can't use UDP because the workstations have to acknowledge
receipt of the update.  Do you know if there are any flavors of
VMTP that will do what I need?  

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 12:43:09 EDT
From:      jas@proteon.com (John A. Shriver)
To:        CHAIBP%NUSDISCS.BITNET@cunyvm.cuny.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   desperately need an answer
At the time that RFC was written, people were still trying to run Unix
on machines like PDP-11's.  There were some very fundamental
limitations there, like a severe shortage of address space.  Several
of Dave Clark's cohorts (Larry Allen, Noel Ciappa, and Liza Martin)
were them working on a PDP-11 Unix (V6) TCP/IP.  The only code in the
kernel was half of IP (uniue ID, fragment assembly), enough UDP and
TCP to do receive port demultiplexing, and a psuedo-terminal driver.
The rest of IP and UDP were in libraries, which linked with the
application.  There were two TCP's, one optimized for server Telnet,
and a simpler lockstep one that was for user Telnet, and got used for
many other things as well.  The TCP never got clean enough to be a
library routine, but it was close.  We ran the code here for a while,
but I don't think it's running anywhere anymore.  (Genetic diversity
bites the dust!)  In quite a few ways, it was an excellent pardigm,
better than sockets in some ways, and it required far fewer buffer
copies.  It also used large contiguous buffers.  (No mbufs!)

The other reason not to want to write a TCP in the kernel, aside from
memory space problems, is that debugging inside a kernel is often a
nightmare.  (Single stepping from the console of a PDP-11/45 is not my
idea of fun.)  It is much easier to debug in user space.  Also, other
people can use the machine.

I would guess the reason that the BBN and Berkeley code wound up in
the kernel was that the programmers were more comfortable there.  They
also had the freedom to extend the facilities provided by the kernel
(which your average developer didn't have), and could provide
themselves with the sort of timer facilities they wanted.  The MIT
people were not in the business of "extending" the Unix kernel.

I have no idea if there are any decent debugging facilities in
Streams.  I suspect that most folks doing kernel network code use the
traditional Unix kernel debugging tool: printf()!

Apollo's TCP is not "in" the kernel, so it's not everybody even yet.
Of course, MS-DOS has not kernel, at least not one worth mentioning.

There can be arguments for putting TCP in the kernel for system
security.
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 16:15:30 PDT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        fillmore%emrcan.bitnet%ugw.utcs.utoronto.ca@TGV.COM
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Multiple IP networks on one Ethernet interface
> I know that the general philosophy in interconnecting IP networks is to use
> a router with two interfaces.  I would like a cheaper solution and was wondering
> if anyone has got this to work in practice:
>
> We have several organizations with TCP/IP networks, and we have a class B
> network number that we divided up into subnetworks (23 bit mask) and allocate
> subnetworks to the organizations.  Now the organizations want to talk to each
> other.  They are all on Ethernet networks.  I would like to know if any of
> the commercially-available TCP/IP packages have the capability of either:
>
>      1)  sending and receiving IP packets for more than one subnetwork
>	   over the same Ethernet interface.
>
>  or: 2)  routing packets between two or more subnetworks over the
>	   same Ethernet interface.

    Our MultiNet TCP/IP product for VMS can do this; it isn't
documented but customer service can give you the instructions for
enabling it.  We don't want to encourage people to run multiple
network numbers on the same cable because of the potential for
problems with broadcasts.

    Basically we allow you to create two `interfaces' for one ethernet
controller.  Each has its own address, and you can gateway between
them, run routing protocols, etc, just as if you had multiple
controllers on separate cables.  This would allow you to do with (1)
and (2) above.

    If you have any other questions, give me mail or a call at
800-TGV-3440 or 408-427-4366.  If you'd like to try it, we have an
evaluation/trade-in program so I can get a copy right out to you.

						    Kenneth Adelman
						    TGV, Inc.
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 12:31:38 GMT
From:      EOO104@URIACC.URI.EDU ("John P. McCarthy")
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 terminal server

Pete,

Cisco Systems is in the stages of developing a tn3270 terminal server.
It should be in Beta in a month or so.  The terminal server also
supports SLIP.

 ---------------------------------------------------------------------
| John P. McCarthy              < EOO104 @ URIACC >    U   U RRR  III |
| Data Communications Tech.                            U   U R  R  I  |
| Academic Computer Center                             U   U RRR   I  |
| University of Rhode Island    "That's all Folks!"     UUU  R  R III |
 ---------------------------------------------------------------------

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 18:48:00 CST
From:      "Dan Kellen" <kellen@uv4.eglin.af.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   I need help with subnetting
   I need some routing/subnetting help.

   We have a class B network.  We are not doing subnetting, but have been
   assigning addresses as if we were; each building has a unique third octet.
   The buildings are tied together with ethernet bridges, not IP routers.

   We have a department that has just aquired several SUN's and want's to
   use one as a gateway to the others.  I gave them IP addresses with a new
   third octet for all of there machines, and an address with the third
   octet of the building they are in, for the second interface on the 
   gateway machine.

   Now comes the problem.  The SUN gateway doesn't gateway!  I can get to 
   the gateway from the main network, but not to/from the other SUN's.

   Since I'm not doing subnetting, the SUN's two interfaces have different 
   IP addresses, the same netmask, but are on two different Ethernet's.  

   I then changed the netmask of the interface to the other SUN's to mask 
   the third octet.  Now the SUN's can talk.  But, the SUN's IP interface 
   to the rest of the network doesn't work.  

   What am doing wrong?


   How about a picture:


        network: 129.61.2.0                network: 129.61.9.0
        netmask: 255.255.0.0               netmask: 255.255.255.0


                                                       +-----+
                                                       |     |
                    /\                           +-----| SUN |
                    |                            |     |     |
                    |             +-----+        |     +-----+
                    |      129.61 |     | 129.61 |
                    |-------------| SUN |--------+
                    |        2.40 |     | 9.2    |
                    |             +-----+        |     +-----+
                    |                            |     |     |
                    |                            +-----| SUN |
                    \/                                 |     |
                                                       +-----+

   Any help appriciated.
   Dan
   kellen@uv4.eglin.af.mil

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 13:00:48 GMT
From:      clyde.concordia.ca!s3!vaillan@uunet.uu.net  (Clement Vaillancourt)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IR/microwave links
In article <9006051917.AA24382@vax.ftp.com> stev@VAX.FTP.COM writes:
>
>
>are you using an IR or Microwave link for bridging between two buildings?
>are you happy? owuld you mail me the information you have (including someone
>at the comany to call)?
>
>
>stev knowles
>stev@ftp.com


We are ordering now a microwave link for bridging between two buildings
located 1.2 km apart. We are buying from:

	Microwave Bypass Systems, Inc.
	25 Braintree Hill Office Park,
	Braintree, MA 02184

	contact: Mr. Robert Cuomo at 617-843-8260

I have seen this product operating at Interop89 in San Jose last October.
The total installed cost quoted to us is 39,696 US$ including licensing.

I have heard that IR equipment is also used in Toronto for a distance of
800 meters and it can work if you can see the other building. That IR equipment
is sold by: LCI at 1848 Charter Lane, Suite F Lancaster PA USA 
            +1 717 396 9831.
--
   Clement Vaillancourt,             |   Institut de Recherche d'Hydro-Quebec
   Network Manager                   |        1800 Montee Ste-Julie, Varennes
                                     |             P. Quebec, Canada, J3X 1S1
   Email: vaillan@ireq.hydro.qc.ca   |  Tel: 514-652-8238 / Fax: 514-652-8309
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jun 90 01:24:17 -0700
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
To:        tcp-ip@nic.ddn.mil
Subject:   Mourning of the passing of the ARPANET

Folks, it appears that the ARPANET has quietly passed away into the annals
of network history.  June 1 was the official cut off date I believe, and I
did some traceroute's to a net 10 host and not even the DDN Core knew
about a route to net 10!  Not even the Mailbridge at BBN in Cambridge.

Script started on Thu Jun  7 01:11:44 1990
cincsac [37]: traceroute -g moffett-fld-mb.ddn.mil 10.0.0.51
traceroute to 10.0.0.51 (10.0.0.51), 30 hops max, 38 byte packets
 1  arc-nas-gw (128.102.16.5)  0 ms  0 ms  0 ms
 2  arc-psn-gw (192.52.195.6)  20 ms  0 ms  20 ms
 3  MOFFETT-FLD-MB.DDN.MIL (26.20.0.16)  60 ms  80 ms  60 ms
 4  MOFFETT-FLD-MB.DDN.MIL (26.20.0.16)  60 ms !N  40 ms !N  60 ms !N
cincsac [38]: traceroute -g cambridge-mb.ddn.mil 10.0.0.51
traceroute to 10.0.0.51 (10.0.0.51), 30 hops max, 38 byte packets
 1  arc-nas-gw (128.102.16.5)  20 ms  20 ms  0 ms
 2  arc-psn-gw (192.52.195.6)  0 ms  20 ms  0 ms
 3  CAMBRIDGE-MB.DDN.MIL (26.1.0.49)  560 ms  500 ms  640 ms
 4  CAMBRIDGE-MB.DDN.MIL (26.1.0.49)  580 ms !N  480 ms !N  480 ms !N
cincsac [39]: exit
exit

script done on Thu Jun  7 01:12:36 1990

Perhaps a moment of silence is in order...

						Thanks,
						   Milo

PS For those of you not familiar with traceroute, the first shows BMILAMES
sending back a network unreachable message for net 10, and the latter is a 
net unreachable from a gateway at BBN.  The -g option specifies a source
route through the MILNET gateway.  NSFNET doesn't know about it either...
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 21:51:22 -0400
From:      bzs@world.std.com (Barry Shein)
To:        crdgw1!sixhub!davidsen@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   anonymous ftp, and the dangers thereof

>  I don't know that I have any objections to shadow password. WHy give
>the show away? It's like having L.sys or Systems world readable. I
>accept that I can't keep the encryption a secret, so why give the
>encrypted passwords away. I don't see what this has to do with
>security-through-obscurity here.

The objection to shadow password files is that it's an admission that
hiding the file contents is critical to the entire system's security
(if not, why hide them?) Don't argue that it merely "improves" the
existant security, fine, you obviously decide for yourself so you can
believe whatever you like. Multiplicative probabilities aren't
compelling arguments.

If for any reason you suspect that someone has obtained a copy of that
file you have to accept that your system's security has been broached.

You have to view this more in the light of a person with authority
coming to you, asking you what your security relies on, and deciding
that it's critical you now prove that no one has ever walked out of
your center with a copy of the shadow password file, a dump tape, etc.
You've opened yourself up to that (valid) criticism.

The original scheme, keeping it publicly readable, removed a target
for attack (capturing the mere contents.) It relied on good encryption
and good password management. Where either or both of those is lacking
the method is not sufficient.

My tendency would be to improve the encryption methods and password
management and leave it publicly readable.

For better encryption, I've suggested schemes, such as per-site
perturbation of the algorithms. At least that makes it (nearly)
impossible for someone to walk away with a copy of your password file
and crack it on another system.

For password management, password-changers that are continuously being
improved (sources are critical!) to disallow "simple" passwords, and
of course education. If you don't educate users then what's the point?
They'll just hand their passwords out or write them on their white
boards, etc.

L.sys is a problem, but less so because most uucp connections only
allow mail and/or news transport even if someone uses it to break in.

I'm not making light of that, but they really don't get a lot more
with that password file than anyone has who telnets to an SMTP port
(without any password.)  Obviously if it's broached passwords must be
changed, but the potential for real damage via uucp logins is fairly
limited.

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 16:22:23 GMT
From:      helios.ee.lbl.gov!me10.lbl.gov!milburn@ucsd.edu  (John Milburn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP source wanted for HP9000/340
In article <703@coma.UUCP> reiner@coma.UUCP (Reiner Petersen) writes:
>In article <1990Jun1.074348.7712@ecn.nl> bernards@ecn.nl (Marcel Bernards) writes:
>[] Hello NetReaders,
>[] I'm looking for (PD) SLIP source for HP9000/340 series running HPUX 6.5/7.0.
>We are interested too.
>
>-- reiner

Well, this makes about 50 requests over the last year or so in this forum,
with absolutely no response from hp. The response is no better from
sales reps :-). Is there any hope that slip or cslip will be available
sometime in the near future, or should I just give up and buy a couple
or Sun machines? This is important! Please let us know.

-jem

JEMilburn@lbl.gov  ...!ucbvax!lbl.gov!JEMilburn
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 16:32:44 GMT
From:      stealth.acf.nyu.edu!brnstnd@nyu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <PMY$TW?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:
> All this emphasis on turning off tftp and waiting for shadow password 
> files may be clouding the simpler and more effective solution.  Force 
> users to pick good passwords!  Something with some non-alpha 
> characters and mixed case (not the first letter capital).  

Oh, wonderful. Changing 3 bits of information per character to 3.2 bits
per character will slow down the average ``crack'' from fifteen million
encryptions to forty million encryptions. Big deal.

---Dan
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 16:38:38 GMT
From:      stealth.acf.nyu.edu!brnstnd@nyu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <1990Apr21.222928.24498@Solbourne.COM> Warner Losh writes:
> What is needed is a good guide to how to setup anonymous FTP correctly
> so that nobody can steal any real files.

Yeah. Let's start by criticizing the SRI White Paper's recommendations.
It says ``you may wish'' to remove all non-ftp accounts from the passwd
file inside the ftp directory; it should say ``you should, no matter
what.'' It recommends creation of ~ftp/pub, owner ftp, mode 777; that
should be mode 577. Anyone want to continue this list?

---Dan
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 16:44:31 GMT
From:      stealth.acf.nyu.edu!brnstnd@nyu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <1990Jun3.152118.4758@cunixf.cc.columbia.edu> shenkin@cunixf.cc.columbia.edu (Peter S. Shenkin) writes:
  [ if passwords are ``good,'' they'll be written down ]
> Not that I have answers....

I have an answer, which I posted to alt.security a few weeks ago but
which was obliterated by cmcl2's alt.* distribution. Here's another
copy.

---Dan

From: brnstnd@stealth.acf.nyu.edu
Newsgroups: alt.security
Subject: How to get the advantages of all types of passwords
Message-ID: <11082:May1722:49:4990@stealth.acf.nyu.edu>
Date: 17 May 90 22:49:49 GMT
References: <1990May3.211534.11818@Solbourne.COM> <iLmNi7w161w@halcyon.wa.com> <1990May9.185628.9241@utzoo.uucp>
Reply-To: brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
Organization: IR
Lines: 23
X-Original-Subject: Re: Improved password cracker - add a sleep()

User-chosen passwords are easily guessable.

Random system-generated passwords are written down all too often.

Expired passwords have been shown to make password guessing easier, and
they don't provide any advantage.

What's the solution? Mix 'n' match. A password has, say, two parts: one
chosen by the user and neither expired nor restricted, one generated
randomly by the system and changed periodically (some sizable fraction
of a year). The first part is NEVER written down; users are told that if
they write down the first part, they'll be drawn and quartered. The
second part is almost certainly written down, typically on a piece of
paper in the user's desk; users are explicitly told that this is okay.

Because the first part of the password is chosen by the user and never
written down, a casual cracker can't find it by just snooping around an
office. Because the second part of the password is chosen by the system,
brute-force cracking will fail miserably.

I proposed this last year (in u-w) but never saw much response.

---Dan
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 16:50:26 GMT
From:      messy!mo@bellcore.com  (Michael O'Dell)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: desperately need an answer
(1) the limitations aren't that severe because it turns out
implementing TCP/IP isn't as piggish as first thought.
Further, previous experience with putting NCP outside the kernel
for just the suggestes reasons was a cosmic lose in terms of
complexity.

but the important one is....

(2) SPEED!!!!! The last thing in the world you want is a few
extra context switches per packet and per network read/write.
Putting it ouside the kernel almost guarantees extra data copies
as well as the extra context switches.

So, aside from being gratuitously complex and hideously slow, the
idea is great.  

	-Mike
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 21:04 EDT
From:      Fitch@DOCKMASTER.NCSC.MIL
To:        tcp-ip@NIC.DDN.MIL
Cc:        Fitch@DOCKMASTER.NCSC.MIL
Subject:   SUN <-> IBM FTP Performance

I'm looking for performance numbers using the FTP protocol between a SUN
and an IBM mainframe over an ETHERNET.  I don't have all the necessary
machines so I thought I'd appeal to the net.  The ideal situation would
provide numbers for transfers between SUN 4 and a 4341 and for transfers
between a SUN and a 3090 over an ETHERNET.  I'd appreciate it if someone
could run a few GETs and PUTs with the SUN as the client machine for say
a 1 MB file and pass the KBps numbers along to me.  I'd also like a
quick summary of your configuration; e.g., the FTP/TCP products you
used, if you went TCP end to end, if a front end or protocol translator
was involved, if the mainframe I/F was a channel attachment not, etc.
Of course, any words of wisdom explaining the performance for this
configuration are welcome.  Thanks much.

--Jack Fitch@dockmaster.ncsc.mil

PS I suppose I could also be interested in SUN-to-9370 rates as well...
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 17:06:11 GMT
From:      mcsun!ukc!stc!datlog!gjack@uunet.uu.net  ( Graham Jack)
To:        tcp-ip@nic.ddn.mil
Subject:   State-of-the-art utilities

I'm currently investigating how closely common TCP/IP software matches
the Host Requirements. So far I've only looked at the 4.3BSD sources
and tried out the products from a few suppliers.
It seems that you can swap out the Telnet, BIND, etc supplied with a system and
replace them with P-D versions.
So one of the things I now need to look at is the
'state-of-the-art' versions of various utilities to see how they
shape up. I suppose I'm really interested in versions in current use
rather than 'beta' software being evaluated.

I have gleaned some version numbers from the vanilla 4.3BSD sources and
a quick look at the news groups gave me some hints for later versions.
Can anybody out there help me by filling in the gaps in the
table below and telling me where software is available (by anonymous FTP
or uucp).

	Program		Vanilla		Latest
			(4.3BSD)
	--------	-------		------
	Telnet Client	5.16		????
	Telent Server	5.18		????
	FTP Client	????		????
	FTP Server	4.105		????
	BIND		4.3		4.8.1?
	Sendmail	5.52		5.61+IDA?

BTW: what is 'IDA'?
-- 
Regards,
	    Graham Jack, Data Logic.
	    <gjack@datlog.co.uk>
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 18:01:57 GMT
From:      usc!snorkelwacker!paperboy!meissner@ucsd.edu  (Michael Meissner)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <19001:Jun616:38:3890@stealth.acf.nyu.edu>
brnstnd@stealth.acf.nyu.edu writes:

| In article <1990Apr21.222928.24498@Solbourne.COM> Warner Losh writes:
| > What is needed is a good guide to how to setup anonymous FTP correctly
| > so that nobody can steal any real files.
| 
| Yeah. Let's start by criticizing the SRI White Paper's recommendations.
| It says ``you may wish'' to remove all non-ftp accounts from the passwd
| file inside the ftp directory; it should say ``you should, no matter
| what.'' It recommends creation of ~ftp/pub, owner ftp, mode 777; that
| should be mode 577. Anyone want to continue this list?

Actually I prefer to customize the passwd file differently -- you
remove all users who don't have files stored in the ftp archives, and
put *'s for the passwords of all remaining users.  This way, when
somebody does a dir on the files, you have a username to mail to for
questions, and the like, but still does not give out the encrypted
password.
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA

Catproof is an oxymoron, Childproof is nearly so
-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 18:19:57 GMT
From:      hayes!wisner@decwrl.dec.com  (Bill Wisner)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
The passwd file in my anonymous FTP heirarchy has all encrypted
passwords replaced with asterisks. What's the problem?

Bill Wisner <wisner@hayes.fai.alaska.edu> Gryphon Gang Fairbanks AK 99775
"Remember, some net.personalities are basically insane."
-- Karl Lehenbauer <karl@sugar.hackercorp.com>
-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 19:00:53 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: AT&T's RFS needs a TCP port number

In article <9006051605.AA28474@bel.isi.edu>, postel@VENERA.ISI.EDU writes:
> 
> Since AT&T doesn't seem on the ball about registering an official TCP/IP
> port number for RFS, how can we get this going?

I've been informed that this is indeed in progress, and was even
before this posting.

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 19:11:10 GMT
From:      mentor.cc.purdue.edu!nelson@purdue.edu  (J. Nelson Howell)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Interesting uses of networking
In article <caOiyei00WB9AJe1Bg@andrew.cmu.edu> aw0g+@ANDREW.CMU.EDU (Aaron Wohl) writes:

        ...

>Glen Marcy (gm0w@cs.cmu.edu) hacked a finger server on a tops20 to
>connect to an rs232 line to the airconditioning computer on the roof.
>One could finger temperature@te.cc.cmu.edu.
>
>Someone is cs (try laurence butcher@cs.cmu.edu) wired up the coke machine.
>You could finger coke@something and see how cold the coke was.

Actually, it did much more.  It would tell you when the machine was filled,
the temperature of each flavor, the last purchase of each flavor, and a few
things I have forgotten.  It was quite impressive to undergrads that were
trying to figure out the basics of networking (myself included at the time).

Come to think of it, it's still pretty impressive :-)


J. Nelson Howell                       | System Programmer
nelson@midas.mgmt.purdue.edu  Internet | Krannert Graduate School of Management
NELSON@PURCCVM                BITNET   | Purdue University
                                       | West Lafayette, IN
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 19:23:59 GMT
From:      nsc!pyramid!infmx!kwang@decwrl.dec.com  (Kwang Sung)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"

>From: mrose@CHEETAH.NYSER.NET (Marshall Rose) wrote:

>I think you've missed April Fools' Day by about 2 months and 4 days!
>But, if you were serious, then you are probably 9 years, 9 months, and
>26 days premature in sending your message.

Yes. I am so serious. We need to create a new newsgroup "comp.protocols.
migrate.to.iso". For instance, recently I've designed and implemented RDA 
(ISO/IEC DP 9579-1) on top of SunLink OSI and TCP/IP with RFC 1006 on my 
SPARCstation 1. Actually, I've embedded it into ISODE 6.0.  However,
a lot of customers wanted to put it on top of lpp (RFC 1085). I have a trouble
with finding those specific bridges between RFC 1085 and "pure" OSI stack.
If we create those new newsgroup, then we can have an info on migration from
"old" TCP/IP technology, SNA, or other protocols to "new" OSI technology.
As far as I know, application gateways, transport gateways, network tunnels,
protocol tunnels, etc are the only primitive methods for the migration. 
Actual environment needs higher technology.

>The Internet suite of protocols is only now coming into its own.  This
>"old" technology is quite vibrant and has a lot of life flowing into it.
>It is also the only thing that works today across multiple vendor lines.
>Further, when meaningful comparisons can be made, it also seems to be
>best technology around, as evidenced by its wide deployment and ever-maturing
>market.

I don't quite agree with it. As I've explained, since the U.S. Government is
getting poorer, they can not afford to replace the "old" technology. Moreover,
they don't want have an error especially under tactical environments. That's
why TCP/IP technology is now getting matured. But I don't think it is "best"
technology. I would call it "old" technology.  About 1983, I had a chance to
design and implement DoD protocols with MIL STD for the U.S. Government.  
I've found a whole bunch of errors on MIL STD specs. I wrote a letter to
DCA about those errors. Still 1990, they are using the same MIL STD specs. 
Do you know why ?? Because they don't have enough money to revise it. Actually,
MIL STD were written by UNISYS under some contract. 

>If Korea and Japan really have thrown out TCP/IP (which I don't believe
>for a second), then they've made a strategic error.  Certainly in
>Europe, the bastion of OSI, they've determined that if you want to
>actually do networking, as opposed to talk about networking, then you do
>it with TCP/IP.  I know of several places in Europe where the phrase
>"IP router" is utterred with reverence and occasionally awe!

Marshall Rose...   

	If you are saying same words to Korea or Japan Government/Industries/
Universities, they are going to laugh. About a year ago, when I had a chance
to go back to Korea, I was invited from several institutions and Korea 
Government Organizations which are dealing with the highest technologies in 
the world. Not many people wanted to talk about TCP/IP. They were already
migrated to OSI world. In these days, I am envolved with the projects with
Euroupe. That's why I was interested in U.K. GOSIP. They are interested in
U.S. "old" TCP/IP technology, but I don't think they will change their 
existing systems for it.   

>Although I'm hopeful that someday OSI might produce competitive
>technologies, I'm not going to hold my breath.  It is not enough to do
>something different, you must do it better, a lot better.  Although
>service for service, the OSI effort is more ambitious than the Internet
>approach, the OSI pseudo-products on the market are, by and large, much
>less functional and robust than their Internet competitors.  It is not
>enough to have a standard for multi-media message handling (X.400), you
>must implement it fully and ubiqiutously in order to displace a
>omnipresent memo-based system (RFC822).  And yet, when I survey the
>X.400 offerings on the market, I still find many lacking features found
>in many of today's RFC822 implementations, and at prices that are truly
>astounding.  The same is true, sadly, for FTAM, and VT.  (And this
>really isn't the fault of the vendors!  OSI technology is extraordinarly
>expensive to produce in terms of time and people.)  I have high hopes
>for OSI Directory Services (X.500), since there really isn't a
>competitor in the Internet suite; but, I fear that political problems
>will make a global Directory improbable.

Some of your statements I agree. Evenif OSI technologies are still 
premature, I don't see 10 years. It's slow sometimes, but the whole world 
is rapidly moving into one OSI world.

>If you are interested in transition technology, there have been papers
>and books printed on this subject for nearly a decade (you might start
>with Green's paper on "Protocol Conversion" in IEEE Trans. on Comm.,
>March, 1986).  There are also some things specific to Internet->OSI
>transition, for example one popular book on OSI devotes about 90 pages
>to the topic.

Thank you for the good reference. Actually, I've enjoyed your "The Open
Book" and ISODE 6.0 source codes more. Again, I think we need to create
a new newsgroup "comp.protocols.migrate.to.iso"  Thanx.


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

------------------------------------------------------------------------------
Disclaimer: The above opinion was nothing to do with my employer.
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 20:33:37 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!hubcap!mmccann@ucsd.edu  (Mike McCann)
To:        tcp-ip@nic.ddn.mil
Subject:   Printing from a PC to a DECserver printer
I am looking for a piece of software that will allow a PC with an
Ethernet card to print to a printer that is attached to a DECserver.

I would like to make this transparent to the user by having LPT1:
remapped so that it prints automatically to the printer on the
DECserver.

I welcome any suggestions or comments on how this could be done.
Spooling on a UNIX or VMS machine would be fine as well.

Thanks for the help in advance,

-- 
Mike McCann       (803) 656-2721   Internet = mmccann@hubcap.clemson.edu 
Engineering Computer Operations      Bitnet = mmccann@clemson.bitnet
Clemson University
Clemson, S.C. 29634-2803         DISCLAIMER = I speak only for myself.
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      Thu 7 Jun 90 01:13:13-EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        kmeyer@decwrl.dec.com
Cc:        tcp-ip@nic.ddn.mil, lynch@A.ISI.EDU
Subject:   Re: toll restrictors
Kraig,  You bring up a very cogent point>  To wit, does a particular OS
have the flexibility to control access on a per user basis to particular
system resources. In the case of current interest you are interested
in network access.  In the late 70's I was associated with a computer
service company (Tymshare) and we had users who cam in via Tymnet and
users who cam in via Arpanet and we had to be able to permit/deny
access on a per user basis to "the other network".  We put th ehooks 
for this into our operating system, Tenex (the precursor of TOPS20).
It was a simple hack to put in the OS.  The only hair/pain was to
then keep the list of permissions updated whenever we created a new user.

IN fact, I have found that the mechanism part(s) of security and access
control are very easy for the OS enforcement part.  The huge and ugly 
part has to do with the administrative part of actually creating
and modifying allthe lists of permissions on a per entity basis.

I'm sure Unix could be hacked a bit to do the same as Tenex did many
years ago.

Dan
-------
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 22:34:01 GMT
From:      excelan!keith@ames.arc.nasa.gov  (Keith Brown)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"

]I've been working on TCP/IP almost 10 years now. I am 
]so tired of it. Since the U.S. Government is getting so poor, they cannot 
]afford to change their environments so quickly. Only thing they can think of
]"Security, security !!", I guess. 
]
]	I had a chance to go back to Korea about a year ago. Not many people  
]wanted to talk about TCP/IP. They think it is now pretty old technology.
]Wealthy countries like Korea, Japan, they quickly threw out the old TCP/IP
]technology. I know Korea has sucked all of the highest technologies from all 
]over the world. 

I would just like to point out that marker pens should only be used for
writing on whiteboards, not for sniffing.....
----------------------------------------------------------------------------
Keith Brown                                      Phone: (408) 473 8308
Novell San Jose Development Centre               Fax:   (408) 433 0775
San Jose, California 95131                       Net:   keith@novell.COM
----------------------------------------------------------------------------
-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Thu, 07 Jun 90 10:45:51 -0700
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        karl@asylum.sf.ca.us
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Efficiency (or lack thereof) of ASN.1
I think history is being a little loosely interpreted here.  The
committee working on X.400 was the first to define an OSI application.
As such, they defined X.409(84).  When other OSI applications began
being defined, the abstract syntax/transfer syntax (ASN.1 and BER) were
split out into ISO8824/ISO8825 and X.208/X.209.  It is true that the
original use of the ASN.1 stuff was MHS, but ASN.1 was not invented
solely for that purpose--the MHS people just happened to be in the
position to need it first.

The strength of something like ASN.1 is its ability to describe a wide
range of data structures using a machine-parsable notation.  One of the
design goals of the OSI people involved was to make sure that it did not
limit the precision of the things being described.  Hence, INTEGERs
needn't be of fixed length, etc.  A side-effect of this is that you need
an encoding algorithm which can accommodate variable length data.

In theory, you can use many different algorithms to encode things
defined using ASN.1, but at present, only one such algorithm has been
standardized, the Basic Encoding Rules.  The reference by Huitema you
are referring to is a second algorithm defined at INRIA, based on Sun's XDR.

The motivation for using ASN.1 in the SGMP and SNMP is simple:
industry has already decided on the lingua franca of the 90's (ASN.1/BER),
and it is counter-productive to invent

		  yet-another-description-and-encoding-standard

So, the goal was to select a small, workable subset that could be
implemented easily, and allowed for some useful optimizations.  Then, if
an implementor is really concered about efficiency, then the routines
can be done by hand with great care. (Probably the most important part
is to have efficient encode/decode support for integers, which
interestingly enough is where the performance characteristics of BER and
XDR differ the most.  By optimizing in once place, you can dramatically
improve the speed of your encoder.)

Using the BER, rather than a non-standard algorithm, over an optimized
ASN.1 was chosen because regardless of the availability of alternate
encoding algorithms, anyone implementing ASN.1 still has to implement
the BER since that's what all ASN.1-capable applications use.  So, if
you are going to ask a vendor to implement something else for their
ASN.1 library to use with application X, you have essentially told them
to do twice as much work.

Since the time of the initial SGMP work, experience has shown that if
you limit use of ASN.1 carefully, you can implement an efficient BER
mapping, this seems to be the most reasonable compromise.

/mtr
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      6 Jun 90 23:25:08 GMT
From:      greywolf@unisoft.UUCP (The Grey Wolf)
To:        alt.security,comp.protocols.tcp-ip,alt.sys.sun
Subject:   Re: anonymous ftp, and the dangers thereof

In article <PMY$TW?@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:
>All this emphasis on turning off tftp and waiting for shadow password 
>files may be clouding the simpler and more effective solution.  Force 
>users to pick good passwords!  Something with some non-alpha 
>characters and mixed case (not the first letter capital).  
>
>Neither turning off tfpd or even shadow passwords will protect you from 
>local users or people who used to have root.

I'm rather new to some of this stuff, so please excuse my ignorance.

To what extent does one disable tftp (or did the original user mean
anonymous ftp)?

If, indeed, one disables tftp, why is this done?  tftp is about the only
way to boot a machine over the network if one needs to reformat the local
disk, and we don't have QIC drives or 9-track drives for every machine, and
hooking them up/disconnecting them is a pain in the ass.  I'd much rather
not have to move the workstation if I can avoid it.

Please don't flame me about hardware or the inadequacies of our setup;
it would be a waste of time and it would completely beg the question.

-- 
MORALITY IS THE BIGGEST DETRIMENT TO OPEN COMMUNICATION.
/earth: minimum percentage of free space changes from 10% to 0%
should optimize for space^H^H^H^H^Hintelligence with minfree < 10%

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 00:48:00 GMT
From:      kellen@UV4.EGLIN.AF.MIL ("Dan Kellen")
To:        comp.protocols.tcp-ip
Subject:   I need help with subnetting


   I need some routing/subnetting help.

   We have a class B network.  We are not doing subnetting, but have been
   assigning addresses as if we were; each building has a unique third octet.
   The buildings are tied together with ethernet bridges, not IP routers.

   We have a department that has just aquired several SUN's and want's to
   use one as a gateway to the others.  I gave them IP addresses with a new
   third octet for all of there machines, and an address with the third
   octet of the building they are in, for the second interface on the 
   gateway machine.

   Now comes the problem.  The SUN gateway doesn't gateway!  I can get to 
   the gateway from the main network, but not to/from the other SUN's.

   Since I'm not doing subnetting, the SUN's two interfaces have different 
   IP addresses, the same netmask, but are on two different Ethernet's.  

   I then changed the netmask of the interface to the other SUN's to mask 
   the third octet.  Now the SUN's can talk.  But, the SUN's IP interface 
   to the rest of the network doesn't work.  

   What am doing wrong?


   How about a picture:


        network: 129.61.2.0                network: 129.61.9.0
        netmask: 255.255.0.0               netmask: 255.255.255.0


                                                       +-----+
                                                       |     |
                    /\                           +-----| SUN |
                    |                            |     |     |
                    |             +-----+        |     +-----+
                    |      129.61 |     | 129.61 |
                    |-------------| SUN |--------+
                    |        2.40 |     | 9.2    |
                    |             +-----+        |     +-----+
                    |                            |     |     |
                    |                            +-----| SUN |
                    \/                                 |     |
                                                       +-----+

   Any help appriciated.
   Dan
   kellen@uv4.eglin.af.mil

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 01:45:48 GMT
From:      auspex!ntrlink!pjj@uunet.uu.net  (Patrick Johnston)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP Between PCs and Mainframes...What Physical Layers?
In article <30494@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
>Using IBM's mainframe TCP-IP implementations and OS/2 Extended Edition's
>TCP/IP, what physical layers can be used?  I assume Ethernet at minimum,
>but what about token ring, and what about SDLC since that is how the
>vast majority of PCs are linked to mainframes?  Also, what about the case
>where a PC goes through a gateway that emulates a 3174 and is connected
>by modem to a 3725?

IBM's TCP/IP supports ethernet in three ways:

1. 8323 (industrializd PC AT with an ungerman bass ethernet card)
2. 3172 (PS/2 386 version of the 8232 - internal ethernet card)
3. 9370 802.3 card with communications processor

You can also use any device that supports the CETI channel protocol
(such as BTI's box or Interlink's 3722)


Token ring is supported in the same three ways.  There has been no
announced support for the 3174 TIC option in either the 3174L or 3174R
controllers.  There is no announced support in the 3270 workstation
software version 3 (the stuff that connected a PC to a 3745 via SDLC)
and there is no announced support for OS/2 comm manager for IBM's TCP/IP
software.

IBM's TCP/IP software can communication with another mainframe via SDLC
lines (via LU0). The above ways are the only ways that I know on getting
TCP/IP out of an IBM mainframe.  

Hmmm... UUCP to a mainframe via a 3745....  I'll have to bring
that up at my next staff meeting....
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 02:18:00 GMT
From:      CHAIBP@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   desperately need an answer



Clark, in his RFC 817, said that kernel implementation
of TCP/IP would subject to many system limitations and
suggested that only part of TCP/IP should be placed in
the kernel, leaving the rest in the user processes.

Now, what I don't understand is that why everybody still
put the entire TCP/IP in the kernel - AT&T system V,
Sun BSD Unix and many others all does just that. Does
that mean that those limitations are never faced by them
or that they have actually took his advice but provided the
interfaces to the user processes in a way that gives
them the illusion of interfacing with the kernel ?

Desperately need an answer on that ! Please give me
an answer if you do have one.

Chai

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jun 90 13:58:40 -0700
From:      sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz)
To:        drears@PICA.ARMY.MIL, sms@WLV.IMSD.CONTEL.COM
Cc:        att!cbnewsh!wcs@ucbvax.berkeley.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  abolishing /etc/passwd (was Re: anonymous ftp, and the dangers thereof)
Dennis:

>From drears@PICA.ARMY.MIL Thu Jun  7 13:16:46 1990
>>"Steven M. Schultz" <sms@wlv.imsd.contel.com> writes:
>>	just a "thought" - if the (shadow)file is non-world readable and the
>>	system is administered "correctly" then why bother with
>>	encryption at all ;-)
>
>   Just in case one of the system admins is a bad guy or becomes a
>bad guy.  I have three passwords for 30+ systems of which I only
>administrate 12 of them.  If my password was available in the clear to
>system administrators on the other machines, they would have my passwords
>to all my accounts which is not a good idea.  Also, what do you do when
>you fire a system administrator for bad conduct?  If he had access to
>those clear passwords, every password would have to be changed.

	i thought i was being only semi-serious...  guess i didn't make that
	clear enough.

	the thought at the time was that the file being non-world readable
	excludes any one BUT a sysadmin from even knowing if there is
	a password present, much less whether it's encrypted or not.

	besides the sysadmin is being trusted not install password snarfing
	versions of programs, isn't he?

	after obtaining (or already posessing) sufficient privs to
	read the "non-world readable file" a person (sysadmin or badguy)
	neither knows nor cares what passwords are - at that point the
	person can do anything he wants to.

	do the other sysadmins have sysadmin privs on the system(s) you 
	administer? if not, then they wouldn't be able to read the 
	"non-world readable" file in the first place.  if they do have 
	privs on your systems, then they can do anything you can and 
	don't need to know the passwords anyhow.

	you mean you don't change passwords when sysadm types leave (especially
	when they're TOLD to leave)?  when someone is as trusted a capacity
	as that leaves (on bad terms especially) i'd think that there'd be
	a fair amount of concern over possible dummy privd account left
	behind, and the like.

	no, i'm not advocating removal of encryption.

	Steven
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 06:25:23 GMT
From:      usc!jarthur!bridge2!3comvax!tymix!tardis!jms@ucsd.edu  (Joe Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Ancient articles re-appearing.
This article showed up on my system.  Any idea who's machine is in a time warp?

From tymix!oliveb!logicon.com!nosc!crash!ncr-sd!sdd.hp.com!uakari.primate.wisc.
edu!aplcen!unmvax!sci.ccny.cuny.edu!cucard!dasys1!cooper!phri!sci.ccny.cuny.edu
!rpi!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!husc6!hscfsas1!chrome Wed Jun 
 6 23:14:24 PDT 1990
Path: tardis!tymix!oliveb!logicon.com!nosc!crash!ncr-sd!sdd.hp.com!uakari.prima
te.wisc.edu!aplcen!unmvax!sci.ccny.cuny.edu!cucard!dasys1!cooper!phri!sci.ccny.
cuny.edu!rpi!zaphod.mps.ohio-state.edu!usc!cs.utexas.edu!husc6!hscfsas1!chrome
Newsgroups: alt.security,comp.protocols.tcp-ip,alt.sys.sun
Subject: Re: anonymous ftp, and the dangers thereof
Message-ID: <2616@husc6.harvard.edu>
References: <EMV.90Apr18204600@picasso.math.lsa.umich.edu>
Sender: news@husc6.harvard.edu

Looks like the original date was 18-Apr-90.
-- 
Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com
BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-C41    | BIX: smithjoe | 12 PDP-10s still running! "POPJ P,"
San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jun 90 11:08:32 EDT
From:      Bob Stewart <stewart@xyplex.com>
To:        info-mac@sumex-aim.stanford.edu, tcp-ip@nic.ddn.mil
Subject:   X Windows and TCP/IP on the Macintosh
Dear Generous Suppliers of Free Advice,

I'm using NCSA Telnet on my Macintosh to talk to a Unix system so I can
communicate with the world.  It's connected through AppleTalk to a Gator Box.
I'd like to have a more direct connection for mail, FTP, etc., as well as 
X Windows access.

We're looking into White Pine Software's eXodus, which implements X Windows
over a communication base such as Alisa Systems' TSS for DECnet or Apple's
MacTCP for the Internet.  I'd like to hear from people who've tried that or
who know anything interesting about it.  If I have MacTCP, can I run FTP,
Telnet, eXodus, and such just as if I was on a Real :-) System?  If so, can
they all run at once?  White Pine tells me that eXodus/MacTCP and NCSA Telnet
are mutually exclusive.  If anyone from Apple or White Pine cares to respond,
I won't consider it as a commercial message.

Thanks in advance for the help.

	Bob

-----------
Bob Stewart (rlstewart@eng.xyplex.com)
Xyplex, Boxborough, Massachusetts
(508) 264-9900

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Jun 90 18:18 H
From:      <CHAIBP%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   desperately need an answer


Clark, in his RFC 817, said that kernel implementation
of TCP/IP would subject to many system limitations and
suggested that only part of TCP/IP should be placed in
the kernel, leaving the rest in the user processes.

Now, what I don't understand is that why everybody still
put the entire TCP/IP in the kernel - AT&T system V,
Sun BSD Unix and many others all does just that. Does
that mean that those limitations are never faced by them
or that they have actually took his advice but provided the
interfaces to the user processes in a way that gives
them the illusion of interfacing with the kernel ?

Desperately need an answer on that ! Please give me
an answer if you do have one.

Chai

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 09:29:50 GMT
From:      mcsun!hp4nl!media01!rla@uunet.uu.net  (Raymond van der Laan)
To:        tcp-ip@nic.ddn.mil
Subject:   datagrams and non-blocking sockets ==> PROBLEM

I have written a network interface on a Sun 386 machine using socket
based IPC. The virtual circuit stuff works fine, but I have a problem
with the datagram part.

Because I want to be able to identify the sender of the datagram,
I let the sender bind its socket to a portnumber (which is well-known
to both parties). When I use the recvfrom call on the receiver's side,
I can retrieve the portnumber and the hostmachine, so I know who sent
the DG. No problems so far.

However, because I do not want to wait forever if there is no dg sent at
all, I use the ioctl call on the receivers side to mark the socket non-
blocking (FIONBIO). When I do this, the binding done by the sender has no
effect. Instead, the system binds the socket to some other portnumber, so
the receiver doesn't know who sent the DG.
(I use the same ioctl call for VC's, but this call is made after the
VC is established.)

What's happening? If anyone knows more about this, please let me know.


+---------------------------------------------------------------------------+
| Raymond van der Laan                                                      |
| Mediasystemen B.V.                                                        |
| Holland                                                                   |
+---------------------------------------------------------------------------+
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 10:32:41 GMT
From:      mcsun!ukc!slxsys!jpp@uunet.uu.net  (John Pettitt)
To:        tcp-ip@nic.ddn.mil
Subject:   Name server help wanted
We have a mixed network of PC's and workstations running TCP/IP
and currently using /etc/hosts to resolve ip addresses.  I will
shortly be bridging to two remote nets and would like to move
to a name server based system.

Can anybody point me at a simple guide to setting up and maintaining
name servers ?  We will eventually be conneting to one of the commercial
IP nets (which ever one gets to the UK first !) and would like to get
things right now while the net is still only 20 systems.


-- 
John Pettitt, Specialix International, 
Email: jpp@specialix.com Tel +44 (0) 9323 54254 Fax +44 (0) 9323 52781
Disclaimer: Me, say that ?  Never, it's a forged posting !
-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 17:36:11 PDT (Thu)
From:      karl@asylum.sf.ca.us (Karl Auerbach)
To:        tcp-ip@nic.ddn.mil
Subject:   Efficiency (or lack thereof) of ASN.1

ASN.1 doesn't try to limit itself in any way.  And that makes it a CPU
hog.  There are zillions of applications where the data range is
limited and the overhead of ASN.1 simply isn't reasonable.

I've optimized and optimized my ASN.1 tools and I find that my SNMP
(which occupies on the order of 20K bytes) could be cut in half if
ASN.1 were replaced by something more like XDR.  And the performance
would be significantly improved.  The problem is that ASN.1 requires
the CPU to examine each and every character.

(I've found that the #1 bottleneck is handling the length field.  #2
bottleneck is handling multi-byte tags [even though they occur with
extreme in-frequency].  These sort of things occuply only a few lines
of C, but they tend to get executed a lot and tend to generate rather
many machine instructions per line of C.)

ASN.1 is the perfect example for the cliche "If all you have is a
hammer, everything looks like a nail."

				--karl--
-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 11:59:08 GMT
From:      stephan@kulcs.uucp (Stephan Biesbroeck)
To:        comp.sys.ibm.pc.rt,comp.dcom.sys.cisco,comp.protocols.tcp-ip
Subject:   IP over x25 between IBM PC/RT and cisco


I have an IBM PC/RT with an X25 board in it. I also have the software
of IBM for running IP above X25.
What I want to do is the following : get an IP connection between my PC/RT
and a cisco-router over an x.25 network.
Is this possible? Has anybody already done this?

Any help will be appreciated of course. 


Send your suggestions, directions, remarks, .... to
stephan@cs.kuleuven.ac.be or stephan@kulcs
stephan@Belgium.EU.net 


----------------------------------------------------------------------------
Stephan Biesbroeck                        Katholieke Universiteit Leuven
Tel : +32/16/20.10.15(x3602)              Dept. of Computer Science
telex : 23674 KULEUV B                    Celestijnenlaan 200A
fax : +32/16/20.53.08                     B - 3030 Leuven
email : stephan@cs.kuleuven.ac.be         Belgium
        stephan@kulcs.UUCP
        stephan@blekul60.BITNET
----------------------------------------------------------------------------

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Jun 90 16:19:03 EDT
From:      "Dennis G. Rears (FSAC)" <drears@PICA.ARMY.MIL>
To:        "Steven M. Schultz" <sms@wlv.imsd.contel.com>
Cc:        att!cbnewsh!wcs@ucbvax.berkeley.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  abolishing /etc/passwd (was Re: anonymous ftp, and the dangers thereof)

"Steven M. Schultz" <sms@wlv.imsd.contel.com> writes:
>
>>From: att!cbnewsh!wcs@ucbvax.Berkeley.EDU  (Bill Stewart erebus.att.com!wcs)
>>References: <6703@blake.acs.washington.edu>, <28764@ut-emx.UUCP>
>>
>>	/etc/passwd has become the traditional location for user-info
>>	other than passwords, so of course it needs to be kept,
>>	but I agree with the shadow-password approach that puts 
>>	(encrypted) passwords in a non-world-readable file.
>
>	just a "thought" - if the (shadow)file is non-world readable and the
>	system is administered "correctly" then why bother with
>	encryption at all ;-)

   Just in case one of the system admins is a bad guy or becomes a
bad guy.  I have three passwords for 30+ systems of which I only
administrate 12 of them.  If my password was available in the clear to
system administrators on the other machines, they would have my passwords
to all my accounts which is not a good idea.  Also, what do you do when
you fire a system administrator for bad conduct?  If he had access to
those clear passwords, every password would have to be changed.

Dennis
-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 13:23:18 GMT
From:      rang@speedy.wisc.edu  (Anton Rang)
To:        tcp-ip@nic.ddn.mil
Subject:   tftp (was Re: anonymous ftp, and the dangers thereof)
In article <3023@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes:
>To what extent does one disable tftp (or did the original user mean
>anonymous ftp)?

  At a minimum, you should restrict either which hosts can access tftp
on a given machine, or which files tftp can access.  The problem is
that tftp, as distributed, lets anyone access any publicly-readable
file, and lots of important files (like /etc/passwd) are publicly
readable.  (In other words, having tftp enabled allows dictionary
attacks to be tried without needing an account on the remote machine.)

  This is my understanding of the matter, at least; feel free to
correct any misapprehensions.

		Anton
   
+---------------------------+------------------+-------------+
| Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison |
+---------------------------+------------------+-------------+
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 14:19:57 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!ntvaxb!billy@ucsd.edu
To:        tcp-ip@nic.ddn.mil
Subject:   WIN/TCP 5.1 programming question
Hi,

I have an account that I would like to limit access to based on IP address. 
This is under VMS 5.3-1 and WIN/TCP 5.1 (though a Multinet program should work
too).  My idea is that the LOGIN.COM (or an executable run in it) would find
out the IP address that the TELNET is from and then screen based on that.  If
anybody can give me an example program that figures out the IP address, I would
appreciate it.

Thanks,

================================================================================
Billy Barron                  Bitnet : BILLY@UNTVAX
VAX system manager            THENET : NTVAX::BILLY
University of North Texas   Internet : billy@vaxb.acs.unt.edu
                                SPAN : UTSPAN::UTADNX::NTVAX::BILLY
================================================================================
-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 14:58:34 GMT
From:      usc!cs.utexas.edu!execu!sequoia!rpp386!jfh@ucsd.edu  (John F. Haugh II)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <19105:Jun616:44:3190@stealth.acf.nyu.edu>, brnstnd@stealth.acf.nyu.edu writes:
> Because the first part of the password is chosen by the user and never
> written down, a casual cracker can't find it by just snooping around an
> office. Because the second part of the password is chosen by the system,
> brute-force cracking will fail miserably.

The flaw in your assumption is the sentence "Because the second part of
the password is chosen by the system, brute-force cracking will fail
miserably."  The problem is that the "hard" part is permitted to be written
down anywheres, or even encouraged to.  This reduces the problem to
finding out the "easy" part of the password.

If this system uses two separate passwords, each given in turn, I try
cracking the "easy" password whenever prompted, since I am always able
to respond with the "hard" password I just found written on your desk
blotter.

If this system interweaves the two parts, I try cracking by starting
with the "hard" part and interweaving my guesses.  This is only
comlicated by the number of possible positions my "easy" part can be
interwoven into.  I would presume that avoiding too much complication
would greatly limit the number of positions, further weakening this
scheme.

> I proposed this last year (in u-w) but never saw much response.

I hope you like my response ;-)
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org

                                            Proud Pilot of RS/6000 Serial #1472
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 15:12:55 GMT
From:      sdd.hp.com!samsung!xylogics!loverso@ucsd.edu  (John Robert LoVerso)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tftp (was Re: anonymous ftp, and the dangers thereof)
And don't be fooled by the fact that the TFTP protocol doesn't include
a list-directory call.  The BSD tftpd will allow [publically readable]
directories to be read, and so a clever user tftp program could use this
to implement an "ls"-style listing.  This can give away the names of
subdirectories you might have in your tftp-area (if you are running
a "secure" tftpd that does a chroot), or let the people walk your
whole filesystem, even if they don't know its layout before hand.

A trivial change to tftpd would prevent the reading of all but plain
files.

John
-- 
John Robert LoVerso			Xylogics, Inc.  617/272-8140 x284
loverso@Xylogics.COM			Annex Terminal Server Development Group
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 16:34:37 GMT
From:      intercon!news@uunet.uu.net  (Amanda Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
In article <4431@infmx.UUCP>, kwang@infmx.UUCP (Kwang Sung) writes:
> If you are saying same words to Korea or Japan Government/Industries/
> Universities, they are going to laugh.

They haven't so far.  TCP/IP is used by many Japanese universities and
industry leaders for the reason that it works and is available right now.
They may be doing research into OSI and MAP/TOP, but they still use TCP/IP
to get their work done.

> I was invited from several institutions and Korea 
> Government Organizations which are dealing with the highest technologies in 
> the world. Not many people wanted to talk about TCP/IP. They were already
> migrated to OSI world.

If they have installed and operational OSI networks, with similar scale,
performance, and quality of service as U.S. and European TCP/IP networks,
then it's time I scheduled a trip to Korea to see them.

I wonder how they managed it while the ISO is still arguing with itself...

> It's slow sometimes, but the whole world is rapidly moving into one OSI
> world.

It doesn't look that way from what I've seen.  My company is a TCP/IP vendor.
The fastest growing part of our market is overseas--institutions all over
the world are installing and expanding TCP/IP networks, sometimes replacing
attempts to use OSI.

OSI has some very important advantages over TCP/IP, but it is still quite
immature technology, and I think that it's a little early to plan
large-scale migration from TCP/IP.  For discussion, though, you can always
use 'comp.protocols.iso', which can probably handle the volume for a
while...

--
Amanda Walker, InterCon Systems Corporation
--
"If we don't succeed, then we run the risk of failure."  -- Dan Quayle
-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 16:37:38 GMT
From:      intercon!news@uunet.uu.net  (Amanda Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Efficiency (or lack thereof) of ASN.1. Was: Re: What is the IAB?
In article <11946@asylum.SF.CA.US>, karl@asylum.SF.CA.US (Karl Auerbach)
writes:
> In my SNMP code, my profilers indicate that an
> overly large portion of the of cycles are spent in the ASN.1
> encoder/decoder.  Maybe my code is inefficient -- although I doubt it.

You might want to look at it again.  The quite restricted variant of ASN.1
that is used in SNMP can actually be pretty quick to parse.  Most of the
publically available ASN.1 parsers that I have seen are overly complex...

--
Amanda Walker, InterCon Systems Corporation
--
"If we don't succeed, then we run the risk of failure."  -- Dan Quayle
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 17:07:04 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!news@ucsd.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
In article <4431@infmx.UUCP> kwang@infmx.UUCP (Kwang Sung) writes:

   	If you are saying same words to Korea or Japan Government/Industries/
   Universities, they are going to laugh.

I just went into 'irc' (Interactive Relay Chat), and did a '/links' command.
The hosts that are linked into irc are listed below.  Not only is Europe
well represented, so is Japan.  Perhaps you're right about OSI, but when
people want to internetwork today, they get on the Internet.

noc.belwue.de (BELWUE (Stuttgart), West Germany)
uni-ulm.de ([titania.mathematik.uni-ulm.de] University of Ulm,)
uni-kl.de ([popper.informatik.uni-kl.de] [131.246.8.80]Univer)
rwth-aachen.de ([cip-s01.informatik.rwth-aachen.de] [192.35.229.11)
ira.uka.de ([iraun1.ira.uka.de] University of Karlsruhe, FRG)
zephyr.cair.du.edu (University of Denver's International Server)
s.ms.uky.edu (University of Kentucky)
xanth.cs.odu.edu (Magical land of Xanth Server)
suna7.cs.uiuc.edu (University of Illinois at Urbana Backup)
sunb7.cs.uiuc.edu (University of Illinois at Urbana Backup)
garfield.mit.edu (MIT Project Athena, Massachusetts, U.S.A.)
diamond.bbn.com (The Server at the End of the World)
chaos.cs.brandeis.edu (Brandeis University, Waltham, MA 2.4)
wharfin.wpi.edu (WPI TEST server running IRC II v2.4.1)
bucse.bu.edu (Boston University, Boston, MA 2.4.1)
eniac.seas.upenn.edu (University of Pennsylvania, Philadelphia, PA)
beach.cis.ufl.edu (University of Florida Server)
slopoke.mlb.semi.harris.com (Harris Semiconductor, Melbourne FL, US
fysaj.fys.ruu.nl (Rijks Universiteit Utrecht, the Netherlands)
assari.tut.fi (Tampere University of Technology, Finland)
otax.tky.hut.fi (Student Body of Helsinki University of Technology)
cs.hut.fi ([sauna.hut.fi] Helsinki University of Technology, )
lut.fi (Lappeenranta University of Technology, Finland)
tolsun.oulu.fi (Experimental IRC Server at University of Oulu, Fin)
kreeta.helsinki.fi (University of Helsinki, Finland <IRC 2.4.1>)
joyx.joensuu.fi ([128.214.14.2] University of Joensuu, Finland)
jyu.fi (University of Jyvaskyla, Finland)
tel4.tel.vtt.fi ([130.188.12.4] VTT--Technical Research Centre of F)
nada.kth.se ([130.237.222.50] Royal Institute of Technology, St)
laila.lysator.liu.se (Lysator CC at Link|ping University, Sweden)
flute.er.sintef.no (ELAB-RUNIT, U. of Trondheim, Norway <2.2msa.4>)
solan4.solan.unit.no (Norwegian Institute of Tech., Trondheim N)
svarte.uio.no (University of Oslo, Norway <2.4>)
adagio.fy.chalmers.se ([129.16.6.200] Chalmers Tekniska Lekskola)
shai.sics.se ([192.16.123.226] Swedish Institute of Computer Sci)
lso.win.tue.nl (Experimental IRC-Server, Eindhoven, Holland)
slice.ooc.uva.nl ([192.42.115.1] Universiteit van Amsterdam, The Ne
giza.cis.ohio-state.edu (Ohio State University, Columbus)
schubert.psu.edu (Penn State NeXTlab IRC server)
galileo.apo.nmsu.edu (Apache Point Obs.)
cwns1.INS.CWRU.Edu (CWRU IRC Server)
wpi.edu ([wpi.WPI.EDU] WPI's Server (others are cheap imita)
vela.acs.oakland.edu (Oakland University, Rochester, MI, USA)
washington.andrew.cmu.edu (A server named George(2.4))
unix.cis.pitt.edu (University of Pittsburgh Server)
astsun.astro.Virginia.EDU (University of Virginia 2.4)
group-w.uchicago.edu (University of Chicago - Astro)
kentmath.math-cs.kent.edu ([kentmath.kent.edu] Computer Science Department, K)
oddjob.uchicago.edu (University of Chicago - Astro)
ux.acs.umn.edu (University of Minnesota, Minneapolis, MN)
medusa.cs.purdue.edu (Chief's Server)
uxc.cso.uiuc.edu (University of Illinois at Urbana (V2.4))
uni-erlangen.de ([faui43.informatik.uni-erlangen.de] Uni Erlangen)
guug.de ([192.48.231.3] GUUG Muenchen,West-Germany)
TU-Muenchen.de ([sunsystem1.informatik.tu-muenchen.de] TU Munich, )
tavi.rice.edu (Rice University)
iroquois.utdallas.edu ([129.110.10.12] Univ. of Texas at Dallas)
pkg.mcc.com ([128.62.40.1] Group Talisman server at MCC, Austin)
taltta.hut.fi (Helsinki University of Technology)
GRASP.CIS.UPENN.EDU (U of Penna. TiTo Server, Philadelphia, PA, USA)
emil.csd.uu.se (CS Dept., Uppsala Univ., Sweden <2.4.1>)
mizar.docs.uu.se (Uppsala University Server (DoCS))
uceng.uc.edu (University of Cincinnati Primary Server 2.4)
byron.u.washington.edu (University of Washington Server)
hayes.fai.alaska.edu (University of Alaska Fairbanks)
cpac.washington.edu ([bailey.cpac.washington.edu] UW IRC Server V2.2PL1)
unicorn.wwu.edu (WWU Fantasy Server)
hammer.me.utoronto.ca (UofToronto Server)
galaxy.ee.rochester.edu (Univ of Rochester, Department of Electrical Engine)
sirius.ctr.columbia.edu ([128.59.64.60] Columbia University CTR, New York C)
NeXT210.NOdak.edu (You Can't Find It In the Atlas)
ronin.us.cc.umich.edu (U. of Michigan ITD Consulting IRC Server)
srvr1.engin.umich.edu (University of Michigan, CAEN IRC Server, Ann Arbor)
oak2.math.ucla.edu (UCLA Mathter and Servant)
astemgw.astem.or.jp (ASTEM Research Institute, Kyoto, JAPAN)
cnam.cnam.fr (Centre National des Arts et Metiers v2.2PL, Paris,)
monu6.cc.monash.edu.au ([130.194.32.106] Monash University, Australia)
MED.STANFORD.EDU (Stanford Medical School Information Systems Group)
hercules.csl.sri.com (SRI Computer Science Lab, Menlo Park, CA  USA)
ucscb.UCSC.EDU (University of California at Santa Cruz, IRC 2.4)
lucid.com (Menlo Park, California, USA)
utsun.s.u-tokyo.ac.jp ([133.11.7.250] University of Tokyo, Japan <2.4>)
choshi.kaba.or.jp ([choshi] Kyoto Artificial Brain Associates, Kyoto,)
kimura4.kuee.kyoto-u.ac.jp ([130.54.30.164] Kyoto University, Japan <2.4>)
jerry.tom.astem.or.jp ([133.18.192.1] Kyoto Junction Server, ASTEM, Kyoto)
eris.Berkeley.EDU (Berkeley Ultra-Hoopy Test Server)
betwixt.cs.caltech.edu ((Caltech Server) <irc2.4>)
ucselx.sdsu.edu (San Diego State University, CA   USA)
paris.ics.uci.edu (University of California, Irvine <2.4PL0>)
ccnext.ucsf.edu (UCSF IRC Server)
cssun1.cs.indiana.edu (Indiana University Test Server)
iucs.cs.indiana.edu (Indiana University Test Server)
silver.ucs.indiana.edu (Indiana University Test Server)
irc.andrew.cmu.edu ([FAIRHOPE.ANDREW.CMU.EDU] Generic Brand CMU IRC
spot.colorado.edu (University of Colorado, Boulder)
hamblin.byu.edu (BYU Math Dept)
cie.uoregon.edu (The Campus Information Exchange's IRC Server)
uhura.cc.rochester.edu (University of Rochester - Rochester, NY)
netserv2.its.rpi.edu (Rensselaer Polytechnic Institute, Troy NY)
sun.soe.clarkson.edu (Clarkson, Potsdam, NY 13676)
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problems
-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 19:25:45 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!thucydides.cs.uiuc.edu!morrison@ucsd.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Trivial Ethernet Analyzer software available

Here is something that I have wanted for a long time, but never found.
Finally I got so fed up, I wrote it myself.  Here is an abridged version
of the software discription document.  

At present, it is unavailable via E-mail.  But if someone places it
on a E-mail archive site and lets me know, I will pass that information
on to interested parties.   If this is a MAJOR problem for you, let me
know, and if there is sufficient interest, I will post the software to 
comp.binaries.ibm.pc.  

Vance

--------------------------------------------------------------------------

                    A Trivial Ethernet Analyzer
                           Vance Morrison


    Very often a network administrator has to debug networking problems
given only the raw symptoms of the problem (my program hangs).  Trying
to debug given such sparse information is difficult at best and impossible
at worst.  Often the ability to 'snoop' on the network and watch the 
packet dialog is VERY helpful.  Basically I have written a program
called 'analyzer' that watches packets go by on the network and prints
them out in a human readable form.   At present, this program only 
understands TCP/IP protocols (and not all of them), and for security
reasons analyzer only prints what it understands.  Thus at least at
present, analyzer will not help with DECNET, XNS, ETHERTALK traffic.

WHAT YOU NEED

    In addition to the analyzer.exe executable (available from 
accuvax.nwu.edu (129.105.49.1) in pub/pcroute/analyzer), you will also 
need a PC with a network card, as well as the clarkson packet driver for 
that  card.  The clarkson packet driver is a piece of software that allows
analyzer.exe (as well as other programs) to access the network card in
a device independent way.  A driver exists for most of the common networking
cards, and is available (among other places)  sun.soe.clarkson.edu 
(128.153.12.3) in the directory 'pub/packet-drivers'.  Note that some
packet drivers do not support 'promiscuous' mode (in particular I know the
ni5010 does not).  In that case analyzer.exe will work, but will not be
of much use (since it will only see packets destined for the itself and
the broadcast address).  I do know that the wd8003e driver DOES work.

SHORTCOMINGS

Admittedly, analyzer is not a very flexible program.  The philosophy here
is that something is a LOT better than nothing, and once you have the
output as ASCII output it can be filtered and beautified to your hearts
content.  For example, if you have a batch editor (like sed), you can
do a global search an substitute to replace ethernet addresses with a
more mnemonic one.   Also, I did NOT what to spend a lot of time on this,
analyzer in its present form is about 3 days work.

SECURITY ISSUES

In an ideal network, it shouldn't matter that a program like analyzer
exists.  However, life is not ideal, and passwords and other sensitive
data are routinely sent in unencrypted form across nets.    I have therefore
gone to a little trouble to make analyzer 'safe'.  It only prints out
parts of packets that should not contain sensitive data.   While this is
not foolproof, I believe is does open any security loophole any wider
than it already is (which is actually pretty wide).  

EXTENSIONS

Usually I provide the source code to my work so that if anyone wants
to make extensions they can do it themselves (and not bother me).  In
the case of analyzer, this would be particularly nice since analyzer
does not print (in any form) what it does not know, and analyzer is
a pretty ignorant program (:-).  Unfortunately releasing source would
be a security problem, since it would be VERY easy to modify analyzer
to do mischief.  Thus I propose a compromise.  If analyzer does not
print output packets that you want to see, simply write some C code
that takes a pointer to that packet and prints it out.  I have included
the file 'ip.c' in the distribution to give you an example of how to
do it.  If you send this file to me, I will look it over for security
holes, compile it, and send you an executable.  This arrangement is
less than perfect, but it will give you an option if you wish to exercise
it.

COPYRIGHT

Please notice the copyright.  This is shareware.  You are allowed to
use this software on a trial basis for one month.  If after that time
you find analyzer and wish to keep using it, send a $10 registration
fee to the address below.    See the analyzer.doc file for details.
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 19:48:59 GMT
From:      jgd@rsiatl.UUCP (John G. De Armond)
To:        comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.nfs
Subject:   Dialup x.25 & nfs questions


I have a couple of questions regarding the use of tcp/ip over x25 in
a dialup environment.

The environment is:

IBM RS/6000 320, Uninet SLAT, v.32 modems on one end and 

IBM 3081 with 3745 on the other.

Questions:

	Does anyone have any experience with a setup similiar to this?

	How does x.25 in a point-to-point environment compare to SLIP?

	How does x.25 and v.32 compare in performance to {slip,x.25,
	other protocols} and trailblazers?  Particularly in noisy environments.

	Any other general comments?


Second question.

From this same RS/6000, there is a need to connect a PC over ethernet.
PC-NFS has been proposed.  I have little experience with NFS in general
and no experience with PC-NFS in particular.  This connection will involve
an unmanned PC and therefore must be reliable.  Any comments positive
or negative would be appreciated.

I have to discuss these situations in the next few days so any comments
would be greatly appreciated.  E-mail prefered.

Thanks,
John

-- 
John De Armond, WD4OQC  | We can no more blame our loss of freedom on congress
Radiation Systems, Inc. | than we can prostitution on pimps.  Both simply
Atlanta, Ga             | provide broker services for their customers.
{emory,uunet}!rsiatl!jgd|  - Dr. W Williams |                **I am the NRA**  

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jun 90 01:01:50 EST
From:      schoff@uu.psi.com (Martin L. Schoffstall)
To:        uupsi!uunet.UU.NET!infmx!moose!kwang@uu.psi.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   migrate.to.iso, off we go......

> 
> I don't quite agree with it. As I've explained, since the U.S. Government is
> getting poorer, they can not afford to replace the "old" technology. Moreover,
> they don't want have an error especially under tactical environments. That's
> why TCP/IP technology is now getting matured. But I don't think it is "best"
> technology. I would call it "old" technology.  About 1983, I had a chance to
> design and implement DoD protocols with MIL STD for the U.S. Government.  
> I've found a whole bunch of errors on MIL STD specs. I wrote a letter to
> DCA about those errors. Still 1990, they are using the same MIL STD specs. 
> Do you know why ?? Because they don't have enough money to revise it. Actually,
> MIL STD were written by UNISYS under some contract. 

The US Government seem to be as rich as ever to me; however, don't confuse
the MILSPEC's of 1983 with the Internet and its technology of 1990.  A
lot has been done in the RFC series and in many other publications, more
importantly these improvements have been widely implemented, and the
rate of improvement of the TCP/IP technology is accelerating.
> 
> 
> 	If you are saying same words to Korea or Japan Government/Industries/
> Universities, they are going to laugh. About a year ago, when I had a chance
> to go back to Korea, I was invited from several institutions and Korea 
> Government Organizations which are dealing with the highest technologies in 
> the world. Not many people wanted to talk about TCP/IP. They were already
> migrated to OSI world. In these days, I am envolved with the projects with
> Euroupe. That's why I was interested in U.K. GOSIP. They are interested in
> U.S. "old" TCP/IP technology, but I don't think they will change their 
> existing systems for it.   

Dozens of commercial organizations laugh all the way to the
bank as they export tcp/ip products to the Pacific Basin to the who's who
of commercial enterprises.  I don't know what the "highest technologies in
the world" are, but I have been told that you need to be high to fully
appreciated OSI and GOSIP.

> 
> Some of your statements I agree. Evenif OSI technologies are still 
> premature, I don't see 10 years. It's slow sometimes, but the whole world 
> is rapidly moving into one OSI world.
>
With sufficient soma it is possible that some might believe that we're
rapidly moving into the brave new world of OSI.  Unfortunately the
monetary investment in product and services doesn't support that.

Philosophically what you need to consider is the concept of coexistence
which will exist 10 and 20 years from now.  Only a very small amount of
the market is going to migrate to OSI in the near term, undoubtedly
for good political reasons, not technological ones.  Considering that most
of the OSI technology will run over things like X.25, which is truelly
ancient technology, the ability to even prove the utility of the OSI
technology sometimes appears doomed.

You say your messages are serious, but I have to reread them to make sure
that BIFF or PVM isn't spoofing us all.

Marty

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 21:06:10 GMT
From:      mrspoc!mrspoc!kayvan@apple.com  (Kayvan Sylvan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
>>>>> "brnstnd" == brnstnd <brnstnd@stealth.acf.nyu.edu> writes:

brnstnd> What's the solution? Mix 'n' match. A password has, say, two
brnstnd> parts: one chosen by the user and neither expired nor
brnstnd> restricted, one generated randomly by the system and changed
brnstnd> periodically (some sizable fraction of a year). The first
brnstnd> part is NEVER written down; users are told that if they write
brnstnd> down the first part, they'll be drawn and quartered. The
brnstnd> second part is almost certainly written down, typically on a
brnstnd> piece of paper in the user's desk; users are explicitly told
brnstnd> that this is okay.

Hmmm... Interesting. If the paper on which the second part is written
down is kept locked up (or otherwise is inaccesible to random
snooping), then it jut might work.

			---Kayvan
-- 
| Kayvan Sylvan @ Transact Software, Inc. -*-  Los Altos, CA (415) 961-6112 |
| Internet: kayvan@{mrspoc.Transact.com, eris.berkeley.edu, largo.ig.com}   |
| UUCP: ...!{apple,pyramid,bionet,mips}!mrspoc!kayvan "Imagine Cute Saying" |
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 21:32:11 GMT
From:      usc!pollux.usc.edu!kmeyer@ucsd.edu  (Kraig Meyer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  Growing sentiment against gateways
In some article someone wrote:
||> (One could argue that those "gateways" violate the access rules for
||> the Internet, since they cannot verify that the message came from an
||> authorized user of the Internet.)
  
In article <9006060613.AA00673@shamash.McRCIM.McGill.EDU> mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) writes:
||You mean there *are* access rules for the modern Internet?  This sounds
||suspiciously as though you're thinking of the DARPA rules, which (it
||seems to me) don't really apply, with the demise of the ARPAnet core.

Most, if not all, of the regional networks attached to the NSFnet backbone
have appropriate usage guidelines.  Traffic which is solely for commercial
purposes is prohibited from traversing the NSFNet backbone--there are most
definitely rules which govern Internet access.  However, in the case of
gatewaying the tcp-ip mailing list to and from usenet I think it could very
easily be argued that this fits appropriate usage guidelines.
---------------------------------------------------------------------------
| Kraig R. Meyer		   		    kraig@jerico.usc.edu  |
| University of Southern California                          Los Angeles  |
---------------------------------------------------------------------------
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      7 Jun 90 22:41:27 GMT
From:      chad@anasaz.UUCP (Chad R. Larson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP Print Spooler

In article <7290002@hpccc.HP.COM> munjal@hpccc.HP.COM (Deepak Munjal) writes:
+---------------
| Does anyone know of a box that will take TCP/IP based Unix spooled 
| printer output and convert it something an RS-232 printer can understand?
+---------------
    Microtest
    3519 East Shea Boulevard
    Suite 134
    Phoenix, Az 85028
    (800) 526-9675

They have a product called LANPORT which does exactly what you want,
but for a Novel network.  Call 'em anyway.  If enough people express
interest, they may make it.  They're a small company and after all,
"it's only software".  New ROMs should do it.
	-crl
-- 
Chad R. Larson          ...{mcdphx,asuvax}!anasaz!chad or chad@anasaz.UUCP
Anasazi, Inc. - 7500 North Dreamy Draw Drive, Suite 120, Phoenix, Az 85020
(602) 870-3330            "I read the news today, oh boy!"  -- John Lennon

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 00:23:33 GMT
From:      Makey@Logicon.COM (Jeff Makey)
To:        comp.protocols.tcp-ip,alt.security
Subject:   Shadow password files (was: anonymous ftp, and the dangers thereof)

In <9006070151.AA03928@world.std.com> bzs@world.std.com (Barry Shein) writes:
>The objection to shadow password files is that it's an admission that
>hiding the file contents is critical to the entire system's security

"Critical" is the wrong word, here.  The use of shadow password files
is nothing more than an application of the well-established concept of
"in-depth" security measures, where the security of the system does
not depend completely upon any single security feature.

>Don't argue that it merely "improves" the
>existant security, fine, you obviously decide for yourself so you can
>believe whatever you like. Multiplicative probabilities aren't
>compelling arguments.

Probability theory is just so much bunk, huh?  You can disbelieve
whatever you like, I guess.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: All opinions are strictly those of the author.
    Internet: Makey@Logicon.COM    UUCP: {nosc,ucsd}!logicon.com!Makey

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 01:07:09 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: abolishing /etc/passwd (was Re: anonymous ftp, and the dangers thereof)

In article <9006060704.AA02343@WLV.IMSD.CONTEL.COM>, sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) writes:
> 	just a "thought" - if the (shadow)file is non-world readable and the
> 	system is administered "correctly" then why bother with
> 	encryption at all ;-)

Go back and read the Morris/Thompson paper.  Basically, files can leak,
due to carelessness, bugs, hard-copy terminals, backup tapes, etc.

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 03:44:16 GMT
From:      jc@minya.UUCP (John Chambers)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous ftp, and the dangers thereof

> Some sites keep anonymous FTP directories to be world-writable,
> letting any random internet user drop a file in a directory.  If you
> see a file named GETMONEY.txt, makemoney.doc, or sex-bbs.doc (or
> variations on same) in your FTP directory, this is why.  It is not
> good practice to allow random anonymous users to scribble into
> directories ...

The obvious counter-example to this is /usr/spool/uucppublic, which
is almost always world-writable, yet there seem to be no reports of
even minor problems with this.  It's usually considered a useful
part of uucp, and an assortment of tools are around (uuto/uupick for
example) are layered on top of it.

It's true (in fact, it's obvious) that one could fill up a victim's
disk partition.  But this isn't doesn't seem to trigger call for 
shutdowns of all uucp sites until the horrible security problems 
are fixed.  (Well, OK, users of competing packages *do* make such
calls, but not uucp's users. ;-)

So why is it such a disaster if an anon-ftp directory is writable?

-- 
Uucp: ...!{harvard.edu,ima.com,mit-eddie.edu}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: It's never to late to have a happy childhood.

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 04:26:49 GMT
From:      jc@minya.UUCP (John Chambers)
To:        comp.protocols.tcp-ip
Subject:   Re: trash message from usenet (BIFF)

In article <23824@bellcore.bellcore.com>, mo@messy.bellcore.com (Michael O'Dell) writes:
> The notion that mail or mailing lists on the Internet are either
> "secure" or "accountable" is simply hysterical.
> 	-Mike

Insults aside, I'd like to hear a coherent definition of these terms
with regards to mailing lists.  I'm not being facetious or asking a
rhetorical question.  It's clear that people have some concept in mind
when they use such phrases; I'd like to read a definition that can be
used to develop software.  It's all very well to say that you want your
system secure, verifiable, and all that.  But until you've said quite
precisely what these terms mean, you're speaking sales propoganda, 
not computer engineering.

The basic problem is that a mailing list is basically an automatic
forwarder.  All that I've seen work in the same way:  There is a 
pseudo-user (account) "mlist" on machine "foo", and any mail to
mlist@foo (or foo!mlist or foo::mlist or ...) gets bounced to all
the recipients on a list.  Anyone who knows how to get mail to foo
can send a message to the entire list.  This isn't a bug; it's what
the list was meant for.  What would it mean for a list to be secure?

Would this perhaps mean that nobody not on the mailing list could
send mail to mlist@foo?  This seems rather pointless.  After all,
the whole point of a mailing list is to encourage sending relevant
comments to everyone on the list.  If someone has a contribution
to make to a discussion, I'd certainly expect that I could show 
them what I'd received, and invite them to post their comments on 
the list by sending mail to foo::mlist.  Maybe they'd want to get
on the list, but that takes time; meanwhile they should be able
to contribute.

Does secure perhaps mean that the mail can't go to anyone not on
the list?  This seems a bit naive.  I can always write a program
that scans my mail for articles from a list of sources, and mails
a copy to someone else.  I can't imagine how the manager of the
mailing list could prevent my doing this.  For that matter, as
the manager of email on this machine, I could write a filter for
all incoming mail looking for certain subjects, sources, keywords,
etc., and do whatever I want with them.  Sure, some people will 
be outraged (or would, if they found out :-); others would insist 
that I am legally required to do so by recent court decisions...
But all that is beside the point; the point is that I or any other
email manager or recipient *could* do it, and the manager of the 
mailing list has no way whatsoever of knowing about it.

So when someone asks for a secure mailing list, what could they
possibly have in mind?  Is this just a vague, fuzzy buzz-phrase,
or does it have some specifiable meaning?

I might also refer y'all to John McCarthy's article "Networks
Considered Harmful for Electronic Mail" in last December's CACM,
for an interesting alternate opinion.

-- 
Uucp: ...!{harvard.edu,ima.com,mit-eddie.edu}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: It's never to late to have a happy childhood.

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 06:07:00 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: abolishing /etc/passwd (was Re: anonymous ftp, and the dangers thereof)

In article <9006060704.AA02343@WLV.IMSD.CONTEL.COM> sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) writes:
>just a "thought" - if the (shadow)file is non-world readable and the
>system is administered "correctly" then why bother with
>encryption at all ;-)

I'm not sure how non-serious that smiley represents.  The serious answer is
that even system administrators should not be able to find out a user's
password.  Sure, they don't need to know the user's password to violate the
user's files.  But if they know someone's password then they could
accidentally (or through coercion) divulge it to someone else.

Also, two levels of protection are better than one: if the file is
accidentally made readable it is still encrypted.
						
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Fri, 08 Jun 90 20:39:00 -0700
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        mm@vax3.iti.org.iti.org (Michael McFarland)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: CMOT and MIB
RFCs 1155, 1156, and 1157 are "full standard protocols, with recommended
status"  according to the IAB.  They are, respectively, the SMI, MIB,
and SNMP.  Because 1155, 1156, and 1157 have reached the end of the
standardization process, the three documents together are sometimes
referred to as the Internet-standard network management framework.

RFC 1158 is a "proposed standard, with recommended status".  It is MIB-II, the
proposed successor to the Internet-standard MIB, and fully compatible
with RFC1156.

RFC 1095 is a "draft standard".  It is CMOT.  There is a new
internet-draft specifying a new version of CMOT.  As it is an
internet-draft, it has no standardization status.

RFC 1156 can be used with both SNMP(1157) and CMOT(1095).  RFC 1109 said
that the work on SNMP and CMOT could use different MIBs.  RFC 1158 can
be used with SNMP.  I am told there is a document which casts RFC 1158
into a form useable for CMOT.

It is my believe that this is the "truth, and whole truth, and nothing
but the truth" regarding the standardization status of these
technologies.  Beyond this, work continues, both in producing new
experimental MIBs (e.g., for FDDI), and in re-evaluating existing
technology.

/mtr
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 09:38:31 GMT
From:      mcsun!ub4b!syteke!jim@uunet.uu.net  (Jim Sanchez)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP-IP Print Spooler
There is a product called lanpr from an outfit called nexus in Sweden
that sends print jobs to an ip address and port number.  The idea is
that a printer can be connected to a terminal server port.  The newest
version also works with printers attaced to pcs and also lets pcs use
the unix system printers.  Sounds like a good product but I only
played around with the earlier version.  They company is on the net at
lanpr@nexus.se so you can "ring them up" if you like.

I have NO relationship with them except as a one-time user.
Good luck
-- 
Jim Sanchez          | jim@syteke.be (PREFERRED)
                     | OR {sun,hplabs}!sytek!syteke!jim
Hughes LAN Systems   | OR uunet!mcsun!ub4b!syteke!jim 
Brussels  
-- 
Jim Sanchez          | jim@syteke.be (PREFERRED)
                     | OR {sun,hplabs}!sytek!syteke!jim
Hughes LAN Systems   | OR uunet!mcsun!ub4b!syteke!jim 
Brussels  
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Fri 8 Jun 90 15:02:02-CDT
From:      Matt Jonson <AFDDN.JONSON@GUNTER-ADAM.AF.MIL>
To:        kellen@uv4.eglin.af.mil
Cc:        tcp-ip@nic.ddn.mil, afddn.beach@GUNTER-ADAM.AF.MIL, afddn.wright@GUNTER-ADAM.AF.MIL, afddn.pm@GUNTER-ADAM.AF.MIL
Subject:   Re: I need help with subnetting
   Dan-

   First let me say a few things about your current problem and then talk
   about your future with respect to subnetting.  Chances are that the reason
   your sun isn't gatewaying is simply because your routes and your ifconfigs
   aren't set up right.

   Using your diagram, the suns behind the gateway must have (x being their
   host number):
	 route add 129.61.9.0 129.61.9.x 0
	 route add default 129.61.9.2 1
   That will insure that their packets get to the outside world.  However,
   the outside world won't know how to get to them unless each one of those
   machines (unless you use proxy arp) has:
	 route add 129.61.9.0 129.61.2.40 1

   Your gateway sun should have these commands performed somewhere during
   start-up:
	 route add 129.61.9.0 129.61.9.2 0
       * route add default 129.61.2.40 0
	 (I'll get back to the asterix later)
   That gateway sun should have a netmask of 255.255.255.0 on BOTH ethernet
   interfaces.  Welcome to subnetting.

   The preceding was written on the assumption that you have a class B
   network just kind of floating in space with no other gateways to anywhere.
   This will not work if there are any other gateways to other things
   on your ethernet.  If, for instance you have a gateway to milnet on this
   ethernet, you should configure it as the default route and the * route
   command from above becomes:
	 route add 129.61.0.0 129.61.2.40 0
	 route add default 129.61.x.y 1
	 route add othernet gateway 1
   At this point you will also need to add routes for every other different
   third octet address on your class B.  It's a pain -- your other option is
   to pick an arbitrary third octet to rehome everyone on or a higher subnet
   to mask off of.

   When this network grows, and gateways start appearing, this kind of
   addressing scheme will get extremely unwieldy.  You will have to do some
   subnetting to streamline things.  You should probably take a good look at
   where you see this net going in the future and think about who will and
   who will not be needing the capabilities of subnets.  Right now you really
   only have a class B ethernet, and except for this one hitch, that is still
   what you have.  If you don't subnet, you will have to make sure that every
   host on the net has a route to every other important gateway.
   But of course there's always proxy arp...

   You should probably try to migrate toward this kind of subnetting:

			     129.61.A.*
     host|net B --  129.61 __________________
	 |-----|GW|--------|   Subnet A     |                  +---SUN
     host|      --   A.a   |   main net     | 129.61 |---|129.61
			   |                |--------|SUN|-----| net C
			   |                |  A.x   |---| C.y |
	 |net D --  129.61 |                |                  +---SUN
	 |-----|GW|--------|                |
	 |      --   A.b   +----------------+

   In this scheme, your gateways will be the only things that have to know
   how to reach the other nets.  Your hosts will just have to know who their
   gateway is.  It is clearly superior to having to update everyones tables
   every time there is a change in the future.

   I noticed you were an Air Force user, so I figured we should get back to
   you.  We'd be happy to help you out with your (potential) subnetting
   problems.  That's one of our functions as the AF DDN PMO.  Please get back
   to us with the details of your net (who connected to, gateways, third
   octet numbers assigned...)

   Right now you are actually subnetting with all 8 bits of the third octet.
   That gives you 254 potential subnets.  You may only need to use the first
   three, four or five bits which will give you 8, 16 or 32 nets...

   POCs are Lt Matt Jonson, Darrel Beach, Capt Brad Wright.  AV: 446-4075


   Matt Jonson
   Network Systems Engineer
   afddn.jonson@gunter-adam.af.mil
   (205) 279-4075





-------
-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 13:38:50 GMT
From:      att!cbnewsi!yam@ucbvax.Berkeley.EDU  (toshihiko.yamakami)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A proposal on "comp.protocols.migrate.to.iso"
From article <NELSON.90Jun7130659@image.clarkson.edu>, by nelson@sun.soe.clarkson.edu (Russ Nelson):
> In article <4431@infmx.UUCP> kwang@infmx.UUCP (Kwang Sung) writes:
> 
>    	If you are saying same words to Korea or Japan Government/Industries/
>    Universities, they are going to laugh.

I believe Japanese industries will not laugh.
 
> I just went into 'irc' (Interactive Relay Chat), and did a '/links' command.
> The hosts that are linked into irc are listed below.  Not only is Europe
> well represented, so is Japan.  Perhaps you're right about OSI, but when
> people want to internetwork today, they get on the Internet.

I agree with you.

I know Korean industries are growing rapidly, these days.
However, as far as Japan is concerned, our industries
are short of both of TCP/IP engineers and ISO engineers.
We need both.

'International standard' is a nice word, however, it is a long way
to beat industrial standards proven effective.

To be honest, I am just a user for TCP/IP, little knowledge about
its implemetation details.
However, I have some experiences with ISO application layers
as an employee of NTT, a Japan communication giant:
	MHS implementation and multi-vendor conformance,
	ISODE 5.0 experimental use,
	member of Japanese body of ISO JTC 1/SC 18/WG 4.

From my understandings, there are lots of things to be fixed in
ISO application layer.
Even with Application Layer Structure(ISO SC21) and
Distributed Office Application Model draft(ISO SC18),
application structeres are not so clear.
There are lots of conflicting issues in ISO and CCITT application
standardization activities.
Group communication is under discussion, however, not yet focused.

So Japanese industries cannot throw away Internet protocol suites
in next decade.
At least, I cannot imagine it.

-- yam
-- 
Toshihiko YAMAKAMI(NTT, Japan) Resident visitor in Bell Labs until Feb 1991
 Room 4G634, AT&T Bell Labs, Crawfords Corner Rd. Holmdel, NJ 07733-1988
 Tel:(201)949-5742	e-mail: yam@vax135.att.com (was: yam@nttmhs.ntt.jp)
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 13:46:20 GMT
From:      rochester!bukys@pt.cs.cmu.edu  (Liudvikas Bukys)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <392@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
>> It is not good practice to allow random anonymous users to
>> scribble into directories ...
>
>The obvious counter-example to this is /usr/spool/uucppublic, which
>is almost always world-writable, yet there seem to be no reports of
>even minor problems with this.  It's usually considered a useful
>part of uucp, and an assortment of tools are around (uuto/uupick for
>example) are layered on top of it.
>
>It's true (in fact, it's obvious) that one could fill up a victim's
>disk partition.  But this isn't doesn't seem to trigger call for 
>shutdowns of all uucp sites until the horrible security problems 
>are fixed.  (Well, OK, users of competing packages *do* make such
>calls, but not uucp's users. ;-)

1.  Here's one "minor problem" report: I have heard that .rhosts
    files have been uucped into ~uucp.  Think about it.

2.  Most uucp connections are point-to-point, many (most?) sites
    have a distinct login for each neighbor, and pretty thorough
    logging is done.  Under these circumstances, it is easy to trace
    a culprit back to a specific neighbor machine, and there is
    something you can do about it if no appropriate response is
    heard -- sever your connection to that neighbor.
-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 14:00:15 GMT
From:      ndsuvm1!plains!lodin@cunyvm.cuny.edu  (Joe Schmo)
To:        tcp-ip@nic.ddn.mil
Subject:   Duplicate Internet address on same network

I have two machines on my network using the same Internet address, and without
network analysis tools, I am having trouble identifying the culprit.  Could
somebody please tell me which manufacturer uses the Ethernet address
AA:0:4:X:X:X.


Thanks alot...

Reply to:
Steve Lodin
lodin%koiasvr01.uucp@ee.ecn.purdue.edu or lodin@koess.gm.hac.com
-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 16:46:12 GMT
From:      mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: trash message from usenet (BIFF)
In article <393@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
   In article <23824@bellcore.bellcore.com>, mo@messy.bellcore.com (Michael O'Dell) writes:
      The notion that mail or mailing lists on the Internet are either
      "secure" or "accountable" is simply hysterical.

   What would it mean for a list to be secure?

   Would this perhaps mean that nobody not on the mailing list could
   send mail to mlist@foo?  If someone has a contribution to make to a
   discussion... they should be able to contribute.

Some mailing lists have implemented filters to block users who
consistently and persistently post inflammable messages with the
particular purpose of inciting wars.  These mailing lists tend to be
ones carrying political or religious discussions and other topics that
are prone to particular emotionalism.  I don't know of any
technically-oriented list that has needed to take this step.

   Does secure perhaps mean that the mail can't go to anyone not on
   the list? ... I can always ... mail a copy to someone else.  I
   can't imagine how the manager of the mailing list could prevent my
   doing this.

This is the practice on certain security-oriented mailing lists, where
the list maintainer requests that members not forward the messages to
anyone not on the list, and not keep them in publicly-readable places.
The list maintainer enforces this policy by threatening to remove any
member from the list, upon sufficient proof of misbehavior.

   So when someone asks for a secure mailing list, what could they
   possibly have in mind?  Is this just a vague, fuzzy buzz-phrase, or
   does it have some specifiable meaning?

When I hear "secure mail" I generally think that it means that the
mail comes from the person named in the From: line, and goes only to
the person named in the To: line.  If the From: line is inaccurate
it's either a bug or a forgery, and if someone other than those listed
in the To: line reads the mail, it's either a bug or snooping.  I
think similar things about mailing lists, but in a one-to-many
context.

There are plenty of research projects in secure communications.  One
area is secure electronic mail.  But the S in SMTP is Simple, not
Secure.  Don't get your hopes up with something so Simple.
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 16:48:34 GMT
From:      maa@ssc-vax.UUCP (Mark A Allyn)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   tcp for VMS and tcp over fiber-optics

I have an application where I have a VAX running VMS in a data center 
in one building and an office with a Macintosh running Appletalk along
with a Postscript printer in another building. Company security requires
that the only means of communications between the two locations is fiber
optics.

In the future, we may want to install a Sun or other Unix/tcp/nfs type
goody in the same room as the Macintosh and the printer. What I need help is
with the following.

The VAX has VMS and DECNET. Because we may have future Unix/tcp type 
stuff in our environment, we would like to have all communication via TCP.
I need some suggestions on what software to get for the VAX so that it can 
run TCP and preferably also NFS. I would also like something that includes
the necessary libraries and include files so that I can write applications
using sockets for both stream stuff and datagrams. I have heard of some names
including Wollengrad (sp?) but don't know anything about them. I need 
company names and phone numbers.

I need something that provides an ethernet bridge through a fiber optic. The
VAX has Ethernet which I hope to use for the TCP as well as the DECNET. I
also hope to get Ethernet for the room with the Macintosh and the future
Sun workstation. The two Ethernets need to be able to talk to each other 
through the fiber optic cable.

The Macintosh uses Appletalk which has its own set of protocols and hardware.
I need something to act as a gateway between Appletalk and the Ethernet with
TCP. I would like to provide the Macintosh with its own IP address and have
it appear as any other IP machine on the network. 

Since the Macintosh cannot act as a server since it is a single process
machine, I need something to act as a TCP server for the printer. The printer
should have its own IP address; that way, I can access it from any machine
on the network. Any Suggestions?

Can anyone please shed some light on any of this? I appreciate any company
names, books on this subject, or if possible to talk with someone who has
done this type of stuff in the past. I can be reached at:
(206) 773-8981 (206) 773-2957 (206) 773-8308 - days
(206) 526-8852 - evenings (til 9 pm Pacific time)

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 17:53:25 GMT
From:      sgi!rpw3%rigden.wpd.sgi.com@ucbvax.Berkeley.EDU  (Rob Warnock)
To:        tcp-ip@nic.ddn.mil
Subject:   XTP multicast (was: VMTP)
In article <8335BA51047F00029B@VAXF.COLORADO.EDU>
LISCHKA_J@CUBLDR.COLORADO.EDU writes:
+---------------
| I'm designing a network in which a host running UNIX System 5 and
| using TCP-IP over Ethernet sends the same message to 16
| workstations.  Rather than send the same message 16 times, would
| like to broadcast the message to the workstations only once.
| Can't use UDP because the workstations have to acknowledge
| receipt of the update.  Do you know if there are any flavors of
| VMTP that will do what I need?  
+---------------

Don't know about VMTP, but the reliable multicast mode in XTP does
exactly that. Depending on how you twiddle the policy knobs, the
mechanism supports the range of multicast from "fire-n-forget"
datagrams (NOERROR) at one end of the spectrum, through "mostly"
reliable datagrams and streams ("mostly" here means "as good as
you want" depending on how many retransmission buffers are kept)
in the middle to "completely reliable" (positive acknowledgement
from each host that the data has been delivered all the way up
to the user process) datagrams and streams at the other end.

The "mostly reliable" mode can offer an arbitrarily low error
rate without requiring a reliable (or indeed *any*) group
membership protocol. The "completely reliable" mode does
require an external method of determining group membership.

Code for XTP is still under development, and is shared on an ongoing
basis with XTP Technical Advisory Board (TAB) members and Research
Affiliates (RA's). The most recent release [March 1990] of the
Unix-based XTP Kernel(-resident) Reference Model (KRM) included an
implementation of the "mostly reliable" multicast mode. For more
information about participating, or for a current "press kit",
please write/call/email/fax:

	Larry Green, President		Phone: (805)965-0825
	Protocol Engines, Inc.		FAX:   (805)687-2984
	1900 State Street, Suite D	Email:	green@pei.com
	Santa Barbara, CA  93101	   or	xtp-request@pei.com

The press kit includes the XTP Protocol Specification, Revision 3.4
(17 July 1989), but be sure to ask for it explicitly anyway.


-Rob

-----
Rob Warnock, MS-9U/510		rpw3@sgi.com		rpw3@pei.com
Silicon Graphics, Inc.		(415)335-1673		Protocol Engines, Inc.
2011 N. Shoreline Blvd.
Mountain View, CA  94039-7311
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Jun 90 22:09:21 EDT
From:      louie@sayshell.umd.edu (Louis A. Mamakos)
To:        medin@nsipo.nasa.gov, tcp-ip@nic.ddn.mil
Cc:        
Subject:   Re: Mourning of the passing of the ARPANET
Milo,

If I'm not mistaken, the last production PSN on the ARPANET is/was PSN #17
at the University of Maryland.  It was but a shell of a network before its
time had come.. the only connection being an IST to the Princeton PSN, with
no host ports still in use.  A network with no user ports.

I had the honor/pleasure of turning off the power switch myself just a few
days ago..

louie


>Folks, it appears that the ARPANET has quietly passed away into the annals
>of network history.  June 1 was the official cut off date I believe, and I
>did some traceroute's to a net 10 host and not even the DDN Core knew
>about a route to net 10!  Not even the Mailbridge at BBN in Cambridge.
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 20:21:39 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!shaikh@ucsd.edu  (Asad Shaikh)
To:        tcp-ip@nic.ddn.mil
Subject:   Floation Point problem
I am using Phil Karan KA9Q code for my distributed system.But I am unable
to work with floating point numbers.Even I enabled float in makefile.
When ever I try to print statement like this
printf("%f\n",a);
I get divide error.
If some one has used this code for float please send me message.
Thanks
ASAD SHAIKH
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 20:38:02 GMT
From:      mailrus!umich!umeecs!itivax!vax3.iti.org.iti.org!mm@iuvax.cs.indiana.edu  (Michael McFarland)
To:        tcp-ip@nic.ddn.mil
Subject:   CMOT and MIB

Can someone tell me where I can get the
latest status of CMOT? I have RFC 1095.

Also the MIB? I have RFC 1066.

Are there two MIBs now? One for SNMP, one for CMOT?

Has either RFC been superseded? 

I keep hearing these rumors...


Thanks, 
	Spike
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      8 Jun 90 20:52:27 GMT
From:      hpcc01!hpcuhb!hpindda!subbu@hplabs.hpl.hp.com  (MCV Subramaniam)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP source wanted for HP9000/340
>In article <703@coma.UUCP> reiner@coma.UUCP (Reiner Petersen) writes:
>>In article <1990Jun1.074348.7712@ecn.nl> bernards@ecn.nl (Marcel Bernards) writes:
>>[] Hello NetReaders,
>>[] I'm looking for (PD) SLIP source for HP9000/340 series running HPUX 6.5/7.0.
>>We are interested too.
>>
>>-- reiner
>
>Well, this makes about 50 requests over the last year or so in this forum,
>with absolutely no response from hp. The response is no better from
>sales reps :-). Is there any hope that slip or cslip will be available
>sometime in the near future, or should I just give up and buy a couple
>or Sun machines? This is important! Please let us know.
>
	We are working on SLIP for the HP-UX 8.0 release. Please contact
	your local HP representative if you need more information.

-Subbu
-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 90 00:55:02 GMT
From:      fernwood!vixie!asylum!karl@apple.com  (Karl Auerbach)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Efficiency (or lack thereof) of ASN.1. Was: Re: What is the IAB?
In article <266E82D2.592A@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes:
>The restricted variant of ASN.1
>that is used in SNMP can actually be pretty quick to parse.  Most of the
>publically available ASN.1 parsers that I have seen are overly complex...

"pretty quick to parse" is a relative term.  I've optimized my ASN.1
tools to handle the SNMP subset and they are fairly efficient, on a
relative scale.

The trouble is that even the limited subset of ASN.1 used by SNMP
represents a fair computational load.  Optimizing it and saying that
the result is good is a lot like saying that you have optimized a
bubble sort -- no matter how well optimized, it is bad news when presented
with anything more than trivial input.

The argument that one can optimize ASN.1 is a red herring.  The
trouble is that ASN.1 requires that one look at a significant number
of bytes, no matter how well optimized.

For things where one has a fairly fixed structure (SNMP being a prime
example) the flexibility of ASN.1 isn't warranted.  As a general
representational tool ASN.1 is OK (not great, but OK).  But for things
that happen often and where the content is fairly predictable (in
structure), a less universal tool ought to be considered.

I'm into my fourth ASN.1 BER encoder/decoder tool.  It does everything
in the ASN.1 BER specification (except floating point) and obeys all
kinds of constructorization/definite-indefinite length strategies and
I have not yet found an input sequence that breaks it (although
massivly deep constructors can cause it to reject an otherwise
legitimate input sequence.)  It was designed to be moved to hardware
as a co-processor.  I'm still profiling and optimizing the code paths
to do fastpathing, bulk operations and pattern matches when possible.
It is small (less than 20K bytes of compiled code on an Intel *86
processor) and, for ASN.1, fast.

My ASN.1 encoder/decoder for SNMP is far smaller, about 3K bytes of
compiled code on an Intel *86 class machine.  And considerably faster.
But even with this efficient code (at least I think it is efficient) I
find that ASN.1 parsing/encoding burns a significant portion of the
overall CPU cycles required to handle an SNMP request.

The potential flexibility of ASN.1 just isn't worth the expense in
situations (like SNMP) where we don't need the flexibility.

We of the internet community ought not to fall into the OSI trap of
thinking that just because ASN.1 exists that it is the perfect tool.*

				--karl--

*I used to own an English sports car (Jensen Healy) and I carried a
set of calibrated hammers.  Each was tuned to correctly bash whatever
thing wasn't working at the time.  A tiny hammer for the carburators,
a mallet for the fuel pump, and a sledge for the front suspension.  To
me, the use of ASN.1 for SNMP is akin to using the sledge to adjust
the carburator.
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jun 90 11:48:28 HST
From:      Torben Nielsen <torben@foralie.ics.Hawaii.Edu>
To:        swrinde!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!news@ucsd.edu, tcp-ip@NIC.DDN.MIL
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
These statements about the glorious OSI environment in Korea sound pretty
silly. KAIST has just established a 56Kbps link to the Internet. And
they at least claim to be building a larger IP network. Also, I just finished
installing the *fourth* 64Kbps link to Tokyo. All of them running IP.

No doubt there's interest in OSI migration in both Japan and Korea. But - and
this is my personal impression - neither is much further along that path than
we are. Unless you count their greater reliance on X.25 and take that as
a plus.....

Australia and New Zealand have extensive IP networks too. They're simply
being pragmatic. Actually, the Australian network (AARN) is about the
most impressive accomplishment in IP network construction I can think of.
They connected just about all the universities in the country in one fell
swoop; the whole thing was planned and executed very nicely.

							Torben


-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jun 90 14:22:51 HST
From:      Torben Nielsen <torben@foralie.ics.Hawaii.Edu>
To:        intercon!news@uunet.uu.net, tcp-ip@NIC.DDN.MIL
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
In response to Kwang Sung's message, Amanda Walker states:

>In article <4431@infmx.UUCP>, kwang@infmx.UUCP (Kwang Sung) writes:
>> If you are saying same words to Korea or Japan Government/Industries/
>> Universities, they are going to laugh.
>
>They haven't so far.  TCP/IP is used by many Japanese universities and
>industry leaders for the reason that it works and is available right now.
>They may be doing research into OSI and MAP/TOP, but they still use TCP/IP
>to get their work done.

The key point here is what the governments are saying versus what the users
are actually doing. Certain government groups may be favoring OSI and pouring
lots of money into ``OSI networks".  But most all of the actual users I
know of are busily putting together IP networks. Even if they have to raise
the funds from non-government sources as often happens. For the users - largely
scientists, R&D people and students - the key is communicating with their
counterparts elsewhere. Currently the Internet is the best vehicle for doing
so. The great majority of users simply don't give a damn what the protocols
are. They merely wish to get the job done as easily and conveniently as 
possible.

There's a *lot* of work to be done to make *any* kind of network support
actual user needs. It would sure be nice if we could spend more time on that
instead of on silly religious wars.

Kwang Sung: from what I've seen, Korea has a long ways to go before they
have any kind of national network supporting the whole research community.
So does Japan. And so does the US for that matter. If you're interested in
how to do national networking *efficiently* (in terms of reaching your
audience and making it possible for them to do what they need to do), take
a look at the Australian AARN. It's very well done.


						Torben
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Sat, 09 Jun 90 16:40:16 -0700
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        karl@asylum.sf.ca.us (Karl Auerbach)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Efficiency (or lack thereof) of ASN.1. Was: Re: What is the IAB?
Karl - we've reached a circular discussion here.  The SNMP PDUs were
written in ASN.1 so as to be as fixed and predictable as possible.  That
is one method that was used in order to help out people optimizing their
encoders and decoders.

I suppose the PDUs could have been written in such a way as to use more
of ASN.1's expressive-ness, but the only benefit would be to be more
elegant in an academic fashion with no gain in functionality.  Of
course, the drawback would be that it would be nigh impossible to do
optimizations.

Sure, SNMP could have used a special-purpose, roll your own encoding
algorithm.  And sure, it could be faster than any form of ASN.1 known to
man; probably an order of magnitude faster, if you were very, very lucky.

And what would that cost exactly?  Well, let's see, it would be yet
another special-purpose thing useable only for one task; it would have
associated with it the usual debugging cost for the designers; it would
also have the usual start-up and training costs for the people writing
implementations.  So it would have a lot of hidden costs that would slow
development and hinder deployment.  (And to add insult to injury it
would still need to have things like ASN.1 object identifiers to provide for
decent naming and extensibility.)

Now I hate to be the one to point this out, but technological issues are
hardly boolean.  Any time someone says "X is better than Y", they have
neglected to state the criteria associated with that judgement.  As
such, there is more to consider than just raw speed when discussing this
issue. 

/mtr
-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jun 90 09:06:46 EDT
From:      Hans-Werner Braun <hwb@merit.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
Milo:

There is no need to be mourning. (D)ARPA did a great service to the networking
community over the last many years in developing and providing a research
facility that emerged into operational infrastructure. Many spinoffs were
created, both in the government (including your NASA Science Network) as
well as other places, including internationally. As we all know, DARPA is
still continuing to do network research, that should yield further results
and benefits to the networking community. There have never been more users
and equipment using technology developed for the ARPANET than there are today.
The ideas, the spirit and the technological thrust of the ARPANET is surviving
in its children. At DARPA and elsewhere.

	-- Hans-Werner
-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jun 90 12:38:31 PDT
From:      infmx!moose!kwang@uunet.UU.NET (Kwang Sung)
To:        lll-winken!psuvax1.uucp!CMSA.BERKELEY.EDU!CLIFF@uunet.UU.NET, tcp-ip@nic.ddn.mil

Hi...

	Recently, I've proposed a new newsgroup "comp.protocols.migrate.to.iso".
I've received so many responses. Among those, I've selected some best ones, 
after I've thrown out some bad ones. I couldn't reply to all of you, since it's
so many. However, I might be able to answer thru this network. I think some 
people still don't understand how/where this networking world is going to. 
Absolutely, and positively, the world is moving toward one OSI world !!,
even if ISODE has screwed up OSI world a little bit. 

	Moreover, a lot of people were also interested in the network 
technology in Korea. I would like explain later as much as I know about it. 
I am sure those informations should be much more updated now than a year ago.
Those informations were based on the systems/networks on KAIST, KIST/SERI, 
ETRI, RIST, Korea Defense Department, DACOM, SNU, and several industries
in Korea.

	First of all, I would like to show some responses in order to prove
why we need to create those new newsgroup. Here are some beautiful statements.
I couldn't read them alone !!

-------------------------------------------------------------------------------
>From: uunet!unx.dec.com!jjf (8N8-FRANEY)

>Kwang and Marshall,

>Our postnews is currently broken so sorry for the direct mailing.  The topic
>you are discussing is so fresh and hot in my veins that I had to join in.

>I recently returned from a symposium in Washington DC that explored the
>transisition from TCP/IP to OSI.  The word is transition since migration means
>travel to a certain place with intention to return.  There will be no intention
>to return to TCP/IP once OSI is established.

>Firstly, the people who ran and participated in the symposium can easily be
>recognized as leaders in communication technology.
>Dr. John McQuillan - consultant and free lance author of about 200 articles
>	on data communication, designed and implemented parts of ARPANET.
>Leonard Kleinrock - Professor of CS at UCLA, author of intense queing theory 
>	textbooks, member of Natinal Academy of Engineering, Guggenheim and
>	IEEE fellow, etc...
>Dr Vintont Cerf - Vice President of the Corporation for National Research
>	Initiatives, Chariman of Internet Activities Board, extensively
>	involved with creation and growth of ARPANET.
>Dr. Jeffery Case - deisgnier of SNMP and other network protocols, professor
>	of CS at U of Tenn.
>Larry Green - founder of Protocol Engines, Inc (developting XTP), working on
>	networking technologies for the last 25 years.
>Bill Johnson - VP of Networks and Communications at DEC.
>Don Holtz - Products manager for IBM's OSI, MAP and TCP/IP communciations
>	development.
>Bob Burnett - vp of Engineering for cisco.
>John Hart - VP of Engineering for Vitalink.
>etc...

>All that follows come from the discussions at this symposium.

>The major reason for a slower than expected transition to OSI is the installed
>base.  TCP/IP is only a small part of the installed base with 1500 networks.
>PC Lans total over 1 million networks, IBM SNA networks control hundreds of
>thousands of terminals, DECnet has over 700,00 nodes (hosts and servers) and
>DEC has sold 3,000,000 ethernet ports to 61k customers.

>The argument that OSI is technically inferior to TCP is a myth.  TCP and TP4
>are practically the same (so much the same that people don't see a benifit
>of using TP4 over TCP.)  Many of the TCP users will have the industry believe
>that the Dod protocols having been used and tested over the past 20-30 years
>is better than a set of protocols designed by open consensus.

>For an attack on TCP/IP, the experts (including Cerf) pointed out the TCP/IP
>was never meant to support a network as large as the internet.  In fact,
>at the rate of growth of TCP/IP, it will run out of address space within the
>next 5-6 years.  SNMP is an example of hind-sight engineering, as is
>sub-networks.  These are features designed into TCP after years of operation.
>OSI has the advantage that it was able to use what was learned by TCP/IP people
>to design the entire protocol set.

>TCP/IP is an old technology.  ALthough it has run on FDDI it wasn't designed
>for the high tech media.  OSI also has limitations here but has afforded
>a modular stack to allow replacements of layers for progressive evolution.
>TCP/IP will not support the upcomming applications such as multimedia as
>well as OSI will.  TCP/IP is connectionless, OSI is connection oriented.
>Multimedia needs multiple synchronized data circuits.  Datagrams can't be lost
>or take variously different routes (TCP/IP).

>The major reason why TCP/IP is so prevalent in computer networks today is
>not because it is technically superior than anything that was put out before.
>But because it was given away as standard equipment on millions of
>workstations.  It was part of the BSD UNIX that was sold on SUN boxes.
>If not for this fact alone, there probably would not be ANY country wide
>interoperable protocol.

>OSI is coming of its own.  GOSIP is US govt's requirement list for computer
>procurements.  Initially specifying a small subset of OSI, it will evolve
>to include the entire specifications.  No company will win a GOSIP bid
>without OSI.  And the US Govt is will start using GOSIP to describe contracts
>in August 1990.

>DEC has commited itself to OSI.  All of its customers computer network nodes
>are going to be converted to OSI with the release of DECnet Phase V.  I work
>for DEC but not in communications engineering but please don't think this is a
>plug.  DEC is the only company to be committed to converting its installed
>base of proprieatary protocol to OSI.  DECnet OSI gateways are expected to be 
>released in December (don't quote me, I am not speaking for DEC here).
>With all DECnet as an OSI network, OSI will be on its way to being more
>accepted.

>Other companies are committed to OSI.  IBM (good-luck), HP, UNISYS, cisco,
>Vitalink, RETIX (has implemented OSI in streams) and others.  With corporate
>support, OSI will move faster.  (A point made by McQuillan is that the Ethernet
>became a commercial success because research, standards and corporate
>communities came together.  For OSI only standards community and more
>the corporate community have endorsed it.  The research community is
>behind TCP/IP for good reasons).

>Corporations are developing transision strategies.
>There are many way to transision to OSI from any protocol.  There are OSI
>gateways, application gateways, trasnport bridges and RFC 1006.  Some customers
>are buying small OSI networks for experimentation only (this approach increases
>expertise before the network becomes critical.)

>TCP/IP is NOT popular in Europe.  It doesn't surprise me that its not popular
>in Korea either.  The big reason here is that the PTTs that implement and
>use the networks in Europe are connection oriented.  They wand Virtual
>Circuits.  TCP/IP is a datagram network and is not acceptable.
>Although there are TCP/IP node across the world, the North
>American Continent is where it is most poular.  Europe, conerned about its 1992
>common community has looked to OSI as common protocol since its inception.
>Europe is poised to take advantage of OSI and will have nothing to do with
>TCP/IP.  Europe is composed of many PTTs that use X.25 and other CCITT
>protocols, not TCP/IP.

>The future of internetworking is not simple.  The experts see TCP/IP
>as an integral part of the worlds networking infrastructure.  But most will
>agree that the core of the infrastructure must be based on a globally
>accepted protocol, no matter how long it takes to implement. This is OSI.
>DEC sees OSI as an enterprise wide backbone, with gateways for proietary
>and early public networking protocols.
>Basically, the world is saying that any and all protocols are going to be uses.
>But the protocol itself is about important to most users as whether your car
>has efi or carbeurator that is not a significant amount.  Users want
>interoperability.  OSI, TCP, PC Lan, SNA, etc.. will be
>with us for a long time (10-15-20-30 years).  The one that outlasts
>the rest will be the ones that best demonstrate interoperability.
>Think long term.

>Regards,
>John Franey

>These comments are generated from the ideas presented at the symposium
>entitled:
>TCP/IP & OSI, The Interoperability Challenge, Washington, D.C.,
>May 21-23 1990 hosted by the Technology Transfer Institute, Santa Monica, CA.
>These ideas are not mine and I am not speaking for my company in any respect.
--------------------------------------------------------------------------------

>From: att!lzaz!jer

>I support your suggestion.
>joe ritacco

--------------------------------------------------------------------------------

>From: uunet!sunkist.West.Sun.COM!gene.saunders (Gene Saunders Sun SE Irvine CA)

>I'd suggest the newsgroup be named "comp.protocols.tpicp.to.iso".
>More descriptive.

>Gene Saunders   \ Gene.Saunders@West.Sun.COM       \ 72265,23 (CompuServe)
>Systems Engineer \ saunders@sunkist (local)         \ GSAUNDERS (GEnie)
>Sun Microsystems  \ #saunder@ProteonW (from Novell)  \ ..!sunkist!saunders

--------------------------------------------------------------------------------

>From: Amit Parghi <uunet!watmath!watcgl.waterloo.edu!aparghi>
>Organization: Computer Graphics Lab, University of Waterloo

>Don't use the name "comp.protocols.migrate.to.iso"; since there are
>already groups under "comp.protocols.iso", call it
>"comp.protocols.iso.migration".

>You claim the state-of-the-art engineers in Korea and Japan don't much
>care for TCP/IP; instead, they use (I assume) ISO solutions, which I guess
>would mean full ISO stacks implemented efficiently across heterogeneous
>hardware and physical media.  I, for one, would be very interested to hear
>of such developments, especially since serious development of efficient and
>*useful* implementations in Europe and North America still seems to be some
>ways away.  Do tell us more.

--------------------------------------------------------------------------------

>From: Steven Willis <nsc!amdahl!ames!harvard!talcott!wellflt!swillis>

>Consider this a vote for the newsgroup. There's an effort in the IETF and
>ANSI to provide dual IS-IS routing for both IP and OSI. Ross Callon is
>the chairman; you can reach him at callon@bigfut.enet.dec.com.

--------------------------------------------------------------------------------


Hi...

	Recently, I've proposed a new newsgroup "comp.protocols.migrate.to.iso".
I've received so many responses. Among those, I've selected some best ones, 
after I've thrown out some bad ones. I couldn't reply to all of you, since it's
so many. However, I might be able to answer thru this network. I think some 
people still don't understand how/where this networking world is going to. 
Absolutely, and positively, the world is moving toward OSI world !! 

	A lot of people were also interested in the network technology 
in Korea. I would like explain later as much as I know about it. 
I am sure those informations are now much more updated than a year ago.
Those informations were based on the systems/networks on KAIST, ETRI, RIST, 
Korea Defense Department, DACOM, SNU, and several industries in Korea.

	First of all, I would like to show some responses in order to prove
why we need to create those new newsgroup. Here are some beautiful statements.
I couldn't read them alone !!

-------------------------------------------------------------------------------
>From: uunet!unx.dec.com!jjf (8N8-FRANEY)

>Kwang and Marshall,

>Our postnews is currently broken so sorry for the direct mailing.  The topic
>you are discussing is so fresh and hot in my veins that I had to join in.

>I recently returned from a symposium in Washington DC that explored the
>transisition from TCP/IP to OSI.  The word is transition since migration means
>travel to a certain place with intention to return.  There will be no intention
>to return to TCP/IP once OSI is established.

>Firstly, the people who ran and participated in the symposium can easily be
>recognized as leaders in communication technology.
>Dr. John McQuillan - consultant and free lance author of about 200 articles
>	on data communication, designed and implemented parts of ARPANET.
>Leonard Kleinrock - Professor of CS at UCLA, author of intense queing theory 
>	textbooks, member of Natinal Academy of Engineering, Guggenheim and
>	IEEE fellow, etc...
>Dr Vintont Cerf - Vice President of the Corporation for National Research
>	Initiatives, Chariman of Internet Activities Board, extensively
>	involved with creation and growth of ARPANET.
>Dr. Jeffery Case - deisgnier of SNMP and other network protocols, professor
>	of CS at U of Tenn.
>Larry Green - founder of Protocol Engines, Inc (developting XTP), working on
>	networking technologies for the last 25 years.
>Bill Johnson - VP of Networks and Communications at DEC.
>Don Holtz - Products manager for IBM's OSI, MAP and TCP/IP communciations
>	development.
>Bob Burnett - vp of Engineering for cisco.
>John Hart - VP of Engineering for Vitalink.
>etc...

>All that follows come from the discussions at this symposium.

>The major reason for a slower than expected transition to OSI is the installed
>base.  TCP/IP is only a small part of the installed base with 1500 networks.
>PC Lans total over 1 million networks, IBM SNA networks control hundreds of
>thousands of terminals, DECnet has over 700,00 nodes (hosts and servers) and
>DEC has sold 3,000,000 ethernet ports to 61k customers.

>The argument that OSI is technically inferior to TCP is a myth.  TCP and TP4
>are practically the same (so much the same that people don't see a benifit
>of using TP4 over TCP.)  Many of the TCP users will have the industry believe
>that the Dod protocols having been used and tested over the past 20-30 years
>is better than a set of protocols designed by open consensus.

>For an attack on TCP/IP, the experts (including Cerf) pointed out the TCP/IP
>was never meant to support a network as large as the internet.  In fact,
>at the rate of growth of TCP/IP, it will run out of address space within the
>next 5-6 years.  SNMP is an example of hind-sight engineering, as is
>sub-networks.  These are features designed into TCP after years of operation.
>OSI has the advantage that it was able to use what was learned by TCP/IP people
>to design the entire protocol set.

>TCP/IP is an old technology.  ALthough it has run on FDDI it wasn't designed
>for the high tech media.  OSI also has limitations here but has afforded
>a modular stack to allow replacements of layers for progressive evolution.
>TCP/IP will not support the upcomming applications such as multimedia as
>well as OSI will.  TCP/IP is connectionless, OSI is connection oriented.
>Multimedia needs multiple synchronized data circuits.  Datagrams can't be lost
>or take variously different routes (TCP/IP).

>The major reason why TCP/IP is so prevalent in computer networks today is
>not because it is technically superior than anything that was put out before.
>But because it was given away as standard equipment on millions of
>workstations.  It was part of the BSD UNIX that was sold on SUN boxes.
>If not for this fact alone, there probably would not be ANY country wide
>interoperable protocol.

>OSI is coming of its own.  GOSIP is US govt's requirement list for computer
>procurements.  Initially specifying a small subset of OSI, it will evolve
>to include the entire specifications.  No company will win a GOSIP bid
>without OSI.  And the US Govt is will start using GOSIP to describe contracts
>in August 1990.

>DEC has commited itself to OSI.  All of its customers computer network nodes
>are going to be converted to OSI with the release of DECnet Phase V.  I work
>for DEC but not in communications engineering but please don't think this is a
>plug.  DEC is the only company to be committed to converting its installed
>base of proprieatary protocol to OSI.  DECnet OSI gateways are expected to be 
>released in December (don't quote me, I am not speaking for DEC here).
>With all DECnet as an OSI network, OSI will be on its way to being more
>accepted.

>Other companies are committed to OSI.  IBM (good-luck), HP, UNISYS, cisco,
>Vitalink, RETIX (has implemented OSI in streams) and others.  With corporate
>support, OSI will move faster.  (A point made by McQuillan is that the Ethernet
>became a commercial success because research, standards and corporate
>communities came together.  For OSI only standards community and more
>the corporate community have endorsed it.  The research community is
>behind TCP/IP for good reasons).

>Corporations are developing transision strategies.
>There are many way to transision to OSI from any protocol.  There are OSI
>gateways, application gateways, trasnport bridges and RFC 1006.  Some customers
>are buying small OSI networks for experimentation only (this approach increases
>expertise before the network becomes critical.)

>TCP/IP is NOT popular in Europe.  It doesn't surprise me that its not popular
>in Korea either.  The big reason here is that the PTTs that implement and
>use the networks in Europe are connection oriented.  They wand Virtual
>Circuits.  TCP/IP is a datagram network and is not acceptable.
>Although there are TCP/IP node across the world, the North
>American Continent is where it is most poular.  Europe, conerned about its 1992
>common community has looked to OSI as common protocol since its inception.
>Europe is poised to take advantage of OSI and will have nothing to do with
>TCP/IP.  Europe is composed of many PTTs that use X.25 and other CCITT
>protocols, not TCP/IP.

>The future of internetworking is not simple.  The experts see TCP/IP
>as an integral part of the worlds networking infrastructure.  But most will
>agree that the core of the infrastructure must be based on a globally
>accepted protocol, no matter how long it takes to implement. This is OSI.
>DEC sees OSI as an enterprise wide backbone, with gateways for proietary
>and early public networking protocols.
>Basically, the world is saying that any and all protocols are going to be uses.
>But the protocol itself is about important to most users as whether your car
>has efi or carbeurator that is not a significant amount.  Users want
>interoperability.  OSI, TCP, PC Lan, SNA, etc.. will be
>with us for a long time (10-15-20-30 years).  The one that outlasts
>the rest will be the ones that best demonstrate interoperability.
>Think long term.

>Regards,
>John Franey

>These comments are generated from the ideas presented at the symposium
>entitled:
>TCP/IP & OSI, The Interoperability Challenge, Washington, D.C.,
>May 21-23 1990 hosted by the Technology Transfer Institute, Santa Monica, CA.
>These ideas are not mine and I am not speaking for my company in any respect.
--------------------------------------------------------------------------------

>From: att!lzaz!jer

>I support your suggestion.
>joe ritacco

--------------------------------------------------------------------------------

>From: uunet!sunkist.West.Sun.COM!gene.saunders (Gene Saunders Sun SE Irvine CA)

>I'd suggest the newsgroup be named "comp.protocols.tpicp.to.iso".
>More descriptive.

>Gene Saunders   \ Gene.Saunders@West.Sun.COM       \ 72265,23 (CompuServe)
>Systems Engineer \ saunders@sunkist (local)         \ GSAUNDERS (GEnie)
>Sun Microsystems  \ #saunder@ProteonW (from Novell)  \ ..!sunkist!saunders

--------------------------------------------------------------------------------

>From: Amit Parghi <uunet!watmath!watcgl.waterloo.edu!aparghi>
>Organization: Computer Graphics Lab, University of Waterloo

>Don't use the name "comp.protocols.migrate.to.iso"; since there are
>already groups under "comp.protocols.iso", call it
>"comp.protocols.iso.migration".

>You claim the state-of-the-art engineers in Korea and Japan don't much
>care for TCP/IP; instead, they use (I assume) ISO solutions, which I guess
>would mean full ISO stacks implemented efficiently across heterogeneous
>hardware and physical media.  I, for one, would be very interested to hear
>of such developments, especially since serious development of efficient and
>*useful* implementations in Europe and North America still seems to be some
>ways away.  Do tell us more.

--------------------------------------------------------------------------------

>From: grieve@cos.com (David Grieve)
>Organization: Corporation for Open Systems, McLean, VA

>I would call it "comp.tcp.osi.transition"

>Migration means you go away and then come back.  Transition means
>you go away for good.

>grieve@cos.com OR  {uunet,  decuac, sun!sundc, hadron, hqda-ai}!cos!grieve
>DISCLAIMER:  Opinions expressed are not necessarily those of the
>Corporation for Open Systems, its members, or any standards body. 

--------------------------------------------------------------------------------

>From: nsc!asylum.sf.ca.us!karl (Karl Auerbach)

>	I propose a comp.protocols.migrates.back.to.tcp group to
>handle the situation when folks find out that ASN.1 eats all the cpu
>cycles and that the word "open" in OSI is something akin to the "open"
>invitation that a snake makes to a mouse when the snake opens its
>mouth.

I think this one was one of the junk mails. But it's funny !!

-------------------------------------------------------------------------------


	Next, I would like to introduce some networking activities in Korea.
Obviously, these informations must be updated now. However, this is what I
know about. One of their networks, KREONet is the National Computer Network
to provide networking services for the whole Korea R&D community. It is 
developed, managed and operated by KIST/SERI. Initially, they used TCP/IP, X.25,
SNA as interim protocols. However, they were migrated to OSI thru ISODE-POSIX,
Dual Protocol Hosts, TS-Bridge, and Application Gateways.

	They are interconnecting 8 cities as 9.6 Kbps and 56 Kbps leased line.
Especially, they set up T1 (1.544 Mbps) leased line between Seoul and Daeduck
Science town. They were using dialup lines or X.25 calls by using PSDN
(DACOMNET). 

	KREONet includes over 100 host machines such as CRAY-2S, IBM, CYBER,
VAX, SUN, etc.  They are using SDN gateway services that provide connection of
CSNET, UUNET, Internet, BITNET, etc. KAIST's IP Address is "sorak.kaist.ac.kr  
137.68.1.1".  In Daeduck science town, they are building FDDI MAN (100 Mbps). 

	They had all kinds of UNIX non-STREAM/STREAM products. They are using
Informix product as their national database solution.

	If I introduce one of their own systems, I might be able to tell one
system called "TICOM". It has 20 CPUs. One board has a couple of MC 68030.
They are using their own system bus (100 MB/s, 64 bits data, 32 bits address,
21 slots), 512 MB Memory, Multi I/O. They are using OSI protocols from OSIAM_C.
It has "pure" OSI stack, FTAM, X.400, X.500, VT, etc. It has STREAMS, TLI,
CLNP, TP4, SNDCP, and TCP/IP.  

	If you know more about OSI activities in Korea, please send an e-mail
to either "uunet!open.osia.re.kr!hwang" (OSIA Secretariat), or 
"osia-all@sorak.kaist.ac.kr"

	By the way, they had SC21 meeting in Seoul in May, 1990. 
That's all, folks !!  I hope this helps. 

	Now, again, I would like to ask you whether we really need to vote
in order to create a new newsgroup either "comp.protocols.migrate.to.iso" or
"comp.protocols.transition.iso", or something like that. Thanks.


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

------------------------------------------------------------------------------
Disclaimer: Those opinions were nothing to do with my employer.

I love OSI !!  I love OSI !!   Don't ask me why !!
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 90 10:06:40 GMT
From:      voder!pyramid!infmx!kwang@ucbvax.Berkeley.EDU  (Kwang Sung)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"[Part 1]

              							[Part 1]
Hi...

	Recently, I've proposed a new newsgroup "comp.protocols.migrate.to.iso".
I've received so many responses. Among those, I've selected some best ones, 
after I've thrown out some bad ones. I couldn't reply to all of you, since it's
so many. However, I might be able to answer thru this network. I think some 
people still don't understand how/where this networking world is going to. 
Absolutely, and positively, the world is moving toward one OSI world !!,
even if ISODE has screwed up OSI world a little bit. 

	Moreover, a lot of people were also interested in the network 
technology in Korea. I would like explain later as much as I know about it. 
I am sure those informations should be much more updated now than a year ago.
Those informations were based on the systems/networks on KAIST, KIST/SERI, 
ETRI, RIST, Korea Defense Department, DACOM, SNU, and several industries
in Korea.

	First of all, I would like to show some responses in order to prove
why we need to create those new newsgroup. Here are some beautiful statements.
I couldn't read them alone !!

-------------------------------------------------------------------------------
>From: uunet!unx.dec.com!jjf (8N8-FRANEY)

>Kwang and Marshall,

>Our postnews is currently broken so sorry for the direct mailing.  The topic
you are discussing is so fresh and hot in my veins that I had to join in.

I recently returned from a symposium in Washington DC that explored the
transisition from TCP/IP to OSI.  The word is transition since migration means
travel to a certain place with intention to return.  There will be no intention
to return to TCP/IP once OSI is established.

Firstly, the people who ran and participated in the symposium can easily be
recognized as leaders in communication technology.
Dr. John McQuillan - consultant and free lance author of about 200 articles
	on data communication, designed and implemented parts of ARPANET.
Leonard Kleinrock - Professor of CS at UCLA, author of intense queing theory 
	textbooks, member of Natinal Academy of Engineering, Guggenheim and
	IEEE fellow, etc...
Dr Vintont Cerf - Vice President of the Corporation for National Research
	Initiatives, Chariman of Internet Activities Board, extensively
	involved with creation and growth of ARPANET.
Dr. Jeffery Case - deisgnier of SNMP and other network protocols, professor
	of CS at U of Tenn.
Larry Green - founder of Protocol Engines, Inc (developting XTP), working on
	networking technologies for the last 25 years.
Bill Johnson - VP of Networks and Communications at DEC.
Don Holtz - Products manager for IBM's OSI, MAP and TCP/IP communciations
	development.
Bob Burnett - vp of Engineering for cisco.
John Hart - VP of Engineering for Vitalink.
etc...

All that follows come from the discussions at this symposium.

The major reason for a slower than expected transition to OSI is the installed
base.  TCP/IP is only a small part of the installed base with 1500 networks.
PC Lans total over 1 million networks, IBM SNA networks control hundreds of
thousands of terminals, DECnet has over 700,00 nodes (hosts and servers) and
DEC has sold 3,000,000 ethernet ports to 61k customers.

The argument that OSI is technically inferior to TCP is a myth.  TCP and TP4
are practically the same (so much the same that people don't see a benifit
of using TP4 over TCP.)  Many of the TCP users will have the industry believe
that the Dod protocols having been used and tested over the past 20-30 years
is better than a set of protocols designed by open consensus.

For an attack on TCP/IP, the experts (including Cerf) pointed out the TCP/IP
was never meant to support a network as large as the internet.  In fact,
at the rate of growth of TCP/IP, it will run out of address space within the
next 5-6 years.  SNMP is an example of hind-sight engineering, as is
sub-networks.  These are features designed into TCP after years of operation.
OSI has the advantage that it was able to use what was learned by TCP/IP people
to design the entire protocol set.

TCP/IP is an old technology.  ALthough it has run on FDDI it wasn't designed
for the high tech media.  OSI also has limitations here but has afforded
a modular stack to allow replacements of layers for progressive evolution.
TCP/IP will not support the upcomming applications such as multimedia as
well as OSI will.  TCP/IP is connectionless, OSI is connection oriented.
Multimedia needs multiple synchronized data circuits.  Datagrams can't be lost
or take variously different routes (TCP/IP).

The major reason why TCP/IP is so prevalent in computer networks today is
not because it is technically superior than anything that was put out before.
But because it was given away as standard equipment on millions of
workstations.  It was part of the BSD UNIX that was sold on SUN boxes.
If not for this fact alone, there probably would not be ANY country wide
interoperable protocol.

OSI is coming of its own.  GOSIP is US govt's requirement list for computer
procurements.  Initially specifying a small subset of OSI, it will evolve
to include the entire specifications.  No company will win a GOSIP bid
without OSI.  And the US Govt is will start using GOSIP to describe contracts
in August 1990.

DEC has commited itself to OSI.  All of its customers computer network nodes
are going to be converted to OSI with the release of DECnet Phase V.  I work
for DEC but not in communications engineering but please don't think this is a
plug.  DEC is the only company to be committed to converting its installed
base of proprieatary protocol to OSI.  DECnet OSI gateways are expected to be 
released in December (don't quote me, I am not speaking for DEC here).
With all DECnet as an OSI network, OSI will be on its way to being more
accepted.

Other companies are committed to OSI.  IBM (good-luck), HP, UNISYS, cisco,
Vitalink, RETIX (has implemented OSI in streams) and others.  With corporate
support, OSI will move faster.  (A point made by McQuillan is that the Ethernet
became a commercial success because research, standards and corporate
communities came together.  For OSI only standards community and more
the corporate community have endorsed it.  The research community is
behind TCP/IP for good reasons).

Corporations are developing transision strategies.
There are many way to transision to OSI from any protocol.  There are OSI
gateways, application gateways, trasnport bridges and RFC 1006.  Some customers
are buying small OSI networks for experimentation only (this approach increases
expertise before the network becomes critical.)

TCP/IP is NOT popular in Europe.  It doesn't surprise me that its not popular
in Korea either.  The big reason here is that the PTTs that implement and
use the networks in Europe are connection oriented.  They wand Virtual
Circuits.  TCP/IP is a datagram network and is not acceptable.
Although there are TCP/IP node across the world, the North
American Continent is where it is most poular.  Europe, conerned about its 1992
common community has looked to OSI as common protocol since its inception.
Europe is poised to take advantage of OSI and will have nothing to do with
TCP/IP.  Europe is composed of many PTTs that use X.25 and other CCITT
protocols, not TCP/IP.

The future of internetworking is not simple.  The experts see TCP/IP
as an integral part of the worlds networking infrastructure.  But most will
agree that the core of the infrastructure must be based on a globally
accepted protocol, no matter how long it takes to implement. This is OSI.
DEC sees OSI as an enterprise wide backbone, with gateways for proietary
and early public networking protocols.
Basically, the world is saying that any and all protocols are going to be uses.
But the protocol itself is about important to most users as whether your car
has efi or carbeurator that is not a significant amount.  Users want
interoperability.  OSI, TCP, PC Lan, SNA, etc.. will be
with us for a long time (10-15-20-30 years).  The one that outlasts
the rest will be the ones that best demonstrate interoperability.
>Think long term.

>Regards,
>John Franey

>These comments are generated from the ideas presented at the symposium
>entitled:
>TCP/IP & OSI, The Interoperability Challenge, Washington, D.C.,
>May 21-23 1990 hosted by the Technology Transfer Institute, Santa Monica, CA.
>These ideas are not mine and I am not speaking for my company in any respect.
--------------------------------------------------------------------------------

>From: att!lzaz!jer

>I support your suggestion.
>joe ritacco

--------------------------------------------------------------------------------

>From: uunet!sunkist.West.Sun.COM!gene.saunders (Gene Saunders Sun SE Irvine CA)

>I'd suggest the newsgroup be named "comp.protocols.tpicp.to.iso".
>More descriptive.

>Gene Saunders   \ Gene.Saunders@West.Sun.COM       \ 72265,23 (CompuServe)
>Systems Engineer \ saunders@sunkist (local)         \ GSAUNDERS (GEnie)
>Sun Microsystems  \ #saunder@ProteonW (from Novell)  \ ..!sunkist!saunders

--------------------------------------------------------------------------------

>From: Amit Parghi <uunet!watmath!watcgl.waterloo.edu!aparghi>
>Organization: Computer Graphics Lab, University of Waterloo

>Don't use the name "comp.protocols.migrate.to.iso"; since there are
>already groups under "comp.protocols.iso", call it
>"comp.protocols.iso.migration".

>You claim the state-of-the-art engineers in Korea and Japan don't much
>care for TCP/IP; instead, they use (I assume) ISO solutions, which I guess
>would mean full ISO stacks implemented efficiently across heterogeneous
>hardware and physical media.  I, for one, would be very interested to hear
>of such developments, especially since serious development of efficient and
>*useful* implementations in Europe and North America still seems to be some
>ways away.  Do tell us more.

--------------------------------------------------------------------------------

>From: Steven Willis <nsc!amdahl!ames!harvard!talcott!wellflt!swillis>

>Consider this a vote for the newsgroup. There's an effort in the IETF and
>ANSI to provide dual IS-IS routing for both IP and OSI. Ross Callon is
>the chairman; you can reach him at callon@bigfut.enet.dec.com.

--------------------------------------------------------------------------------


Hi...

	Recently, I've proposed a new newsgroup "comp.protocols.migrate.to.iso".
I've received so many responses. Among those, I've selected some best ones, 
after I've thrown out some bad ones. I couldn't reply to all of you, since it's
so many. However, I might be able to answer thru this network. I think some 
people still don't understand how/where this networking world is going to. 
Absolutely, and positively, the world is moving toward OSI world !! 

	A lot of people were also interested in the network technology 
in Korea. I would like explain later as much as I know about it. 
I am sure those informations are now much more updated than a year ago.
Those informations were based on the systems/networks on KAIST, ETRI, RIST, 
Korea Defense Department, DACOM, SNU, and several industries in Korea.

	First of all, I would like to show some responses in order to prove
why we need to create those new newsgroup. Here are some beautiful statements.
I couldn't read them alone !!

-------------------------------------------------------------------------------
>From: uunet!unx.dec.com!jjf (8N8-FRANEY)

>Kwang and Marshall,

>Our postnews is currently broken so sorry for the direct mailing.  The topic
>you are discussing is so fresh and hot in my veins that I had to join in.

>I recently returned from a symposium in Washington DC that explored the
>transisition from TCP/IP to OSI.  The word is transition since migration means
>travel to a certain place with intention to return.  There will be no intention
>to return to TCP/IP once OSI is established.

>Firstly, the people who ran and participated in the symposium can easily be
>recognized as leaders in communication technology.
>Dr. John McQuillan - consultant and free lance author of about 200 articles
>	on data communication, designed and implemented parts of ARPANET.
>Leonard Kleinrock - Professor of CS at UCLA, author of intense queing theory 
>	textbooks, member of Natinal Academy of Engineering, Guggenheim and
>	IEEE fellow, etc...
>Dr Vintont Cerf - Vice President of the Corporation for National Research
>	Initiatives, Chariman of Internet Activities Board, extensively
>	involved with creation and growth of ARPANET.
>Dr. Jeffery Case - deisgnier of SNMP and other network protocols, professor
>	of CS at U of Tenn.
>Larry Green - founder of Protocol Engines, Inc (developting XTP), working on
>	networking technologies for the last 25 years.
>Bill Johnson - VP of Networks and Communications at DEC.
>Don Holtz - Products manager for IBM's OSI, MAP and TCP/IP communciations
>	development.
>Bob Burnett - vp of Engineering for cisco.
>John Hart - VP of Engineering for Vitalink.
>etc...

>All that follows come from the discussions at this symposium.

>The major reason for a slower than expected transition to OSI is the installed
>base.  TCP/IP is only a small part of the installed base with 1500 networks.
>PC Lans total over 1 million networks, IBM SNA networks control hundreds of
>thousands of terminals, DECnet has over 700,00 nodes (hosts and servers) and
>DEC has sold 3,000,000 ethernet ports to 61k customers.

>The argument that OSI is technically inferior to TCP is a myth.  TCP and TP4
>are practically the same (so much the same that people don't see a benifit
>of using TP4 over TCP.)  Many of the TCP users will have the industry believe
>that the Dod protocols having been used and tested over the past 20-30 years
>is better than a set of protocols designed by open consensus.

>For an attack on TCP/IP, the experts (including Cerf) pointed out the TCP/IP
>was never meant to support a network as large as the internet.  In fact,
>at the rate of growth of TCP/IP, it will run out of address space within the
>next 5-6 years.  SNMP is an example of hind-sight engineering, as is
>sub-networks.  These are features designed into TCP after years of operation.
>OSI has the advantage that it was able to use what was learned by TCP/IP people
>to design the entire protocol set.

>TCP/IP is an old technology.  ALthough it has run on FDDI it wasn't designed
>for the high tech media.  OSI also has limitations here but has afforded
>a modular stack to allow replacements of layers for progressive evolution.
>TCP/IP will not support the upcomming applications such as multimedia as
>well as OSI will.  TCP/IP is connectionless, OSI is connection oriented.
>Multimedia needs multiple synchronized data circuits.  Datagrams can't be lost
>or take variously different routes (TCP/IP).

>The major reason why TCP/IP is so prevalent in computer networks today is
>not because it is technically superior than anything that was put out before.
>But because it was given away as standard equipment on millions of
>workstations.  It was part of the BSD UNIX that was sold on SUN boxes.
>If not for this fact alone, there probably would not be ANY country wide
>interoperable protocol.

>OSI is coming of its own.  GOSIP is US govt's requirement list for computer
>procurements.  Initially specifying a small subset of OSI, it will evolve
>to include the entire specifications.  No company will win a GOSIP bid
>without OSI.  And the US Govt is will start using GOSIP to describe contracts
>in August 1990.

>DEC has commited itself to OSI.  All of its customers computer network nodes
>are going to be converted to OSI with the release of DECnet Phase V.  I work
>for DEC but not in communications engineering but please don't think this is a
>plug.  DEC is the only company to be committed to converting its installed
>base of proprieatary protocol to OSI.  DECnet OSI gateways are expected to be 
>released in December (don't quote me, I am not speaking for DEC here).
>With all DECnet as an OSI network, OSI will be on its way to being more
>accepted.

>Other companies are committed to OSI.  IBM (good-luck), HP, UNISYS, cisco,
>Vitalink, RETIX (has implemented OSI in streams) and others.  With corporate
>support, OSI will move faster.  (A point made by McQuillan is that the Ethernet
>became a commercial success because research, standards and corporate
>communities came together.  For OSI only standards community and more
>the corporate community have endorsed it.  The research community is
>behind TCP/IP for good reasons).

>Corporations are developing transision strategies.
>There are many way to transision to OSI from any protocol.  There are OSI
>gateways, application gateways, trasnport bridges and RFC 1006.  Some customers
>are buying small OSI networks for experimentation only (this approach increases
>expertise before the network becomes critical.)

>TCP/IP is NOT popular in Europe.  It doesn't surprise me that its not popular
>in Korea either.  The big reason here is that the PTTs that implement and
>use the networks in Europe are connection oriented.  They wand Virtual
>Circuits.  TCP/IP is a datagram network and is not acceptable.
>Although there are TCP/IP node across the world, the North
>American Continent is where it is most poular.  Europe, conerned about its 1992
>common community has looked to OSI as common protocol since its inception.
>Europe is poised to take advantage of OSI and will have nothing to do with
>TCP/IP.  Europe is composed of many PTTs that use X.25 and other CCITT
>protocols, not TCP/IP.

>The future of internetworking is not simple.  The experts see TCP/IP
>as an integral part of the worlds networking infrastructure.  But most will
>agree that the core of the infrastructure must be based on a globally
>accepted protocol, no matter how long it takes to implement. This is OSI.
>DEC sees OSI as an enterprise wide backbone, with gateways for proietary
>and early public networking protocols.
>Basically, the world is saying that any and all protocols are going to be uses.
>But the protocol itself is about important to most users as whether your car
>has efi or carbeurator that is not a significant amount.  Users want
>interoperability.  OSI, TCP, PC Lan, SNA, etc.. will be
>with us for a long time (10-15-20-30 years).  The one that outlasts
>the rest will be the ones that best demonstrate interoperability.
>Think long term.

>Regards,
>John Franey

>These comments are generated from the ideas presented at the symposium
>entitled:
>TCP/IP & OSI, The Interoperability Challenge, Washington, D.C.,
>May 21-23 1990 hosted by the Technology Transfer Institute, Santa Monica, CA.
>These ideas are not mine and I am not speaking for my company in any respect.
--------------------------------------------------------------------------------

>From: att!lzaz!jer

>I support your suggestion.
>joe ritacco

--------------------------------------------------------------------------------

>From: uunet!sunkist.West.Sun.COM!gene.saunders (Gene Saunders Sun SE Irvine CA)

>I'd suggest the newsgroup be named "comp.protocols.tpicp.to.iso".
>More descriptive.

>Gene Saunders   \ Gene.Saunders@West.Sun.COM       \ 72265,23 (CompuServe)
>Systems Engineer \ saunders@sunkist (local)         \ GSAUNDERS (GEnie)
>Sun Microsystems  \ #saunder@ProteonW (from Novell)  \ ..!sunkist!saunders

--------------------------------------------------------------------------------

>From: Amit Parghi <uunet!watmath!watcgl.waterloo.edu!aparghi>
>Organization: Computer Graphics Lab, University of Waterloo

>Don't use the name "comp.protocols.migrate.to.iso"; since there are
>already groups under "comp.protocols.iso", call it
>"comp.protocols.iso.migration".

>You claim the state-of-the-art engineers in Korea and Japan don't much
>care for TCP/IP; instead, they use (I assume) ISO solutions, which I guess
>would mean full ISO stacks implemented efficiently across heterogeneous
>hardware and physical media.  I, for one, would be very interested to hear
>of such developments, especially since serious development of efficient and
>*useful* implementations in Europe and North America still seems to be some
>ways away.  Do tell us more.

--------------------------------------------------------------------------------

>From: grieve@cos.com (David Grieve)
>Organization: Corporation for Open Systems, McLean, VA

>I would call it "comp.tcp.osi.transition"

>Migration means you go away and then come back.  Transition means
>you go away for good.

>grieve@cos.com OR  {uunet,  decuac, sun!sundc, hadron, hqda-ai}!cos!grieve
>DISCLAIMER:  Opinions expressed are not necessarily those of the
>Corporation for Open Systems, its members, or any standards body. 

--------------------------------------------------------------------------------

>From: nsc!asylum.sf.ca.us!karl (Karl Auerbach)

>	I propose a comp.protocols.migrates.back.to.tcp group to
>handle the situation when folks find out that ASN.1 eats all the cpu
>cycles and that the word "open" in OSI is something akin to the "open"
>invitation that a snake makes to a mouse when the snake opens its
>mouth.

I think this one was one of the junk mails. But it's funny !!

-------------------------------------------------------------------------------
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jun 90 17:08:30 PDT
From:      infmx!moose!kwang@uunet.UU.NET (Kwang Sung)
To:        tcp-ip@nic.ddn.mil

Hi...

	Recently, I've proposed a new newsgroup "comp.protocols.migrate.to.iso".
I've received so many responses. Among those, I've selected some best ones, 
after I've thrown out some bad ones. I couldn't reply to all of you, since it's
so many. However, I might be able to answer thru this network. I think some 
people still don't understand how/where this networking world is going to. 
Absolutely, and positively, the world is moving toward one OSI world !!,
even if ISODE has screwed up OSI world a little bit. 

	Moreover, a lot of people were also interested in the network 
technology in Korea. I would like explain later as much as I know about it. 
I am sure those informations should be much more updated now than a year ago.
Those informations were based on the systems/networks on KAIST, KIST/SERI, 
ETRI, RIST, Korea Defense Department, DACOM, SNU, and several industries
in Korea.

	First of all, I would like to show some responses in order to prove
why we need to create those new newsgroup. Here are some beautiful statements.
I couldn't read them alone !!

-------------------------------------------------------------------------------
>From: uunet!unx.dec.com!jjf (8N8-FRANEY)

>Kwang and Marshall,

>Our postnews is currently broken so sorry for the direct mailing.  The topic
>you are discussing is so fresh and hot in my veins that I had to join in.

>I recently returned from a symposium in Washington DC that explored the
>transisition from TCP/IP to OSI.  The word is transition since migration means
>travel to a certain place with intention to return.  There will be no intention
>to return to TCP/IP once OSI is established.

>Firstly, the people who ran and participated in the symposium can easily be
>recognized as leaders in communication technology.
>Dr. John McQuillan - consultant and free lance author of about 200 articles
>	on data communication, designed and implemented parts of ARPANET.
>Leonard Kleinrock - Professor of CS at UCLA, author of intense queing theory 
>	textbooks, member of Natinal Academy of Engineering, Guggenheim and
>	IEEE fellow, etc...
>Dr Vintont Cerf - Vice President of the Corporation for National Research
>	Initiatives, Chariman of Internet Activities Board, extensively
>	involved with creation and growth of ARPANET.
>Dr. Jeffery Case - deisgnier of SNMP and other network protocols, professor
>	of CS at U of Tenn.
>Larry Green - founder of Protocol Engines, Inc (developting XTP), working on
>	networking technologies for the last 25 years.
>Bill Johnson - VP of Networks and Communications at DEC.
>Don Holtz - Products manager for IBM's OSI, MAP and TCP/IP communciations
>	development.
>Bob Burnett - vp of Engineering for cisco.
>John Hart - VP of Engineering for Vitalink.
>etc...

>All that follows come from the discussions at this symposium.

>The major reason for a slower than expected transition to OSI is the installed
>base.  TCP/IP is only a small part of the installed base with 1500 networks.
>PC Lans total over 1 million networks, IBM SNA networks control hundreds of
>thousands of terminals, DECnet has over 700,00 nodes (hosts and servers) and
>DEC has sold 3,000,000 ethernet ports to 61k customers.

>The argument that OSI is technically inferior to TCP is a myth.  TCP and TP4
>are practically the same (so much the same that people don't see a benifit
>of using TP4 over TCP.)  Many of the TCP users will have the industry believe
>that the Dod protocols having been used and tested over the past 20-30 years
>is better than a set of protocols designed by open consensus.

>For an attack on TCP/IP, the experts (including Cerf) pointed out the TCP/IP
>was never meant to support a network as large as the internet.  In fact,
>at the rate of growth of TCP/IP, it will run out of address space within the
>next 5-6 years.  SNMP is an example of hind-sight engineering, as is
>sub-networks.  These are features designed into TCP after years of operation.
>OSI has the advantage that it was able to use what was learned by TCP/IP people
>to design the entire protocol set.

>TCP/IP is an old technology.  ALthough it has run on FDDI it wasn't designed
>for the high tech media.  OSI also has limitations here but has afforded
>a modular stack to allow replacements of layers for progressive evolution.
>TCP/IP will not support the upcomming applications such as multimedia as
>well as OSI will.  TCP/IP is connectionless, OSI is connection oriented.
>Multimedia needs multiple synchronized data circuits.  Datagrams can't be lost
>or take variously different routes (TCP/IP).

>The major reason why TCP/IP is so prevalent in computer networks today is
>not because it is technically superior than anything that was put out before.
>But because it was given away as standard equipment on millions of
>workstations.  It was part of the BSD UNIX that was sold on SUN boxes.
>If not for this fact alone, there probably would not be ANY country wide
>interoperable protocol.

>OSI is coming of its own.  GOSIP is US govt's requirement list for computer
>procurements.  Initially specifying a small subset of OSI, it will evolve
>to include the entire specifications.  No company will win a GOSIP bid
>without OSI.  And the US Govt is will start using GOSIP to describe contracts
>in August 1990.

>DEC has commited itself to OSI.  All of its customers computer network nodes
>are going to be converted to OSI with the release of DECnet Phase V.  I work
>for DEC but not in communications engineering but please don't think this is a
>plug.  DEC is the only company to be committed to converting its installed
>base of proprieatary protocol to OSI.  DECnet OSI gateways are expected to be 
>released in December (don't quote me, I am not speaking for DEC here).
>With all DECnet as an OSI network, OSI will be on its way to being more
>accepted.

>Other companies are committed to OSI.  IBM (good-luck), HP, UNISYS, cisco,
>Vitalink, RETIX (has implemented OSI in streams) and others.  With corporate
>support, OSI will move faster.  (A point made by McQuillan is that the Ethernet
>became a commercial success because research, standards and corporate
>communities came together.  For OSI only standards community and more
>the corporate community have endorsed it.  The research community is
>behind TCP/IP for good reasons).

>Corporations are developing transision strategies.
>There are many way to transision to OSI from any protocol.  There are OSI
>gateways, application gateways, trasnport bridges and RFC 1006.  Some customers
>are buying small OSI networks for experimentation only (this approach increases
>expertise before the network becomes critical.)

>TCP/IP is NOT popular in Europe.  It doesn't surprise me that its not popular
>in Korea either.  The big reason here is that the PTTs that implement and
>use the networks in Europe are connection oriented.  They wand Virtual
>Circuits.  TCP/IP is a datagram network and is not acceptable.
>Although there are TCP/IP node across the world, the North
>American Continent is where it is most poular.  Europe, conerned about its 1992
>common community has looked to OSI as common protocol since its inception.
>Europe is poised to take advantage of OSI and will have nothing to do with
>TCP/IP.  Europe is composed of many PTTs that use X.25 and other CCITT
>protocols, not TCP/IP.

>The future of internetworking is not simple.  The experts see TCP/IP
>as an integral part of the worlds networking infrastructure.  But most will
>agree that the core of the infrastructure must be based on a globally
>accepted protocol, no matter how long it takes to implement. This is OSI.
>DEC sees OSI as an enterprise wide backbone, with gateways for proietary
>and early public networking protocols.
>Basically, the world is saying that any and all protocols are going to be uses.
>But the protocol itself is about important to most users as whether your car
>has efi or carbeurator that is not a significant amount.  Users want
>interoperability.  OSI, TCP, PC Lan, SNA, etc.. will be
>with us for a long time (10-15-20-30 years).  The one that outlasts
>the rest will be the ones that best demonstrate interoperability.
>Think long term.

>Regards,
>John Franey

>These comments are generated from the ideas presented at the symposium
>entitled:
>TCP/IP & OSI, The Interoperability Challenge, Washington, D.C.,
>May 21-23 1990 hosted by the Technology Transfer Institute, Santa Monica, CA.
>These ideas are not mine and I am not speaking for my company in any respect.

--------------------------------------------------------------------------------

>From: att!lzaz!jer

>I support your suggestion.
>joe ritacco

--------------------------------------------------------------------------------

>From: uunet!sunkist.West.Sun.COM!gene.saunders (Gene Saunders Sun SE Irvine CA)

>I'd suggest the newsgroup be named "comp.protocols.tpicp.to.iso".
>More descriptive.

>Gene Saunders   \ Gene.Saunders@West.Sun.COM       \ 72265,23 (CompuServe)
>Systems Engineer \ saunders@sunkist (local)         \ GSAUNDERS (GEnie)
>Sun Microsystems  \ #saunder@ProteonW (from Novell)  \ ..!sunkist!saunders

--------------------------------------------------------------------------------

>From: Amit Parghi <uunet!watmath!watcgl.waterloo.edu!aparghi>
>Organization: Computer Graphics Lab, University of Waterloo

>Don't use the name "comp.protocols.migrate.to.iso"; since there are
>already groups under "comp.protocols.iso", call it
>"comp.protocols.iso.migration".

>You claim the state-of-the-art engineers in Korea and Japan don't much
>care for TCP/IP; instead, they use (I assume) ISO solutions, which I guess
>would mean full ISO stacks implemented efficiently across heterogeneous
>hardware and physical media.  I, for one, would be very interested to hear
>of such developments, especially since serious development of efficient and
>*useful* implementations in Europe and North America still seems to be some
>ways away.  Do tell us more.

--------------------------------------------------------------------------------

>From: grieve@cos.com (David Grieve)
>Organization: Corporation for Open Systems, McLean, VA

>I would call it "comp.tcp.osi.transition"

>Migration means you go away and then come back.  Transition means
>you go away for good.

>grieve@cos.com OR  {uunet,  decuac, sun!sundc, hadron, hqda-ai}!cos!grieve
>DISCLAIMER:  Opinions expressed are not necessarily those of the
>Corporation for Open Systems, its members, or any standards body. 

--------------------------------------------------------------------------------

>From: nsc!asylum.sf.ca.us!karl (Karl Auerbach)

>	I propose a comp.protocols.migrates.back.to.tcp group to
>handle the situation when folks find out that ASN.1 eats all the cpu
>cycles and that the word "open" in OSI is something akin to the "open"
>invitation that a snake makes to a mouse when the snake opens its
>mouth.

I think this one was one of the junk mails. But it's funny !!

-------------------------------------------------------------------------------


	Next, I would like to introduce some networking activities in Korea.
Obviously, these informations must be updated now. However, this is what I
know about. One of their networks, KREONet is the National Computer Network
to provide networking services for the whole Korea R&D community. It is 
developed, managed and operated by KIST/SERI. Initially, they used TCP/IP, X.25,
SNA as interim protocols. However, they were migrated to OSI thru ISODE-POSIX,
Dual Protocol Hosts, TS-Bridge, and Application Gateways.

	They are interconnecting 8 cities as 9.6 Kbps and 56 Kbps leased line.
Especially, they set up T1 (1.544 Mbps) leased line between Seoul and Daeduck
Science town. They were using dialup lines or X.25 calls by using PSDN
(DACOMNET). 

	KREONet includes over 100 host machines such as CRAY-2S, IBM, CYBER,
VAX, SUN, etc.  They are using SDN gateway services that provide connection of
CSNET, UUNET, Internet, BITNET, etc. KAIST's IP Address is "sorak.kaist.ac.kr  
137.68.1.1".  In Daeduck science town, they are building FDDI MAN (100 Mbps). 

	They had all kinds of UNIX non-STREAM/STREAM products. They are using
Informix product as their national database solution.

	If I introduce one of their own systems, I might be able to tell one
system called "TICOM". It has 20 CPUs. One board has a couple of MC 68030.
They are using their own system bus (100 MB/s, 64 bits data, 32 bits address,
21 slots), 512 MB Memory, Multi I/O. They are using OSI protocols from OSIAM_C.
It has "pure" OSI stack, FTAM, X.400, X.500, VT, etc. It has STREAMS, TLI,
CLNP, TP4, SNDCP, and TCP/IP.  

	If you know more about OSI activities in Korea, please send an e-mail
to either "uunet!open.osia.re.kr!hwang" (OSIA Secretariat), or 
"osia-all@sorak.kaist.ac.kr"

	By the way, they had SC21 meeting in Seoul in May, 1990. 
That's all, folks !!  I hope this helps. 

	Now, again, I would like to ask you whether we really need to vote
in order to create a new newsgroup either "comp.protocols.migrate.to.iso" or
"comp.protocols.transition.iso", or something like that. Thanks.


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

------------------------------------------------------------------------------
Disclaimer: Those opinions were nothing to do with my employer.

I love OSI !!  I love OSI !!   Don't ask me why !!
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 90 10:11:24 GMT
From:      voder!pyramid!infmx!kwang@ucbvax.Berkeley.EDU  (Kwang Sung)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"[Part 2]
-------------------------------------------------------------------------------

								[Part 2]


	Next, I would like to introduce some networking activities in Korea.
Obviously, these informations must be updated now. However, this is what I
know about. One of their networks, KREONet is the National Computer Network
to provide networking services for the whole Korea R&D community. It is 
developed, managed and operated by KIST/SERI. Initially, they used TCP/IP, X.25,
SNA as interim protocols. However, they were migrated to OSI thru ISODE-POSIX,
Dual Protocol Hosts, TS-Bridge, and Application Gateways.

	They are interconnecting 8 cities as 9.6 Kbps and 56 Kbps leased line.
Especially, they set up T1 (1.544 Mbps) leased line between Seoul and Daeduck
Science town. They were using dialup lines or X.25 calls by using PSDN
(DACOMNET). 

	KREONet includes over 100 host machines such as CRAY-2S, IBM, CYBER,
VAX, SUN, etc.  They are using SDN gateway services that provide connection of
CSNET, UUNET, Internet, BITNET, etc. KAIST's IP Address is "sorak.kaist.ac.kr  
137.68.1.1".  In Daeduck science town, they are building FDDI MAN (100 Mbps). 

	They had all kinds of UNIX non-STREAM/STREAM products. They are using
Informix product as their national database solution.

	If I introduce one of their own systems, I might be able to tell one
system called "TICOM". It has 20 CPUs. One board has a couple of MC 68030.
They are using their own system bus (100 MB/s, 64 bits data, 32 bits address,
21 slots), 512 MB Memory, Multi I/O. They are using OSI protocols from OSIAM_C.
It has "pure" OSI stack, FTAM, X.400, X.500, VT, etc. It has STREAMS, TLI,
CLNP, TP4, SNDCP, and TCP/IP.  

	If you know more about OSI activities in Korea, please send an e-mail
to either "uunet!open.osia.re.kr!hwang" (OSIA Secretariat), or 
"osia-all@sorak.kaist.ac.kr"

	By the way, they had SC21 meeting in Seoul in May, 1990. 
That's all, folks !!  I hope this helps. 

	Now, again, I would like to ask you whether we really need to vote
in order to create a new newsgroup either "comp.protocols.migrate.to.iso" or
"comp.protocols.transition.iso", or something like that. Thanks.


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

------------------------------------------------------------------------------
Disclaimer: Those opinions were nothing to do with my employer.

I love OSI !!  I love OSI !!   Don't ask me why !!
-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jun 90 20:44:41 HST
From:      Torben Nielsen <torben@foralie.ics.Hawaii.Edu>
To:        infmx!moose!kwang@uunet.uu.net, tcp-ip@NIC.DDN.MIL
Subject:   Quote
From Kwang Sung's diatribe....

>	Recently, I've proposed a new newsgroup "comp.protocols.migrate.to.iso".
>I've received so many responses. Among those, I've selected some best ones, 
>after I've thrown out some bad ones. 

Wouldn't do to let us read all of that garbage. ``No" votes truly are no good;
they should be discarded so we can have a fair poll here.....

Actually, I'm delighted you threw the following quote in there. Apparently
from someone inside DEC:

>>The major reason for a slower than expected transition to OSI is the installed
>>base.  TCP/IP is only a small part of the installed base with 1500 networks.
>>PC Lans total over 1 million networks, IBM SNA networks control hundreds of
>>thousands of terminals, DECnet has over 700,00 nodes (hosts and servers) and
>>DEC has sold 3,000,000 ethernet ports to 61k customers.

Can you say ``apples"? Now try ``oranges" and maybe ``pineapples".... Is this
the official DEC line explaining why the transition is going so slowly?

					Torben
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Sat, 9 Jun 90 21:01:00 HST
From:      Torben Nielsen <torben@foralie.ics.Hawaii.Edu>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Clarification......
In response to some of Mr. Sung's comments, I recently made the following
statement:

>Actually, the Australian network (AARN) is about the
>most impressive accomplishment in IP network construction I can think of.
>They connected just about all the universities in the country in one fell
>swoop; the whole thing was planned and executed very nicely.

Several people have pointed out that I'm not being nice to the NSFNet by 
saying such things :-) Well, I had no intention of saying that the
construction of NSFNet was somehow inferior.

However, irrespective of it's size, the AARN is a true national academic
network and they have more than just a few nodes on it. Moreover, it was
established with what appeared to be a minimum of fuss and bother. The primary
protocol is IP. Not because it's viewed as inherently better, but because
it's available and works *now*.

When we have a true national network that reaches all universities in the
country, I'll revise my statement. Waiting for the NREN :-)

As an aside, it's truly interesting to watch how national networks are
built/develop/grow. So far, I can see at least three major types of
scenarios.... No doubt ther're a lot more.

						Torben
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Sat, 09 Jun 90 17:55:20 -0400
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        karl@asylum.sf.ca.us
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Efficiency (or lack thereof) of ASN.1. Was: Re: What is the IAB?

 > In my SNMP code, my profilers indicate that an
 > overly large portion of the of cycles are spent in the ASN.1
 > encoder/decoder.  Maybe my code is inefficient -- although I doubt it.

Refresh my memory but doesn't your code base derive from an effort
to span the perceived market for both CMOT and SNMP?  Could this
be a factor?  I've seen some very tight code by commercial implementors
of SNMP.

While you make the comparison of ASN.1 vs "SNMP" within your
code base, do remember that the tradeoff were made between

	doing real work code (such as routing)
		vs
	network management code

inside the network entity.  That was the foundation of all
critical engineering decision tradeoffs.

Your statement above leads me to believe that you aren't seeing the forest
for the trees.

Marty
-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 90 16:00:50 GMT
From:      brian@ucsd.edu  (Brian Kantor)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
A few of us are sorta planning to hold a wake for the Arpanet at Usenix
next week.  We just haven't found the proper bar yet.
	- Brian
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 90 18:28:09 GMT
From:      snorkelwacker!spdcc!ima!minya!jc@tut.cis.ohio-state.edu  (John Chambers)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <1990Apr21.222928.24498@Solbourne.COM>, imp@dancer.Solbourne.COM (Warner Losh) writes:
> 
> In article <6703@blake.acs.washington.edu>
> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
> >... There are lessons to be learned, starting with the
> >abolishment of /etc/passwd and user access to the encryption
> >algorithm.
> 
> Sorry.  There are too may passwd files out there to do this.  Shadow
> files might help, but then again they might not.  

Logistics isn't the only problem; an unreadable password file can
decrease security in some situations.

I've written several packages that, when talking across a comm line
that needs extra security, will occasionally say, in effect, "I'm
not sure you are who you claim to be; please type your password: "
On a system with an unreadable encrypted password, the application
(which isn't running as super-user) is denied read access and can't
check the password for validity.  So when the software is ported to
such systems, this checking normally just gets #ifdeffed out (so we
can get the application delivered on time ;-).

Now it's true that there are other solutions possible.  But until
they are available, what do you suggest I and other developers
without access to the kernel do?  Remember that we're all trying
to get products out the door, and most of us aren't security experts.

What usually happens, in fact, is that such applications have their
own encrypted-password file, but since it was set up by non-experts
in security, it is even less secure than /etc/passwd ever was.

-- 
Uucp: ...!{harvard.edu,ima.com,mit-eddie.edu}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: It's never to late to have a happy childhood.
-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jun 90 01:43:11 PDT
From:      richardt@Legato.COM
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
Hmmm... I would vote for the creation of this newsgroup.  
*Because* I believe that the OSI 'migration' is doomed to go the way of the
Edsel.  While this does (like all of the other "we'll have OSI running
Real Soon Now" propaganda) run the risk that someone might actually take
the migration seriously, it also will provide a public forum in which to
demonstrate what is (and is NOT) actually happening.  Think of it as a 
'give 'em enough rope' strategy.  And as for a name, comp.protocols.migration,
please.  This 'comp.migration.to.iso' stuff is painful to read, as well as
completely breaking the naming system.

RichardT
This is just a test...
-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 90 20:38:17 GMT
From:      vsi1!tim@ames.arc.nasa.gov  (Tim Richardson)
To:        tcp-ip@nic.ddn.mil
Subject:   TCPIP Driver -- VXWORKS
We're looking for a VXWORKS driver which supports tcp-ip protocols.  Does
anyone know of such a product?  We've been attempting to get WindRiver
to write one and so far they've been more than non-responsive.  We
are willing to purchase it, we're not looking for a freebe (but wouldn't
turn one down, of course).

I don't usually read these newsgroups, so please reply directly to the
address below.

Thanks,
-- 

Tim Richardson
VP Engineering
(415) 498-3200
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      9 Jun 90 21:01:23 GMT
From:      ecsgate!uncmed!durham!robinson@mcnc.org  (Gerard A. Robinson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Duplicate Internet address on same network
In article <4988@plains.UUCP> lodin@plains.UUCP (Steve Lodin) writes:
>
>I have two machines on my network using the same Internet address, and without
>network analysis tools, I am having trouble identifying the culprit.  Could
>somebody please tell me which manufacturer uses the Ethernet address
>AA:0:4:X:X:X.

That's the format of a DEC ethernet address after DECnet is done with it.
The X:X:X is typically a 0 followed by the 16-bit combination of the area
and node number 6bits of area and 10bits of node, little-endian.  DECnet
overrides the default ethernet address on the board with this result.  An
example for host 42.8 is AA:0:4:0:8:A8.

Gerard Robinson
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jun 90 06:18:58 -0400
From:      Scott Brim <swb@dainichi.tn.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
So are we going to follow through with the idea of running Net 10 in the
Boston Computer Museum (hooked up to the Internet) or not??
-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 90 02:33:11 GMT
From:      munnari.oz.au!ditmela!george@uunet.uu.net  (George Michaelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Efficiency (or lack thereof) of ASN.1. Was: Re: What is the IAB?

If an ASN.1 en/de coder is built to a specific and known subset of
ASN.1 which is what at least one message about SNMP implied, is it
any wonder it runs faster than a en/de coder written to try and handle
an *arbitrary* ASN.1 description? 

The same goes for the BER surely, if you know in advance what specific
sequences to expect you can afford to write an optimal package to read
and write those sequences, nasty hacks like pre-defined fixed buffers
that you write 2-3 bytes into and chuck onto the net without actually
"walking" all the ASN.1 involved.

ISODE is more than just SNMP support. If somebody writes fast generic
ASN.1 nobody will complain. meantime, its better than nothing. 

How does ISODE compare to Huitema's ASN.1 stuff for speed? ditto the
EAN code? Retix? is there are basis for benchmarking ASN.1 and BER
code?

George
-- 
ACSnet: ggm@brolga.cc.uq.oz                    Phone: +61 7 377 4079
Postal: George Michaelson, Prentice Computer Centre
          Queensland University, St Lucia, QLD 4067 Australia
-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      Sun, 10 Jun 90 09:43:15 PDT
From:      postel@venera.isi.edu
To:        lodin@koess.gm.hac.com, ndsuvm1!plains!lodin@cunyvm.cuny.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Duplicate Internet address on same network

Steve Lodin:

AA:0:4:X:X:X = DEC  - logical addresses for systems running decnet

See RFC-1060 page 40.

--jon.
-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 90 13:31:35 GMT
From:      scamp!jrr@mcnc.org  (Joe Ragland)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
In article <9006101018.AA04161@chumley.TN.Cornell.EDU> swb@DAINICHI.TN.CORNELL.EDU (Scott Brim) writes:
>So are we going to follow through with the idea of running Net 10 in the
>Boston Computer Museum (hooked up to the Internet) or not??

Gee Scott, that's sorta close to the water's edge.  A few ICMP redirects
and ole net 10 might just slide into Boston Harbor (that's "haba" to the
natives).

Actually, sounds like a great idea to me.

--joe
-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 90 18:07:24 GMT
From:      cs.utexas.edu!mailrus!news-server.csri.toronto.edu!utgpu!dennis@tut.cis.ohio-state.edu  (Dennis Ferguson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Quote
Torben Nielsen writes:
>From Kwang Sung's diatribe....
...
>Actually, I'm delighted you threw the following quote in there. Apparently
>from someone inside DEC:
>
>>The major reason for a slower than expected transition to OSI is the installed
>>base.  TCP/IP is only a small part of the installed base with 1500 networks.
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>PC Lans total over 1 million networks, IBM SNA networks control hundreds of
>>thousands of terminals, DECnet has over 700,00 nodes (hosts and servers) and
>>DEC has sold 3,000,000 ethernet ports to 61k customers.

I quite enjoyed that note as well, not so much because I have particularly
strong feelings on the subject, but rather because if you rearrange the
paragraphs you get a little of the schizophrenia I often hear from vendors
and others with greater interest in the topic.  For example, compare the
above to the following, which appeared about 15 sentences later.

> The major reason why TCP/IP is so prevalent in computer networks today is
> not because it is technically superior than anything that was put out before.
> But because it was given away as standard equipment on millions of
> workstations.  It was part of the BSD UNIX that was sold on SUN boxes.
> If not for this fact alone, there probably would not be ANY country wide
> interoperable protocol.

Or how about this

> The argument that OSI is technically inferior to TCP is a myth.  TCP and TP4
> are practically the same (so much the same that people don't see a benifit
> of using TP4 over TCP.)

and this

> TCP/IP will not support the upcomming applications such as multimedia as
> well as OSI will.  TCP/IP is connectionless, OSI is connection oriented.
> Multimedia needs multiple synchronized data circuits.  Datagrams can't be lost
> or take variously different routes (TCP/IP).

I think what is really needed is an ISO committee to standardize criticisms
of DoD IP for the advancement of OSI networking.  This way people could just
cite ISO 8992 instead of having to spend time rewriting all the same old
stuff, could be sure they were all saying the same bad things about TCP/IP,
and wouldn't get contradictory criticisms mixed up in the same eight
paragraphs.  Perfect.

Dennis Ferguson
-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      10 Jun 90 18:35:53 GMT
From:      netnews.upenn.edu!pcpond.cis.upenn.edu!farber@rutgers.edu  (David J. Farber)
To:        tcp-ip@nic.ddn.mil
Subject:   Please not yet again
While I know it will not help to stop the religious wars, please take a peek at
the report produced by the Board on telecommunications and Computer
Applications of the National Research Council dated 1985 (work started
in 1983) titled:

Transport Protocols for the DOD Data Networks -- report to the DoD and the NBS

it compared TP/4 and TCP.

Dave



David Farber; Prof. of CIS and EE, U of Penn, Philadelphia, PA 19104-6389 Tele:
215-898-9508(off); 215-274-8292 (home); FAX: 215-274-8293;  Cellular:  302-740-
1198 "The fundamental principle of science, the definition almost, is this: the
sole test of the validity of any idea is experiment." -- R. P. Feynman
-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 09:23:45 PDT
From:      mja@chico.simpact.com (Mike Anello)
To:        tcp-ip@nic.ddn.mil
Subject:   Remove from list
Please remove tcpip@chico.simpact.com from tcp-ip list. Thank you.
-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 10:35:00 PDT
From:      postel@venera.isi.edu
To:        tcp-ip@nic.ddn.mil
Subject:   National Research Council report on Transport Protocols
Dave:

That is RFC-942.

--jon.

----- Begin Included Message -----
Date: 10 Jun 90 18:35:53 GMT
From: netnews.upenn.edu!pcpond.cis.upenn.edu!farber@rutgers.edu  (David J. Farber)
Subject: Please not yet again
To: tcp-ip@nic.ddn.mil

While I know it will not help to stop the religious wars, please take a peek at
the report produced by the Board on telecommunications and Computer
Applications of the National Research Council dated 1985 (work started
in 1983) titled:

Transport Protocols for the DOD Data Networks -- report to the DoD and the NBS

it compared TP/4 and TCP.

Dave

David Farber; Prof. of CIS and EE, U of Penn, Philadelphia, PA 19104-6389 Tele:
215-898-9508(off); 215-274-8292 (home); FAX: 215-274-8293;  Cellular:  302-740-
1198 "The fundamental principle of science, the definition almost, is this: the
sole test of the validity of any idea is experiment." -- R. P. Feynman
----- End Included Message -----

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 08:26:46 EDT
From:      louie@sayshell.umd.edu (Louis A. Mamakos)
To:        tcp-ip@nic.ddn.mil
Cc:        
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
Its because of things like this that I wish the TCP-IP mailing list
would not be gatewayed to the USENET newsgroup comp.protcols.tcpip.
The S/N ratio has decreased steadily since it was gatewayed to the
newsgroup.

First of all, for the USENET folks, you should know that if you want
to create a new newsgroup, you should not hold discussion in
comp.protocols.tcpip, but in news.groups or something.  Post a pointer
to it, and carry on elsewhere.  Perhaps you don't know that the
newsgroup is also a mailing list?

comp.protocols.migrate.to.iso?  Well, sometime I think that the Milo
Medin view on this issue is correct; the ISO migration will turn out
to be from ISO BACK to TCP/IP when network users actually want to get
work done.  So much for my stand on that issue.

I remember when you could actually carry on a useful technical
discussion on this mailing list.  You know, implementations issues and
performance hack and the like.  Now, I know of many network weenies
who can't take the time to sort through the trash to find "useful"
messages.  So we don't read it very much at all.

Perhaps someone from DARPA, NSF, DoE, et al, could fund a person to
moderate the TCP-IP mailing list, making it useful once more.  Or
maybe we could form a new mailing list dedicated to what the TCP-IP
list used to be used for.  I realize now that the Internet protocol
suite has been "discovered" by the trade rags, there are lots of users
that need information.  I just think that there is still the need for
a forum for effective technical discussion.  And the TCP-IP@NIC.DDN.MIL
mailing list doesn't seem to be the place to do it anymore.

Louis Mamakos
-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 11:43:57 -0400 (EDT)
From:      Craig_Everhart@transarc.com
To:        tcp-ip@nic.ddn.mil
Cc:        John.Zsarnay@cs.cmu.edu, butcher@xerox.com, Mike_Kazar@transarc.com, nichols.pa@xerox.com, durham@adobe.com
Subject:   Re: Interesting uses of networking
The cs.cmu.edu Coke machine was hooked up to a computer by John Zsarnay
and/or Lawrence Butcher (now at Xerox PARC); essentially, the six little
out-of-product lights on the pushbuttons were monitored.  These would
flash on for a couple seconds while a particular bottle was dispensed,
and of course stay on when a column was empty.  They were connected, I
believe, to a terminal server machine that was programmed by Mike Kazar
to keep track of the time of the last transition (short-term and
long-term) for each column.  He and Dave Nichols put together a simple
Coke@+(TM) protocol by which any machine on the local University-grant
Ethernet, and later the Internet as a whole, could probe the current
status of the machine; Dave wrote the program that became the ``coke''
command, which printed out the length of time since each column had been
totally empty.  (The idea, you see, was to notice when a column, having
gone empty, was refilled with (warm, room-temperature) Coke, because in
principle you wanted to select the coldest Coke available, and thus
avoid those colums that had recently been refilled.)  Ivor Durham, I
believe, wrote the Finger server that, if you fingered
``coke@somemachine.cs.cmu.edu'' would execute the ``coke'' command and
print out the column coldnesses.  I don't know who wrote the program,
which was one of the most-used Perq/Canvas applications, which displayed
the status of the (imputed) coldnesses as an array of bar graphs
displayed in the same layout as the selector buttons on the Coke machine
itself.  There was even a Gosling Emacs package that would run the coke
command for you and tell you, as a one-liner, where the coldest one was.

The Coke machine even had an internal holding bin, to combat the ``warm
Coke'' problem, such that it would never dispense the last two bottles
in a column.  Thus, to sense when a newly-loaded bottle would be
dispensed, you had to notice when the last two bottles had been
dispensed.  The protocol had a way to describe, separately, the imputed
coldnesses (the refrigeration time) of these last two bottles, and it
would recommend their use when appropriate.

Sure, there are dozens of hacks throughout the world, but I know
something about this one and it's fun.  As far as I can tell, Dave
Nichols spearheaded this one, having loved the idea of the SAIL (r.i.p.)
Pony.
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 09:06:48 EDT
From:      jbvb@vax.ftp.com  (James B. Van Bokkelen)
To:        Scott Brim <swb@dainichi.tn.cornell.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
	From: Scott Brim <swb@dainichi.tn.cornell.edu>

	So are we going to follow through with the idea of running Net 10 in
	the Boston Computer Museum (hooked up to the Internet) or not??

I don't know how receptive they'd be, or what their criteria for
noteworthy hardware is - when MIT shut down the last of the ITS 10s
(actually 2020s) last month, I was listening to someone there talk
about trying to give MC (KL10) to the museum, and being told "we
wouldn't mind having the front panel".  MC went to Sweden (a student
computer club in ?Malmo?), where I believe it is running again.

If they are interested, MIT is presently looking for a home for 10.2.0.6,
among others (10.0.0.44 is gone), but if they aren't, maybe we should
try to get ARPA to give two or three IMPs to the Swedish hackers...

James B. VanBokkelen				FTP Software Inc.
jbvb@ftp.com					617-246-0900
-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 09:38:36 EDT
From:      Bob Stewart <stewart@xyplex.com>
To:        ndsuvm1!plains!lodin@cunyvm.cuny.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Duplicate Internet address on same network
The Ethernet AA-00-04 indicates a DECnet node, with its Ethernet address
"locally administered" to contain the DECnet node number.  You'll find the
fourth byte is a zero.  The last two bytes are the DECnet node number, in, of
course, little-endian form.  The high order 6 bits of the last byte are the
DECnet area.  The rest of the bits are the DECnet node within that area.

(This should be close, its from memory and looking at a sample of one DECNet
node.)

	Bob

-----------
Bob Stewart (rlstewart@eng.xyplex.com)
Xyplex, Boxborough, Massachusetts
(508) 264-9900

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 09:48:38 EDT
From:      stev@vax.ftp.com
To:        Dan Lynch <LYNCH@A.ISI.EDU>, tcp-ip@nic.ddn.mil
Subject:   Re: toll restrictors

>I'm sure Unix could be hacked a bit to do the same as Tenex did many
>years ago.

>Dan
>-------


assuming, ofcourse, that you have enough of the sources . . . .. 


stev

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 21:10:20 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        snorkelwacker!bu.edu!bu-it!kwe@tut.cis.ohio-state.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
Maybe we could get three systems and have one set-up as "cambridge-mb", one as
"reston-mb", and one as "moffett-mb".  We could then have a perpetual trace-
route running with constant redirects between Cambridge and Reston with Moffett
as the, occassional, side-line judge.

Those on the ARPA side may not appreciate the humour of the last days of this 
net as seen from the MILNET side--unfortunately one has attendency to remember
the wierd or worst events.

Merton
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 09:56:30 GMT
From:      oliveb!tymix!tardis!jms@apple.com  (Joe Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tftp (was Re: anonymous ftp, and the dangers thereof)
In article <RANG.90Jun7082318@derby.cs.wisc.edu> rang@cs.wisc.edu (Anton Rang) writes:
>In article <3023@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes:
:  At a minimum, you should restrict either which hosts can access tftp
:on a given machine, or which files tftp can access.  The problem is
:that tftp, as distributed, lets anyone access any publicly-readable
:file, and lots of important files (like /etc/passwd) are publicly
:readable.  (In other words, having tftp enabled allows dictionary
:attacks to be tried without needing an account on the remote machine.)
:  This is my understanding of the matter, at least; feel free to
:correct any misapprehensions.

As distributed from Sun, tftp does NOT allow access to /etc/passwd.
It does a chroot to /tftpboot first.  This means that if you attempt to
read /etc/passwd, the kernel translates it to /tftpboot/etc/passwd, which
does not exist.  The chroot call also means that ".." cannot be used to
get out of set directory.  See "man 2 chroot".

-- 
Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com
BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-C41    | BIX: smithjoe | 12 PDP-10s still running! "POPJ P,"
San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."
-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 16:44:27 -0400
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        nems!dtix!curt@uunet.uu.net (Welch)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: How about comp.internet?
Actually comp.internet would also serve an additional (smaller) purpose,
many of the Internet providers have newsgroups that are regional
in distribution that might be interested in posting to something
like:
	comp.internet.psinet
	comp.internet.nearnet
	comp.internet.nordunet
etc.....

Marty
-------------

 In article <9006111226.AA04905@sayshell.umd.edu>,
 louie@SAYSHELL.UMD.EDU (Louis A. Mamakos) writes:

 >I remember when you could actually carry on a useful technical
 >discussion on this mailing list.  You know, implementations issues and
 >performance hack and the like.

 >... Or maybe we could form a new mailing list dedicated to what the TCP-IP
 >list used to be used for.  I realize now that the Internet protocol
 >suite has been "discovered" by the trade rags, there are lots of users
 >that need information.

 I agree that there is a real need for both a general Internet news group
 and a technical group.  However, I think the best solution would be
 to move all the non technical discussions to a new newsgroup, and let
 TCP-IP return to what it once was.

 Why not create a new group (and mailing list) called comp.internet?

 In general, comp.internet should be for the users and administrators of
 the Internet and comp.protocols.tcp-ip should be for the developers of
 TCP/IP hardware and software.

 Curt Welch
 curt@dtix.dt.navy.mil
 David Taylor Research Center (A Navy Lab)
 Bethesda, MD
 (301) 227-1428
-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 11:08:11 GMT
From:      mcsun!ukc!stc!datlog!gjack@uunet.uu.net  ( Graham Jack)
To:        tcp-ip@nic.ddn.mil
Subject:   A future standard for UNIX TCP/IP?
I hear a rumour that the 4.4BSD TCP/IP is intended to be compliant
with the Host Requirements RFCs (I'm not sure if that included both
RFCs or just RFC1122).
Given the status of the current 4.3BSD TCP/IP as something of a
'functional standard' for UNIX (and other) implementations, it would be
worth a small wager that an enhanced (compliant) 4.4BSD TCP/IP will
be the standard of the future.
If I were a UNIX supplier and I had to choose between fixing my
current port to meet the HRs or hanging on for a new BSD version....
I also heard that 4.4 is to include support for OSI protocols, this
begins to sound too good to be true.

What is the status of 4.4BSD, is there going to be one, does it exist
yet? Does anyone out there have any advance information on what 4.4BSD
might add to the current standard of TCP/IP implementation?

	    Graham Jack, Data Logic.
	    <gjack@datlog.co.uk>
-- 
Regards,
	    Graham Jack, Data Logic.
	    <gjack@datlog.co.uk>
-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 12:06:59 GMT
From:      mcsun!inria!mirsa!jerry.inria.fr!huitema@uunet.uu.net  (Christian Huitema)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Efficiency (or lack thereof) of ASN.1.
A few comment on the efficiency of ASN.1. We did quite a lot of work on
that at INRIA, including the development of alternative encoding rules.
The relative cost of ASN.1 derives from the recursive
``type-length-value'' structure of the BER, plus the cost of decoding
length fields, integers, and reals. The relative cost of ASN.1, compared
to a simpler encoding, depends from the type of elements. To cite, in order:

* the handling of REALs is ludicrous. It is almost equivalent to
converting them to string using something like <sprintf/sscanf>, only
more complex.

* the handling of the Integers, as explained by MTR, uses variable
length big endian complement to 2 notation. The coding can be optimized
somehow, e.g. by predicting the range of the element or by loosening
your compliance to the BER (as advocated by some experts from DEC); the
decoding routines on the other hand must be general. Their cost depends
from the quality of the implementation; I measured a ration of 10 to 20
between BER decoding of integers and a simple ``move''; an endian
reversion would have costed 5 to 6 moves.

* the handling of the strings is comparable to what can be found in
other syntaxes: the coding of the tag and length field may take 20
instructions instead of 1 or 2, but it is outweighted by the copying of
the string itself, which is syntax independant. The decoding can however
be made much longer if your partner insists on passing its strings as
``sequences of segments''.

* the handling of structures requires an analysis of the tags and length
fields. A sequence without optional components has a very low cost; a
set is very costly; a choice cost marginally more than a ``case of''
operation; an array (set of, sequence of) costs significantly longer to
decode than a simple ``count + pointer'' representation, as one can only
assert the number of elements (useful for malloc, bound checking, etc)
by decoding each element and testing the ``length'' field.

In short: the efficiency of ASN.1/BER depends of the complexity of the
structure and of the type of the element. If a simple structure contains
mostly strings, ASN.1 is very efficient. If a semi complex structure
contains a mix of strings and integers (or booleans), one can expect 1
to 4 instructions per byte -- depending of the mix. If the message is a
matrix of floating point numbers exchanged between a Cray and a
graphical workstation, then ASN.1 is about as good as converting the
matrix to a text file... In short, if the application deals mostly with
numbers, one should try to negociate something else than the BER.

For information handling protocols like MHS, X.500, DFR or CMIP (and
SGMP) the cost of the encoding is probably in the 1-4 inst/byte range.
This is  significant, although probably much less than the cost of
retrieving the information itself. And one should point out that the
coding of the DNS is about as costly...

Christian Huitema
-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Jun 90 20:15:52 PDT
From:      infmx!moose!kwang@uunet.UU.NET (Kwang Sung)
To:        UCBCMSA!CLIFF@uunet.UU.NET, ames!elroy!david@uunet.UU.NET, att!lzaz!jer@uunet.UU.NET, callon@bigfut.enet.dec.com, mrose@cheetah.nyser.net, cos!grieve@uunet.UU.NET, lll-winken!psuvax1.uucp!CMSA.BERKELEY.EDU!CLIFF@uunet.UU.NET, amanda@mermaid.intercon.com, iso@nic.ddn.mil, isode@nic.ddn.mil, tcp-ip@nic.ddn.mil, keith@novell.COM, nsc!amdahl!ames!harvard!talcott!wellflt!swillis@uunet.UU.NET, nsc!asylum.sf.ca.us!karl@uunet.UU.NET, nsc!wellfleet.com!bstreile@uunet.UU.NET, jessop@rlgvax.OPCR.ICL.COM, sacto!sparc2!ts@sun.com, nelson@sun.soe.clarkson.edu, gene.saunders@sunkist.West.Sun.COM, jjf@unx.dec.com, schoff@uu.psi.com, voder!ucbvax!nma.com!stef@uunet.UU.NET, watmath!watcgl.waterloo.edu!aparghi@uunet.UU.NET, moose!kwang@uunet.UU.NET

>From: bob@MorningStar.Com (Bob Sutterfield)  wrote:
>Sender: news@MorningStar.COM (USENET Administrator)
>Organization: Morning Star Technologies


Hi...

	Upon Bob's request, I would like to take a normal procedure in order
to create a new newsgroup "comp.protocols.iso.migration" so that nobody can
bother existing newsgroup either "comp.protocols.iso" or "comp.protocols.
tcp-ip" any more.

>if its regular readers were calling for help in the form of another,
>more focused group and list (they aren't), then the group should be
>called comp.protocols.iso.migration, in order to fit in with the
>established naming structure.

>I'd suggest you follow the common newsgroup creation procedure: set up
>a mailing list, broadcast its existence to all appropriate, interested
>forums (e.g. the existing ISO forums), and invite all interested
>parties to join.  When the traffic becomes too heavy for members'
>mailboxes, you'll have a particularly strong case to call for a new
>newsgroup.  At that time, ask someone to help you set up a gateway
>between your iso-migration list and the new c.p.i.m newsgroup.  And
>you have my permission, in advance, to say "I told you so" :-)

>You have asked the folks there whether they're interested in
>segmenting their discussions.  From their responses, I see neither the
>need or the mandate.

	First of all, this new newsgroup can be grouped by anybody who is
interested in migration/transition to OSI. You may discuss any technical
or non-technical issues on any protocols/strategies which might be helpful
to migrate/transit to OSI world. Here are about 40 persons who responded to
my postings so far. I would like to vote whether we need to create such a new 
newsgroup.  Please vote, and e-mail either me or post temporarily at 
"comp.protocols.iso", NOT at "comp.protocols.tcp-ip". After I collect those
info, I will re-post the result at both "comp.protocols.iso" and 
"comp.protocols.tcp-ip". Here is the mailing list, and if you are interested
in joining this new newsgroup, please vote.

------------------------------------------------------------------------------

bob@MorningStar.Com (Bob Sutterfield)
goldstein@carafe.enet.dec.com (Fred R. Goldstein)
oberman@rogue.llnl.gov
cperry@STARBASE.MITRE.ORG (Chris Perry)
Amit Parghi <uunet!watmath!watcgl.waterloo.edu!aparghi>
Bill Streilein <nsc!wellfleet.com!bstreile>
CLIFF@UCBCMSA (Cliff Frost {415} 642-5360)
uunet!elroy.Jpl.Nasa.Gov!david (David Robinson)
dennis@gpu.utcs.utoronto.ca (Dennis Ferguson)
Stef@NRTC.NORTHROP.COM (Einar Stefferud)
uunet!proteon.com!gmalkin (Gary Scott Malkin(GONE))
grieve@cos.com (David Grieve)
uunet!wrs!yuba!hwajin (Hwa Jin Bae)
att!lzaz!jer
jessop@rlgvax.OPCR.ICL.COM (Lynn Jessop)
uunet!unx.dec.com!jjf (8N8-FRANEY)
nsc!asylum.sf.ca.us!karl (Karl Auerbach)
keith@excelan.COM (Keith Brown)
Hakiml Laraqui  <uunet!sics.se!laraqui>
ncr-sd!ncrcae!lhybl
louie@SAYSHELL.UMD.EDU (Louis A. Mamakos)
uunet!uu.psi.com!schoff (Martin L. Schoffstall)
David Hayes <uunet!csvax.seas.smu.edu!merlin>
uunet!ukc.ac.uk!mhs
mrose@CHEETAH.NYSER.NET (Marshall Rose)
vaillan@ireq.hydro.qc.ca (Clement Vaillancourt)
nelson@sun.soe.clarkson.edu (Russ Nelson)
richardt@Legato.COM
saunders@gesundheit.West.Sun.Com (Gene Saunders)
schoff@PSI.COM ("Martin Lee Schoffstall")
Einar Stefferud <voder!ucbvax!nrtc.northrop.com!Stef>
Steven Willis <nsc!amdahl!ames!harvard!talcott!wellflt!swillis>
torben@FORALIE.ICS.HAWAII.EDU (Torben Nielsen)
uunet!sacto.West.Sun.COM!sparc2!ts (Troy Schumaker)
amanda@mermaid.intercon.com (Amanda Walker)
curt@dtix.dt.navy.mil (Welch)

--------------------------------------------------------------------------------

>In summary, we should continue discussing migration issues in the
>existing forum.  When the popular mandate arises for a new forum,
>create it as a mailing list.  When the mailing list becomes too busy,
>establish a gateway to a newsgroup named comp.protocols.iso.migration.

	Thanks, Bob... and, from my previous postings, I would like to
apologize to some persons, if they felt hurt from me. I am sure this new
newsgroup will resolve our networking future, and will give us a right 
direction. Thanks.



					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

--------------------------------------------------------------------------------
Disclaimer: Those opinions are mine alone, not my employers'.
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 14:21:36 GMT
From:      netwrx1!mindel@uunet.uu.net  (Joshua L Mindel)
To:        tcp-ip@nic.ddn.mil
Subject:   Wollongong TCP/IP WIN/3B 3.0 - UUCP/TCP/IP password capability?
I'd like to use UUCP for file transfers between AT&T 3B2s interconnected
via TCP/IP.

MY QUESTION:  Is there any way to specify a password in the uucico command?

The AT&T Enhanced TCP/IP WIN 3B Installation/Administration guide provides
steps to set-up UUCP over TCP/IP on a 3B2 in a trusted environment.
In this context, a trusted environment is one in which password protection 
is not required.

The WIN software utilizes the standard UUCP programs and datafiles,
but disregards the chat script in the Systems file.  Instead, the userid
that uucico uses to login to a remote machine is specified in the uucico
command itself (via the -u option).  The password requirement on the remote end
is bypassed somehow by the WIN software.  The end result is that two 
nodes running UUCP/TCP/IP can establish a communications link via address and 
userid only; whether or not a password is associated with that userid.

A broader question:  Is there any means by which to utilize passwords in
UUCP/TCP/IP communications?   uucico seems the most obvious place to me.
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 14:24:43 GMT
From:      netwrx1!mindel@uunet.uu.net  (Joshua L Mindel)
To:        tcp-ip@nic.ddn.mil
Subject:   UUCP/TCP/IP question:  oops, my signature didn't get included
Hi, I just posted the question concerning passwords with UUCP over TCP/IP
on AT&T 3B2s.  Unfortunately, I don't believe that my signature got
included in the message before it was sent out.

-------------------------------------------------------------------------------
Joshua L Mindel				Internet:  mindel%netwrx1@uunet.uu.net
Senior Analyst				Usenet:	   uunet!netwrx1!mindel
NetWorks One				Phone:     (703) 827-7767
8229 Boone Blvd., Suite 810 		Fax:	   (703) 790-9372
Vienna, VA  22182 
-------------------------------------------------------------------------------
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 14:33:14 GMT
From:      mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu  (Bob Sutterfield)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"
In article <4460@infmx.UUCP> kwang@infmx.UUCP (Kwang Sung) writes:
   Recently, I've proposed a new newsgroup
   "comp.protocols.migrate.to.iso".

      From: Amit Parghi <aparghi@watcgl.waterloo.edu>

      Don't use the name "comp.protocols.migrate.to.iso"; since there
      are already groups under "comp.protocols.iso", call it
      "comp.protocols.iso.migration".

If comp.protocols.iso and its associated mailing list,
iso@nic.ddn.mil, were swamped with transition traffic (it isn't) and
if its regular readers were calling for help in the form of another,
more focused group and list (they aren't), then the group should be
called comp.protocols.iso.migration, in order to fit in with the
established naming structure.

   First of all, I would like to show some responses in order to prove
   why we need to create those new newsgroup.

I'd suggest you follow the common newsgroup creation procedure: set up
a mailing list, broadcast its existence to all appropriate, interested
forums (e.g. the existing ISO forums), and invite all interested
parties to join.  When the traffic becomes too heavy for members'
mailboxes, you'll have a particularly strong case to call for a new
newsgroup.  At that time, ask someone to help you set up a gateway
between your iso-migration list and the new c.p.i.m newsgroup.  And
you have my permission, in advance, to say "I told you so" :-)

I suspect that the existing list and group facilities are able to
manage the traffic.  In fact, "the impending IP-ISO transition" is one
of the topics of comp.protocols.iso and its associated mailing list.
You have asked the folks there whether they're interested in
segmenting their discussions.  From their responses, I see neither the
need or the mandate.

In summary, we should continue discussing migration issues in the
existing forum.  When the popular mandate arises for a new forum,
create it as a mailing list.  When the mailing list becomes too busy,
establish a gateway to a newsgroup named comp.protocols.iso.migration.
-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 15:44:16 GMT
From:      nems!dtix!curt@uunet.uu.net  (Welch)
To:        tcp-ip@nic.ddn.mil
Subject:   How about comp.internet?
In article <9006111226.AA04905@sayshell.umd.edu>,
louie@SAYSHELL.UMD.EDU (Louis A. Mamakos) writes:

>I remember when you could actually carry on a useful technical
>discussion on this mailing list.  You know, implementations issues and
>performance hack and the like.

>... Or maybe we could form a new mailing list dedicated to what the TCP-IP
>list used to be used for.  I realize now that the Internet protocol
>suite has been "discovered" by the trade rags, there are lots of users
>that need information.

I agree that there is a real need for both a general Internet news group
and a technical group.  However, I think the best solution would be
to move all the non technical discussions to a new newsgroup, and let
TCP-IP return to what it once was.

Why not create a new group (and mailing list) called comp.internet?

In general, comp.internet should be for the users and administrators of
the Internet and comp.protocols.tcp-ip should be for the developers of
TCP/IP hardware and software.

Curt Welch
curt@dtix.dt.navy.mil
David Taylor Research Center (A Navy Lab)
Bethesda, MD
(301) 227-1428
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 16:49:48 GMT
From:      van-bc!ubc-cs!kiwi!zaphod!kell@ucbvax.Berkeley.EDU  (Dave Kell)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP reliability
Does SLIP have the same level of error detection and correction that
ethernet-based IP has?

Dave Kell
MPR Teltech Ltd.
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 17:14:38 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!rpi!bu.edu!bu-it!kwe@ucsd.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Multiple IP networks on one Ethernet interface
In article <90Jun6.101602edt.57781@ugw.utcs.utoronto.ca>,
FILLMORE@EMRCAN.BITNET writes:
> ... I would like to know if any of
> the commercially-available TCP/IP packages have the capability of either:
> 
>      1)  sending and receiving IP packets for more than one subnetwork
>          over the same Ethernet interface.
> 
>  or: 2)  routing packets between two or more subnetworks over the
>          same Ethernet interface.
> 
> We have several spare Ethernet bridges but only one router - a Cisco.

	Multiple subnets on a single interface is a feature of the latest
cisco software.  Look in the manual update section, not the manual.  It
is the primary/secondary designation of the ip-address of a given
interface.
 ...
> We also run WIN/TCP for VAX/VMS and Control Data's TCP/IP product.  Can
> either of these be configured for multiple subnets on one interface?
> 
	Rather than configure each host to be a member of each subnet on 
the given wire, I would recommend setting the subnet mask such that each
host on the wire would ARP for all directly connected hosts.

	You could simply set the subnetmask to the netmask (ie, no subnet)
on each host on the LAN and let the router proxy for any nonlocal destinations.
This seems to me to be a cleaner approach than creating multiple addresses 
for each host on the shared subnets.

	This will not work for multiple networks, only subnets.
-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 17:22:33 GMT
From:      snorkelwacker!bu.edu!bu-it!kwe@tut.cis.ohio-state.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
In article <9006101018.AA04161@chumley.TN.Cornell.EDU>, 
swb@DAINICHI.TN.CORNELL.EDU (Scott Brim) writes:
> So are we going to follow through with the idea of running Net 10 in the
> Boston Computer Museum (hooked up to the Internet) or not??

	I think it is a great idea.  If you know a contact there, I would
talk to them.

	But if that doesn't pan out, it shouldn't be too hard to create a
net 10 routing loop inside BBN somewhere.  I think an occasional ping packet
would feel right at home wandering around inside 10 Moulton Street somewhere.
:-)  Does that seem appropriately respectful?  (Certainly no disrespect
intended to BBN.)

	--Kent England, Boston University
-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 17:52:50 GMT
From:      shlump.nac.dec.com!carafe.enet.dec.com!goldstein@decuac.dec.com  (Fred R. Goldstein)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"[Part 1]

In article <4460@infmx.UUCP>, kwang@infmx.UUCP (Kwang Sung) writes...
>	Recently, I've proposed a new newsgroup "comp.protocols.migrate.to.iso".
>I've received so many responses. Among those, I've selected some best ones, 
>after I've thrown out some bad ones. I couldn't reply to all of you, since it's
>so many. However, I might be able to answer thru this network. I think some 
>people still don't understand how/where this networking world is going to. 
>Absolutely, and positively, the world is moving toward one OSI world !!,
>even if ISODE has screwed up OSI world a little bit. 

John Franey, who works for the same company that I do (and I don't
think either of us is speaking officially here!) says, 
>TCP/IP is connectionless, OSI is connection oriented.
>Multimedia needs multiple synchronized data circuits.  Datagrams can't be lost
>or take variously different routes (TCP/IP).

That basically is wrong.  TCP/IP is connectionless (CL) at the top of the 
network layer.  OSI offers BOTH CO and CL services.  DECnet/OSI provies
the CLNS, not unlike IP.  It also supports the CONS when needed for
compatibility, but its "native language" is connectionless.  ISO settled 
the CLNS/CONS war by standardizing both.  And multimedia is irrelevant.
If anything, the higher speeds possible in CLNS tend to make it more
applicable for multimedia than CONS, which is X.25-based.

>DEC has commited itself to OSI.  All of its customers computer network nodes
>are going to be converted to OSI with the release of DECnet Phase V.  I work
>for DEC but not in communications engineering but please don't think this is a
>plug.  

While I'm not a spokesman, I do work for DEC in communications 
engineering.  We have certainly taken a leading role in OSI.  But we
are also building TCP/IP.  And while Phase V is OSI up to Layer 3 it
supports OSI and non-OSI in parallel using a "towers" approach.  Most
DEC-DEC applications won't use the OSI upper layers.  Note that it's
the upper layers of OSI that are most controversial.

>TCP/IP is NOT popular in Europe.  It doesn't surprise me that its not popular
>in Korea either.  The big reason here is that the PTTs that implement and
>use the networks in Europe are connection oriented.  They wand Virtual
>Circuits.  TCP/IP is a datagram network and is not acceptable.

The PTTs only own their own internal networks.  They provide X.25
subnetworks.  In OSI terminology (see ISO8648) ANY public network
is just a subnetwork; you may run an NS-protocol on top of it.  So
you can run OSI-CLNS (ISO8473, found in DECnet/OSI) and be fully
OSI compliant, or you can run IP above it and be fully TCP/IP compliant.
The PTTs have no say in what you do above their subnet layers.  
Datagrams are not easy to bill for, so the subnet is still CO.

I post this because I don't think the terms of reference of this debate 
should be based on misinformation, like "OSI is connection-oriented"
or "PTTs won't allow TCP/IP to be used in Europe."  OSI CLNS + TP4
is not very different (semantically) from IP and TCP.  They provide a
growth path, especially since IP addressing has obvious limitations.  
But they also provide coexistence.  TCP/IP is a valued technology and
while comp.protocols.osi.migration might be a good group to have,
extremist anti-TCP/IP rhetoric will make the transition harder and more
painful for all involved. 
---
Fred R. Goldstein   goldstein@carafe.enet.dec.com 
                 or goldstein@delni.enet.dec.com
                    voice:  +1 508 486 7388 
opinions are mine alone; sharing requires permission
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 19:56:50 GMT
From:      intercon!news@uunet.uu.net  (Kurt Baumann)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: X Windows and TCP/IP on the Macintosh
In article <9006071808.AA08561@xap>, stewart@xyplex.com (Bob Stewart) writes:
> Dear Generous Suppliers of Free Advice,
> 
> I'm using NCSA Telnet on my Macintosh to talk to a Unix system so I can
> communicate with the world.  It's connected through AppleTalk to a Gator Box.
> I'd like to have a more direct connection for mail, FTP, etc., as well as 
> X Windows access.
> 
> We're looking into White Pine Software's eXodus, which implements X Windows
> over a communication base such as Alisa Systems' TSS for DECnet or Apple's
> MacTCP for the Internet.  I'd like to hear from people who've tried that or
> who know anything interesting about it.  If I have MacTCP, can I run FTP,
> Telnet, eXodus, and such just as if I was on a Real :-) System?  If so, can
> they all run at once?  White Pine tells me that eXodus/MacTCP and NCSA Telnet
> are mutually exclusive.  If anyone from Apple or White Pine cares to respond,
> I won't consider it as a commercial message.
> 

Here is the scoop.  If you are using NCSA Telnet with the builtin NCSA TCP/IP
stack, then you cannot also use anything that uses MacTCP.  If, however,
you either get a commercial product that uses MacTCP (like TCP/Connect II,
or the UB product) or you get the NCSA Telnet that uses MacTCP, then you
can use other programs that use MacTCP at the sametime.  As far as I am aware
there should be no problem in using eXodus with other MacTCP compatable
products.

Hope that helps.

Kurt Baumann--
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 21:18:49 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   OSI Transition mail group
In article <9006062107.AA23343@moose.informix.com>, kwang@moose.UUCP (Kwang Sung) writes:
> Yes. I am so serious. We need to create a new newsgroup "comp.protocols.
> migrate.to.iso". For instance, recently I've designed and implemented RDA 
> (ISO/IEC DP 9579-1) on top of SunLink OSI and TCP/IP with RFC 1006 on my 
> SPARCstation 1. Actually, I've embedded it into ISODE 6.0.  However,
> a lot of customers wanted to put it on top of lpp (RFC 1085). I have a trouble
> with finding those specific bridges between RFC 1085 and "pure" OSI stack.
> If we create those new newsgroup, then we can have an info on migration from
> "old" TCP/IP technology, SNA, or other protocols to "new" OSI technology.
> As far as I know, application gateways, transport gateways, network tunnels,
> protocol tunnels, etc are the only primitive methods for the migration. 
> Actual environment needs higher technology.

I think such a group might not be too inappropriate. I am in the middle of
planning such a migration for a multi-thousand node global network, and while I
don't expect things to happen instantly, it's time to start looking at the
issues.

As far as the group name, I might suggest comp.protocols.iso.transition. It
fits the existing structure much better (I think). I prefer transition to
migration because the birds keep migrating back and forth and if we make it to
ISO, we plan to stay there.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      11 Jun 90 21:49:49 GMT
From:      excelan!george@ames.arc.nasa.gov  (George Powers)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Out Of Band data processing.
From excelan!zaphod.mps.ohio-state.edu!samsung!uunet!ogicse!littlei!intelisc!isc.intel.com!joel Mon Jun 11 13:26:24 PDT 1990
Article 3226 of comp.protocols.tcp-ip:
Path: excelan!zaphod.mps.ohio-state.edu!samsung!uunet!ogicse!littlei!intelisc!isc.intel.com!joel
>From: joel@isc.intel.com (Joel Clark)
Newsgroups: comp.protocols.tcp-ip
Subject: Out Of Band data processing.
Message-ID: <772@intelisc.isc.intel.com>
Date: 7 Jun 90 20:24:42 GMT
Sender: joel@isc.intel.com
Distribution: na
Organization: Intel Scientific Computers, Beaverton, Oregon
Lines: 28



Two questions regarding Out Of Band data processing.

1) If a socket has the OOBINLINE option set and a user calls recv() on it
   with the MSG_OOB flag set, what should be returned to the recv() call?
	An error? which error?
	The next data in the INLINE Queue?

2) If a socket does not have the OOBINLINE option set and a user calls 
   recv() on it with the MSG_OOB flag set and there is no Out OF Band data
   what should happen?

	The recv() call blocks waiting for Out Of Band data unless the
	socket is NON-Blocking in which case the recv call returns
	EWOULDBLOCK in errno?

	The recv() call returns zero bytes immediately?

	The recv() call returns an error? which error?

Please Email if possible and I will summarize for the net.

Joel Clark
Intel Scientific Computers
Beaverton, Or. USA
(503) 629-7732
joel@isc.intel.com


--
UUCP: {ames,sun,apple,mtxinu,cae780,sco}!novell!george  George Powers
Internet: george@novell.com 
--
-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jun 90 07:58 PDT
From:      Michael Stein                        <CSYSMAS@OAC.UCLA.EDU>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Mourning of the passing of the ARPANET
Net 10 is a class A network number.  As we run out of network
numbers someone is going to need it, don't stick it in some
museum.  I'm sure that if anyone asked there would be lots
of volunteers who could turn in several class B network numbers...
-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 02:44:48 GMT
From:      snorkelwacker!spdcc!ima!minya!jc@tut.cis.ohio-state.edu  (John Chambers)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: desperately need an answer
In article <9006061544.AA08499@ucbvax.Berkeley.EDU>, CHAIBP@NUSDISCS.BITNET writes:
> Clark, in his RFC 817, said that kernel implementation
> of TCP/IP would subject to many system limitations and
> suggested that only part of TCP/IP should be placed in
> the kernel, leaving the rest in the user processes.
> 
> Now, what I don't understand is that why everybody still
> put the entire TCP/IP in the kernel - AT&T system V,
> Sun BSD Unix and many others all does just that. Does
> that mean that those limitations are never faced by them
> or that they have actually took his advice but provided the
> interfaces to the user processes in a way that gives
> them the illusion of interfacing with the kernel ?

This one's easy.  People are paid more for kernel work than they
are for application-level work, so they have a strong incentive
to do as much work there as possible.  I've seen a lot of this,
and it goes a long way to explain why Unix kernels are becoming
so bloated.  When you reward people better for using method A
than for methods B, C, ..., it should come as no surprise that
they will tend to use method A.

Until a few years ago, I foolishly took the approach of doing
work wherever it seemed best, and this was almost never inside
the kernel.  After a while, I noticed that the main effect of
this was to make it clear to prospective employers that I was
a kernel lightweight.  Now I know better.

(Note the lack of :-)s above. ;-)

-- 
Uucp: ...!{harvard.edu,ima.com,mit-eddie.edu}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: It's never to late to have a happy childhood.
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 03:04:34 GMT
From:      nsc!pyramid!infmx!kwang@decwrl.dec.com  (Kwang Sung)
To:        tcp-ip@nic.ddn.mil
Subject:   Vote for/against "comp.protocols.iso.migration"
>From: bob@MorningStar.Com (Bob Sutterfield)  wrote:
>Sender: news@MorningStar.COM (USENET Administrator)
>Organization: Morning Star Technologies


Hi...

	Upon Bob's request, I would like to take a normal procedure in order
to create a new newsgroup "comp.protocols.iso.migration" so that nobody can
bother existing newsgroup either "comp.protocols.iso" or "comp.protocols.
tcp-ip" any more.

>if its regular readers were calling for help in the form of another,
>more focused group and list (they aren't), then the group should be
>called comp.protocols.iso.migration, in order to fit in with the
>established naming structure.

>I'd suggest you follow the common newsgroup creation procedure: set up
>a mailing list, broadcast its existence to all appropriate, interested
>forums (e.g. the existing ISO forums), and invite all interested
>parties to join.  When the traffic becomes too heavy for members'
>mailboxes, you'll have a particularly strong case to call for a new
>newsgroup.  At that time, ask someone to help you set up a gateway
>between your iso-migration list and the new c.p.i.m newsgroup.  And
>you have my permission, in advance, to say "I told you so" :-)

>You have asked the folks there whether they're interested in
>segmenting their discussions.  From their responses, I see neither the
>need or the mandate.

	First of all, this new newsgroup can be grouped by anybody who is
interested in migration/transition to OSI. You may discuss any technical
or non-technical issues on any protocols/strategies which might be helpful
to migrate/transit to OSI world. Here are about 40 persons who responded to
my postings so far. I would like to vote whether we need to create such a new 
newsgroup.  Please vote, and e-mail either me or post temporarily at 
"comp.protocols.iso", NOT at "comp.protocols.tcp-ip". After I collect those
info, I will re-post the result at both "comp.protocols.iso" and 
"comp.protocols.tcp-ip". Here is the mailing list, and if you are interested
in joining this new newsgroup, please vote.

------------------------------------------------------------------------------

bob@MorningStar.Com (Bob Sutterfield)
goldstein@carafe.enet.dec.com (Fred R. Goldstein)
oberman@rogue.llnl.gov
cperry@STARBASE.MITRE.ORG (Chris Perry)
Amit Parghi <uunet!watmath!watcgl.waterloo.edu!aparghi>
Bill Streilein <nsc!wellfleet.com!bstreile>
CLIFF@UCBCMSA (Cliff Frost {415} 642-5360)
uunet!elroy.Jpl.Nasa.Gov!david (David Robinson)
dennis@gpu.utcs.utoronto.ca (Dennis Ferguson)
Stef@NRTC.NORTHROP.COM (Einar Stefferud)
uunet!proteon.com!gmalkin (Gary Scott Malkin(GONE))
grieve@cos.com (David Grieve)
uunet!wrs!yuba!hwajin (Hwa Jin Bae)
att!lzaz!jer
jessop@rlgvax.OPCR.ICL.COM (Lynn Jessop)
uunet!unx.dec.com!jjf (8N8-FRANEY)
nsc!asylum.sf.ca.us!karl (Karl Auerbach)
keith@excelan.COM (Keith Brown)
Hakiml Laraqui  <uunet!sics.se!laraqui>
ncr-sd!ncrcae!lhybl
louie@SAYSHELL.UMD.EDU (Louis A. Mamakos)
uunet!uu.psi.com!schoff (Martin L. Schoffstall)
David Hayes <uunet!csvax.seas.smu.edu!merlin>
uunet!ukc.ac.uk!mhs
mrose@CHEETAH.NYSER.NET (Marshall Rose)
vaillan@ireq.hydro.qc.ca (Clement Vaillancourt)
nelson@sun.soe.clarkson.edu (Russ Nelson)
richardt@Legato.COM
saunders@gesundheit.West.Sun.Com (Gene Saunders)
schoff@PSI.COM ("Martin Lee Schoffstall")
Einar Stefferud <voder!ucbvax!nrtc.northrop.com!Stef>
Steven Willis <nsc!amdahl!ames!harvard!talcott!wellflt!swillis>
torben@FORALIE.ICS.HAWAII.EDU (Torben Nielsen)
uunet!sacto.West.Sun.COM!sparc2!ts (Troy Schumaker)
amanda@mermaid.intercon.com (Amanda Walker)
curt@dtix.dt.navy.mil (Welch)

--------------------------------------------------------------------------------

>In summary, we should continue discussing migration issues in the
>existing forum.  When the popular mandate arises for a new forum,
>create it as a mailing list.  When the mailing list becomes too busy,
>establish a gateway to a newsgroup named comp.protocols.iso.migration.

	Thanks, Bob... and, from my previous postings, I would like to
apologize to some persons, if they felt hurt from me. I am sure this new
newsgroup will resolve our networking future, and will give us a right 
direction. Thanks.



					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

--------------------------------------------------------------------------------
Disclaimer: Those opinions are mine alone, not my employers'.
-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 03:10:21 GMT
From:      zaphod.mps.ohio-state.edu!usc!snorkelwacker!spdcc!ima!minya!jc@tut.cis.ohio-state.edu  (John Chambers)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: abolishing /etc/passwd (was Re: anonymous ftp, and the dangers thereof)
In article <37166@think.Think.COM>, barmar@think.com (Barry Margolin) writes:
> In article <9006060704.AA02343@WLV.IMSD.CONTEL.COM> sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) writes:
> >just a "thought" - if the (shadow)file is non-world readable and the
> >system is administered "correctly" then why bother with
> >encryption at all ;-)
> 
> I'm not sure how non-serious that smiley represents.  The serious answer is
> that even system administrators should not be able to find out a user's
> password.  Sure, they don't need to know the user's password to violate the
> user's files.  But if they know someone's password then they could
> accidentally (or through coercion) divulge it to someone else.

Some years back, I saw an enlightening instance of all of the above.
The participants shall remain nameless; the OS was Univac's EXEC8 on
the 1108, for which every file had both a read and a write password.
The system stored these internally in an unencrypted form, and one
of the local games was to try to find holes in the system that let
one access them.  One of the holes was intentional:  There was a
system utility that would list files and their passwords, so that
an administrator could delete files.  One administrator was rather
unpopular with users; and one day he got a bunch of guys in the
EE and physics departments especially mad at him, so they changed
their files to have a read password that was a well-known sexual
verb starting with 'f', and a write password that was his name.
They took no further action.

At the next campus-wide users-group meeting, he got into a dispute
with some of them, and in the heat of the moment, he made some rather
disparaging remarks about the nature of people who would use obscene
insults about him as their passwords.  They didn't respond.

The next day, they all wrote letters to his superiors complaining about
the fact that he had, in a public meeting, made statements that enabled
listeners to guess the passwords on their files.  It was perhaps just a
coincidence, but in very short order he no longer worked there.

Myself, I was satisfied with finding one way to do raw disk I/O that
showed a few such passwords, then I went on to more interesting work.

-- 
Uucp: ...!{harvard.edu,ima.com,mit-eddie.edu}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: It's never to late to have a happy childhood.
-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jun 90 10:07:39 -0400
From:      wuu@dumbo.jvnc.net (Sze-ying Wuu)
To:        mailrus!bbn.com!craig@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re: Dial up access to Internet facilities

>	CSNET did this some time ago with MMDF2b.  Some of the dial-up sites run
>	a script every night which brings up the dial-up line, and then opens
>	a connection to a port on relay.cs.net and tells it to start delivering
>	mail to the site.  The application at that connection starts up the
>	appropriate MMDF channel (mmdf can have multiple SMTP delivery channels,
>	where a channel typically has messages destined for a particular site),
>	which delivers the mail to the site.  [Note there's no security problem
>	here -- anyone can start up the channel, but the channel will only deliver
>	to the proper remote system(s)]
>
>	Craig
>


Does CSNET uses Phonenet protocol for dial-up sites? 

We have 1986 version of MMDF, is there a newer version available from
pulic domain? I assume with MMDF, we still need MX RR for a host to
accumulate mail for all dial-up sites. Is there a limitation on the
number of channnels can be fired up? 

Sze-Ying Wuu
JvNCnet
wuu@nisc.jvnc.net
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 03:46:59 GMT
From:      snorkelwacker!spdcc!ima!minya!jc@tut.cis.ohio-state.edu  (John Chambers)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <1990Jun8.134620.24070@cs.rochester.edu>, bukys@cs.rochester.edu (Liudvikas Bukys) writes:
> In article <392@minya.UUCP> jc@minya.UUCP (John Chambers) writes:
> >The obvious counter-example to this is /usr/spool/uucppublic, which
> >is almost always world-writable, yet there seem to be no reports of
> >even minor problems with this.  It's usually considered a useful
> >part of uucp, and an assortment of tools are around (uuto/uupick for
> >example) are layered on top of it.
>
> 1.  Here's one "minor problem" report: I have heard that .rhosts
>     files have been uucped into ~uucp.  Think about it.

Yeah; I've often wondered about the practice of making ~uucp be
/usr/lib/uucppublic, and this is just one of the reasons why this
isn't a good idea.  Even if you aren't on the internet, consider
uucping something into ~uucp/.profile, ~uucp/.cshrc, etc.

The most basic uucp security says that you only allow the world
to write to /usr/lib/uucppublic, which is nobody's home directory.
(Of course, since Sun started selling systems on which "nobody"
is a valid login, this rule should perhaps be rephrased... :-)
Trusted users might be allowed access to other directories, such
as their own home directories.  But for your own sanity, you should
try to prevent the copying of files (especially accidentally) into
uucp's home directory.  Security aside, correcting the problems when
someone duplicates a filename there can be really crazy.

This isn't unique to uucp, of course.  I've seen several cases of
people building email systems with an administrative pseudo-user,
whose home directory was the mail spool directory.  It seems like
a good idea until a higher-level package uses a file-name convention
that produces a name that matches one of the control (or source ;-)
files.  This can be surprisingly difficult to avoid, considering
that packages typically come from several sources.  "What do you
mean, you set up `Systems' and `Dialers' accounts right after we
merged /usr/spool/mail with /usr/lib/uucp?"  It's a good idea to 
separate home directories from working directories, if you want 
to get it all working.

-- 
Uucp: ...!{harvard.edu,ima.com,mit-eddie.edu}!minya!jc (John Chambers)
Home: 1-617-484-6393
Work: 1-508-952-3274
Cute-Saying: It's never to late to have a happy childhood.
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 04:59:34 GMT
From:      munnari.oz.au!bunyip!brolga!ggm@uunet.uu.net  (George Michaelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Please, no more transit vs migrate smirking

If I hear/read one more article from <arbitrary wise-old-owl> 
about transit vs migrate I gonna go off pop.

Migrate is appropriate when you behave like a flock of sheep about 
something, have random goats to be separated out, shepherds pushing 
you into small confined spaces, with snarling dogs nipping your heels, 
and have a bunch of lone wolves picking off stragglers along the edge. 

It also applies to large flighty crowds that head around aimlessly, 
following a leader blindly on faith, and split up into a zillion separate 
paths when attacked, and also the ones that seem to keep coming back year 
after year to the same old turf. 

Sounds like network debates to me...

Around here, OSI is like buying this years vintage:

	-Tastes awful when you sample, but your nose tells
	 you its going to improve with age.

Enough mixed metaphors.

George
-- 
	G.Michaelson
Internet: G.Michaelson@cc.uq.oz.au                     Phone: +61 7 377 4079
  Postal: George Michaelson, Prentice Computer Centre
          The University of Queensland, St Lucia, QLD Australia 4067. 
-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 07:07:19 GMT
From:      bellcore-2!ka9q.bellcore.com!karn@bellcore.com  (Phil Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: A proposal on a new newsgroup "comp.protocols.migrate.to.iso"

I also support the creation of a "comp.protocols.migrate-to-osi" newsgroup.
The longer we can keep the OSI cheerleaders preaching to themselves, the
less damage they'll be able to wreak among the rest of us who are building
real networks, supporting real users, and solving real problems instead of
artificial ones.

And during slow moments it'll always be good for a laugh; perhaps somebody
can excerpt the better items for rec.jokes.funny.

BTW, I think the term "migrate" is highly appropriate here for the very same
reason that some others want to change it...

Last fall, Marshall Rose and I were among the participants in a panel
discussion on protocol standards at the NORDUNET conference in Stockholm.
Rolf Nordhagen, the Norwegian moderator, led off with a question that pretty
much said it all: "If OSI is the solution, then what is the problem?"

I sure wish I had thought of that one. But it's better that a European
said it first.

Phil
-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 14:24:45 PDT (Tue)
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        van-bc!ubc-cs!kiwi!zaphod!kell@ucbvax.berkeley.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: SLIP reliability
Dave Kell asks:
   Does SLIP have the same level of error detection and correction that
   ethernet-based IP has?

IP and its transport protocols (TCP or UDP or whatever) running over
SLIP will use the same error detection algorithms (IP header checksum,
TCP or UDP data checksum) that they will over ethernet.

SLIP doesn't include any error checking; it just frames the packet
over an asynchronous link. Ethernet does a CRC check of each packet,
so there is a difference at this level.
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
"There is no loyalty except loyalty to the party. There is no love except love
of Big Brother. All competing pleasures we will destroy." - 1984 (film)
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jun 90 12:17:13 EDT
From:      lazear@gateway.mitre.org
To:        tcp-ip@nic.ddn.mil
Subject:   TCPtrace port to HP
I have a colleague who needs to know the effort required to
port TCPtrace to an HP 3000.  I don't know if there's some
showstoppers in the kernel arrangement that would prevent
this from being easy.  I assume IP is similar enough to make 
that portion a wash.  Please write me directly.

	Walt Lazear
	lazear@gateway.mitre.org
-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jun 90 14:33:20 EDT
From:      Bill Streilein <bstreile@wellfleet.com>
To:        tcp-ip@nic.ddn.mil
Subject:   bootp
Hello,
Does anyone know of a public domain bootp
source?  Maybe another public domain trivial
boot program?

Thanx in advance,
Bill Streilein
bstreile@wellfleet.com
Wellfleet Communications, Inc.

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 10:35:11 GMT
From:      ads.com!snmp-ok-forw%nisc.nyser.net@ames.arc.nasa.gov  (Armin Schweizer)
To:        tcp-ip@nic.ddn.mil
Subject:   SNMP Agents on SUN
As most of us know, SUN currently does not intend to deliver
SNMP agents with their SUN/3 and SPARC Systems. As I was
informed, there are SUN-SNMP agents available from the following
universities:

- Massachusets Institute of Technology
- Carnegie Mellon
- University of Tennessee, Knoxville

Who can tell me more specific (e-)mail addresses?

thank you
armin schweizer


-- 

       Armin R. Schweizer, CIBA-GEIGY AG, R1045.P.06, WRZ
                  4002 Basel / Switzerland
	          phone: -41-61-697'79'46
		  e-mail: cgch!wasc@relay.EU.net
-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jun 90 14:54:46 EDT
From:      Bill Streilein <bstreile@wellfleet.com>
To:        tcp-ip@nic.ddn.mil
Subject:   Subnet Broadcasting

Hello,

Mogul & Postel [RFC 950] specify that the subnet field must
never be all 0's or all 1's.  Thus,

       128.10.0.0  with a mask of 255.255.255.0 

would be an invalid subnet.  Has the thought on this changed
since this was proposed?  For instance, if all broadcasts are
all 1's only, is a 'zero' subnet allowed? 

Thanx in advance,
Bill Streilein
bstreile@wellfleet.com
Wellfleet Communications, Inc.
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 18:14:11 PDT (Tue)
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        bstreile@wellfleet.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Subnet Broadcasting
There are a couple of reasons why all 0's is a bad idea. One is
historical reasons; old versions of the BSD code used to use all 0's
as the broadcast address.

Another reason is to help screen out bugs. An uninitialized value will
often default to 0, so from a technical perspective it's often a good
idea to avoid using 0 as a magic number, like a subnet number or such.
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
"There is no loyalty except loyalty to the party. There is no love except love
of Big Brother. All competing pleasures we will destroy." - 1984 (film)
-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 13:10:47 GMT
From:      ficc!peter@uunet.uu.net  (Peter da Silva)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How about comp.internet?
In article <2225@nems.dt.navy.mil> curt@dtix.dt.navy.mil (Curt Welch) writes:
> I agree that there is a real need for both a general Internet news group
> and a technical group.  However, I think the best solution would be
> to move all the non technical discussions to a new newsgroup, and let
> TCP-IP return to what it once was.

Hear, hear. I read c.p.tcp-ip for tcp-ip information. We don't have any
interest in the Internet or Internet politics... we use tcp-ip internally
along with tp4, and could care less about the politics.
-- 
`-_-' Peter da Silva. +1 713 274 5180.  <peter@ficc.ferranti.com>
 'U`  Have you hugged your wolf today?  <peter@sugar.hackercorp.com>
@FIN  Dirty words: Zhghnyyl erphefvir vayvar shapgvbaf.
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 14:58:00 GMT
From:      CSYSMAS@OAC.UCLA.EDU (Michael Stein)
To:        comp.protocols.tcp-ip
Subject:   Re: Mourning of the passing of the ARPANET

Net 10 is a class A network number.  As we run out of network
numbers someone is going to need it, don't stick it in some
museum.  I'm sure that if anyone asked there would be lots
of volunteers who could turn in several class B network numbers...

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 16:42:25 GMT
From:      ogicse!plains!lodin@ucsd.edu  (Joe Schmo)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Duplicate Internet address on same network
The culprit has been determined to be a Sun 4 running both TCP/IP and DECnet.
The DECnet software for the Sun is Sunlink DNI.  Only Intergraph machines pick
up this address translation error, Suns and HPs don.  We haven't determined 
whether its a Sun problem or Intergraph problem.  No offense, but Intergraphs
are weird when it comes to TCP/IP.



Steven W. Lodin  
Advanced Instrumentation Engineering
Delco Electronics Corp

AT&T:    (317) 451-8722    GM: 8-322-8722
Domain:  lodin%koiasvr01.uucp@ee.ecn.purdue.edu
  or     lodin@plains.nodak.edu
  or     swlodin@koess.gm.hac.com
UUCP:    <backbone>!pur-ee!koiasvr01!lodin
GM:      LODIN, SW <KOESS::SWLODIN>
-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jun 90 21:14:04 EDT
From:      jbvb@vax.ftp.com  (James B. Van Bokkelen)
To:        van-bc!ubc-cs!kiwi!zaphod!kell@ucbvax.Berkeley.EDU  (Dave Kell)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP reliability
	Does SLIP have the same level of error detection and correction that
	ethernet-based IP has?

IP has header checksums, and they're the same wherever IP is run.
Likewise, the TCP checksum is mandatory.  UDP can optionally use the
same algorithm, but some vendors believe this costs too much speed,
so they omit them, regardless of the network media.  IP and UDP have no
"correction" in and of themselves, but TCP will do retransmits if the
checksum catches damage, or packets are lost altogether.

What Ethernet has that SLIP doesn't is a link-layer CRC-16, which can
do a pretty good job of detecting damage while on the cable.  SLIP
has no error detection at all at the link layer.  Of course, the
Ethernet CRC-16 may not detect packets damaged in the interface, or
in the host before transmission or after reception.  This sort of
undetected lower-layer damage happens much more often than the
optimistic crowd would like to believe, and is at the root of the
widely held belief that "end-to-end checksums are a Good Thing".

James B. VanBokkelen				FTP Software Inc.
jbvb@ftp.com					617-246-0900
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 18:32:29 GMT
From:      logicon.com!Makey@nosc.mil  (Jeff Makey)
To:        tcp-ip@nic.ddn.mil
Subject:   Security fix for anonymous uucp (was: anonymous ftp, and the dangers thereof)
In article <1990Jun8.134620.24070@cs.rochester.edu> bukys@cs.rochester.edu (Liudvikas Bukys) writes:
>1.  Here's one "minor problem" report: I have heard that .rhosts
>    files have been uucped into ~uucp.  Think about it.

I did think about it for a bit, and then I changed the following
/etc/passwd entry:

    uucp:*:66:1:UNIX-to-UNIX Copy:/usr/spool/uucppublic:

into:

    uucp:*:66:1:UNIX-to-UNIX Copy:/usr/spool/uucppublic:/dev/null
    UUCP:*:66:1:UNIX-to-UNIX Copy:/usr/spool/uucp:

(order is important to preserve "ls -l" output) and changed all
occurrences of "su uucp" in my crontab file into "su UUCP".  This
maintains "~uucp" as a public place to put files, but "su uucp" fails
with a "No shell" error.  Any programs that have a legitimate need to
run with the uucp user id can get to it through the "UUCP" login name,
whose home directory is *not* world-writable.

Sorry for putting this on TCP-IP, but that's where it started.
Followups are directed to alt.security.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: All opinions are strictly those of the author.
    Internet: Makey@Logicon.COM    UUCP: {nosc,ucsd}!logicon.com!Makey
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Jun 90 23:21:35 EDT
From:      Mark Bodenstein <MAB@CORNELLC.cit.cornell.edu>
To:        Joe Smith <usc!jarthur!bridge2!3comvax!tymix!tardis!jms@ucsd.edu>
Cc:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Ancient articles re-appearing.
On 7 Jun 90 06:25:23 GMT you said:
>This article showed up on my system.  Any idea who's machine is in a time warp?
I've noticed this too (and I believe John Shriver said he also did.)  Wierd.

Here are the headers from two appearances of a message - the first April 21,
the second June 5.  (Someone here happened to be saving tcp-ip mailing list
messages from this period.)

Mark Bodenstein   (mab@cornellc.cit.cornell.edu; 607-255-8059)
Cornell University

-----------First appearance of the message:---------------
Received: from CORNELLA by CORNELLA (Mailer R2.05X) with BSMTP id 0144; Sat, 21
 Apr 90 14:58:04 EDT
Received: from NIC.DDN.MIL by CORNELLA.cit.cornell.edu (IBM VM SMTP R1.2.1MX)
 with TCP; Sat, 21 Apr 90 14:58:01 EDT
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 21 Apr 90
 11:05:50 PDT
Received: by ucbvax.Berkeley.EDU (5.62/1.41)
        id AA07444; Sat, 21 Apr 90 10:57:57 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
        for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil)
        (contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 21 Apr 90 17:50:57 GMT
From: network.ucsd.edu!celit!hutch@ucsd.edu  (Jim Hutchison)
Organization: FPS Computing
Subject: Passwords in the kernel (was Re: anonymous ftp, and ...)
Message-Id: <8030@celit.fps.com>
References: <6703@blake.acs.washington.edu>, <1990Apr20.192233.4092@utzoo.uucp>,
 <6721@blake.acs.washington.edu>
Sender: tcp-ip-relay@nic.ddn.mil
To: tcp-ip@nic.ddn.mil

In article <6721@blake.acs.washington.edu>
        mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>No.  We aren't talking about hiding passwords in a secret file.  Any
 ... (body deleted)

----------------Second appearance of the message:------------------
Received: from CORNELLA by CORNELLA (Mailer R2.05X) with BSMTP id 1172; Tue, 05
 Jun 90 20:30:44 EDT
Received: from NIC.DDN.MIL by CORNELLA.cit.cornell.edu (IBM VM SMTP R1.2.1MX)
 with TCP; Tue, 05 Jun 90 20:30:24 EDT
Received: from ucbvax.Berkeley.EDU ([128.32.133.1]) by NIC.DDN.MIL with TCP;
 Mon, 4 Jun 90 12:53:02 PDT
Received: by ucbvax.Berkeley.EDU (5.63/1.41)
        id AA14464; Mon, 4 Jun 90 06:39:29 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
        for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil)
        (contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 3 Jun 90 08:10:10 GMT
From: network.ucsd.edu!celit!hutch@ucsd.edu  (Jim Hutchison)
Organization: FPS Computing
Subject: Passwords in the kernel (was Re: anonymous ftp, and ...)
Message-Id: <8030@celit.fps.com>
References: <6703@blake.acs.washington.edu>, <1990Apr20.192233.4092@utzoo.uucp>,
 <6721@blake.acs.washington.edu>
Sender: tcp-ip-relay@nic.ddn.mil
To: tcp-ip@nic.ddn.mil

In article <6721@blake.acs.washington.edu>
        mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>No.  We aren't talking about hiding passwords in a secret file.  Any
 ... (body deleted)
-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      12 Jun 90 21:14:19 GMT
From:      rja7m@HAGAR2.ACC.VIRGINIA.EDU (rja7m)
To:        comp.protocols.tcp-ip
Subject:   Re: How about comp.internet?

Let's try  comp.NET.internet instead since
it is a safe bet that other networks (e.g. BITNET/EARN)
might later also want such a group and it
is more flexible...

Ran
randall@virginia.edu

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 00:05:36 GMT
From:      netnews.upenn.edu!DCCS.UPENN.EDU!hagan@rutgers.edu  (John Dotts Hagan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP-IP Print Spooler
Does anyone have a version of Transcript that uses IP/TCP to open a connection
to a postscript device and then do the print thing?

The problem with most of the other mentioned methods is that they are one way
connections - that is, the connection is opened and data is dumped from the
host to the printer.  Some (maybe all) of them can deal with flow control by
not acking TCP frames, or such, but all the methods seem to not be able to read
data from the printer.

Postscript printers like to talk back (error messages, other stuff?) that lets
you know what is going on.

Anyone changed all the open's in the transcript package to be network
connections?

--Kid.
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 01:47:27 GMT
From:      bacchus.pa.dec.com!mogul@decwrl.dec.com  (Jeffrey Mogul)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Subnet Broadcasting
In article <9006121854.AA01650@rp.Wellfleet.Com> bstreile@wellfleet.com (Bill Streilein) writes:
>Mogul & Postel [RFC 950] specify that the subnet field must
>never be all 0's or all 1's.  Thus,
>
>       128.10.0.0  with a mask of 255.255.255.0 
>
>would be an invalid subnet.  Has the thought on this changed
>since this was proposed?  For instance, if all broadcasts are
>all 1's only, is a 'zero' subnet allowed? 

We recommended against "subnet number 0" because there is some
fear that certain software may use "0" internally to mean something
like "reserved" or "not yet set".  It seemed safer to ban the use
of this value for numbering a real subnet, to avoid any mysterious
bugs.

Also, I'm not sure everyone has stopped using all-zeros broadcasts.

In my experience, it is possible to get away with a subnet numbered
zero, but why tempt fate?

-Jeff
-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 03:21:35 GMT
From:      MAB@CORNELLC.CIT.CORNELL.EDU (Mark Bodenstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Ancient articles re-appearing.

On 7 Jun 90 06:25:23 GMT you said:
>This article showed up on my system.  Any idea who's machine is in a time warp?
I've noticed this too (and I believe John Shriver said he also did.)  Wierd.

Here are the headers from two appearances of a message - the first April 21,
the second June 5.  (Someone here happened to be saving tcp-ip mailing list
messages from this period.)

Mark Bodenstein   (mab@cornellc.cit.cornell.edu; 607-255-8059)
Cornell University

-----------First appearance of the message:---------------
Received: from CORNELLA by CORNELLA (Mailer R2.05X) with BSMTP id 0144; Sat, 21
 Apr 90 14:58:04 EDT
Received: from NIC.DDN.MIL by CORNELLA.cit.cornell.edu (IBM VM SMTP R1.2.1MX)
 with TCP; Sat, 21 Apr 90 14:58:01 EDT
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Sat, 21 Apr 90
 11:05:50 PDT
Received: by ucbvax.Berkeley.EDU (5.62/1.41)
        id AA07444; Sat, 21 Apr 90 10:57:57 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
        for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil)
        (contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 21 Apr 90 17:50:57 GMT
From: network.ucsd.edu!celit!hutch@ucsd.edu  (Jim Hutchison)
Organization: FPS Computing
Subject: Passwords in the kernel (was Re: anonymous ftp, and ...)
Message-Id: <8030@celit.fps.com>
References: <6703@blake.acs.washington.edu>, <1990Apr20.192233.4092@utzoo.uucp>,
 <6721@blake.acs.washington.edu>
Sender: tcp-ip-relay@nic.ddn.mil
To: tcp-ip@nic.ddn.mil

In article <6721@blake.acs.washington.edu>
        mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>No.  We aren't talking about hiding passwords in a secret file.  Any
 ... (body deleted)

----------------Second appearance of the message:------------------
Received: from CORNELLA by CORNELLA (Mailer R2.05X) with BSMTP id 1172; Tue, 05
 Jun 90 20:30:44 EDT
Received: from NIC.DDN.MIL by CORNELLA.cit.cornell.edu (IBM VM SMTP R1.2.1MX)
 with TCP; Tue, 05 Jun 90 20:30:24 EDT
Received: from ucbvax.Berkeley.EDU ([128.32.133.1]) by NIC.DDN.MIL with TCP;
 Mon, 4 Jun 90 12:53:02 PDT
Received: by ucbvax.Berkeley.EDU (5.63/1.41)
        id AA14464; Mon, 4 Jun 90 06:39:29 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
        for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil)
        (contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 3 Jun 90 08:10:10 GMT
From: network.ucsd.edu!celit!hutch@ucsd.edu  (Jim Hutchison)
Organization: FPS Computing
Subject: Passwords in the kernel (was Re: anonymous ftp, and ...)
Message-Id: <8030@celit.fps.com>
References: <6703@blake.acs.washington.edu>, <1990Apr20.192233.4092@utzoo.uucp>,
 <6721@blake.acs.washington.edu>
Sender: tcp-ip-relay@nic.ddn.mil
To: tcp-ip@nic.ddn.mil

In article <6721@blake.acs.washington.edu>
        mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>No.  We aren't talking about hiding passwords in a secret file.  Any
 ... (body deleted)

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 11:10:26 PDT (Wed)
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        rhott@rellay.nswc.navy.mil
Cc:        tcp-ip@nic.ddn.mil
Subject:   IP Addresses (Subnets)
The dotted-decimal notation (128.38.253.44) is just a direct
representation of the 32 bit IP address. It doesn't (necessarily)
break apart neatly into net, subnet and host numbers at dot
boundaries. So the 3rd octet field in the dot notation is equivalent
to the third octet in the 32 bit number.
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
"There is no loyalty except loyalty to the party. There is no love except love
of Big Brother. All competing pleasures we will destroy." - 1984 (film)
-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jun 90 11:24:55 PDT
From:      infmx!kwang@uunet.UU.NET (Kwang Sung)
To:        infmx!nsc!cs.UMD.EDU!pete@uunet.UU.NET, infmx!nsc!gateway.mitre.org!reichlen@uunet.UU.NET, infmx!nsc!ico.isc.com!dougm@uunet.UU.NET, mrose@CHEETAH.NYSER.NET, db@East.Sun.COM, dawei@Eng.Sun.COM, torben@FORALIE.ICS.HAWAII.EDU, richardt@Legato.COM, bob@MorningStar.Com, kzm@NMS.HLS.COM, Stef@NRTC.NORTHROP.COM, schoff@PSI.COM, louie@SAYSHELL.UMD.EDU, Allen_Rochkind@SPD.3Mail.3Com.COM, cperry@STARBASE.MITRE.ORG, galvin@TIS.COM, UCBCMSA!CLIFF@uunet.UU.NET, VitaM6!marciano@uunet.UU.NET, YAKOV@YKTVMX.BITNET, cmt@apollo.com, att!lzaz!jer@uunet.UU.NET, zopalka@bbn.com, mundy@beast.ddn.mil, callon@bigfut.enet.dec.com, dino@bridge2.ESD.3Com.COM, merritt@brl.mil, ggm@brolga.cc.uq.oz.au, goldstein@carafe.enet.dec.com, collins@ccc.mfecc.llnl.gov, haun@ccc.mfecc.llnl.gov, cire@cisco.com, grieve@cos.com, dab@cray.com, hagens@cs.wisc.edu, ietf-osi@cs.wisc.edu, merlin@csvax.seas.smu.edu, roki@dhafeu52.bitnet, curt@dtix.dt.navy.mil, david@elroy.Jpl.Nasa.Gov, keith@excelan.COM, gmalkin@ftp.com, dscott@gateway.mitre.org, epg@gateway.mitre.org, kit@gateway.mitre.org, patb@gateway.mitre.org, rick@gateway.mitre.org, saunders@gesundheit.West.Sun.Com, dennis@gpu.utcs.utoronto.ca, jsherida@ibm.com, yakov@ibm.com, infmx!kwang@uunet.UU.NET, karn@ka9q.bellcore.com, amanda@mermaid.intercon.com, jdr@mlb.semi.harris.com, netwrx1!graham@uunet.UU.NET, iso@nic.ddn.mil, isode@nic.ddn.mil, tcp-ip@nic.ddn.mil, nsc!amdahl!ames!harvard!talcott!wellflt!swillis@uunet.UU.NET, nsc!asylum.sf.ca.us!karl@uunet.UU.NET, nsc!wellfleet.com!bstreile@uunet.UU.NET, martin@protolaba.dca.mil, jessop@rlgvax.OPCR.ICL.COM, oberman@rogue.llnl.gov, mystie.rtp.dg.com!don%xyzzy@rti.rti.org, sparc2!ts@sacto.West.Sun.COM, lionel@salt.acc.com, laraqui@sics.se, harris@sparta.com, sun!bridge2!fjd@uunet.UU.NET, sun.soe.clarkson.e@uunet.UU.NET
du!nelson
    infmx!uunet!unx.dec.com!jjf infmx!uunet!uvcw.uvic.ca!eskovgaa infmx!uunet!voder!ucbvax!nrtc.northrop.com!Stef
    infmx!uunet!watcgl.waterloo.edu!aparghi infmx!uunet!watmath!ria.ccs.uwo.ca!csd.uwo.ca!mike
    infmx!uunet!wrs!yuba!hwajin



			

Dear Mr. Bob Sutterfield:


	Now I would like to finalize my proposal on creation of a new
newsgroup "comp.protocols.iso.migration".

	Here is a list of all persons who have responded to my postings 
so far as of 11:00 PST, June 13, 1990. They voted with a serious mind. 
I've collected the info to make a decision for all of us.

	Obviously, majority wanted to create such a newsgroup on USENET.
Among 54, 30 said "Yes", 17 said "No", and 7 were not clear.

	Since there are many companies who are interested in migration/
transition to OSI without having Internet connection, I proposed such a 
newsgroup on USENET. I hope we can have always close relationships with
already existing groups such as X3S3.3 (the ANSI group for network and
transport layers), IETF-OSI.

	This new newsgroup will discuss any technical or non-technical
issues on any protocols/strategies even besides TCP/IP which might be 
helpful to migrate/transit to OSI world.

	As I've mentioned earlier, I am sure this newsgroup will resolve
our networking future, and will give us a right direction to OSI. 

	So, could you create a new newsgroup "comp.protocols.iso.migration"
as soon as possible so that we can discuss seriously and aggressively,
and nobody can bother either "comp.protocols.iso" or "comp.protocols.tcp-ip"
any more ??

	Thank you for your help !!


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang


-------------------------------------------------------------------------------
Persons who have responded to my proposal so far:                    	Vote:
-------------------------------------------------------------------------------

uunet!YKTVMX.BITNET!YAKOV Tue Jun 12 08:15:38 1990			Yes
uunet!SPD.3Mail.3Com.COM!Allen_Rochkind					Yes
Amit Parghi <uunet!watcgl.waterloo.edu!aparghi>				No
bob@MorningStar.Com (Bob Sutterfield)					Yes
Bill Streilein <nsc!wellfleet.com!bstreile>				?
cire|eric <uunet!cisco.com!cire>					No
CLIFF@UCBCMSA (Cliff Frost {415} 642-5360)				?
cperry@STARBASE.MITRE.ORG (Chris Perry)					Yes
uunet!elroy.Jpl.Nasa.Gov!david (David Robinson)				?
uunet!Eng.Sun.COM!dawei (David Yang)					Yes
uunet!East.Sun.COM!db (David Brownell)					No
dennis@gpu.utcs.utoronto.ca (Dennis Ferguson)				?
Stef@NRTC.NORTHROP.COM (Einar Stefferud)				No
uunet!gateway.mitre.org!epg						Yes
Erik Skovgaard <uunet!uvcw.uvic.ca!eskovgaa>				Yes
James M Galvin <uunet!TIS.COM!galvin>					Yes
ggm@brolga.cc.uq.oz.au (George Michaelson)				No
goldstein@carafe.enet.dec.com (Fred R. Goldstein)			Yes
grieve@cos.com (David Grieve)						Yes
uunet!wrs!yuba!hwajin (Hwa Jin Bae)					No
att!lzaz!jer								Yes
uunet!rlgvax.OPCR.ICL.COM!jessop (Lynn Jessop)				?
uunet!unx.dec.com!jjf (John J. Franey)					Yes
nsc!asylum.sf.ca.us!karl (Karl Auerbach)				No
keith@excelan.COM (Keith Brown)						No
uunet!gateway.mitre.org!kit						Yes
uunet!infmx!kwang (Kwang Sung)						Yes
Hakiml Laraqui  <uunet!sics.se!laraqui>					?
louie@SAYSHELL.UMD.EDU (Louis A. Mamakos)				Yes
David Hayes <uunet!csvax.seas.smu.edu!merlin>				No
mrose@CHEETAH.NYSER.NET (Marshall Rose)					No
Russ Nelson <uunet!sun.soe.clarkson.edu!nelson>				No
oberman@rogue.llnl.gov							Yes
uunet!gateway.mitre.org!patb (Pat Blankenship)				Yes
karn@ka9q.bellcore.com (Phil Karn)					Yes
richardt@Legato.COM							Yes
saunders@gesundheit.West.Sun.Com (Gene Saunders)			Yes	
schoff@PSI.COM ("Martin Lee Schoffstall")				Yes	
Einar Stefferud <voder!ucbvax!nrtc.northrop.com!Stef>			Yes
Steven Willis <nsc!amdahl!ames!harvard!talcott!wellflt!swillis>	 	Yes	
torben@FORALIE.ICS.HAWAII.EDU (Torben Nielsen)				No
uunet!sacto.West.Sun.COM!sparc2!ts (Troy Schumaker)			Yes
amanda@mermaid.intercon.com (Amanda Walker)				No
curt@dtix.dt.navy.mil (Welch)						Yes
<uunet!bigfut.enet.dec.com!callon>					?
David Hayes <uunet!csvax.seas.smu.edu!merlin>				No
uunet!rti.rti.org!mystie.rtp.dg.com!don%xyzzy (Don Lehman)		No
"Doug McCallum" <nsc!ico.isc.com!dougm>                             	No
uunet!netwrx1!graham							Yes
uunet!mlb.semi.harris.com!jdr (Jim Ray)				 	No	
uunet!VitaM6!marciano (Marciano Pitargue)				Yes
JM Bennett <uunet!watmath!ria.ccs.uwo.ca!csd.uwo.ca!mike>		Yes
nsc!cs.UMD.EDU!pete (Pete Cottrell)					Yes
nsc!gateway.mitre.org!reichlen						Yes

-------------------------------------------------------------------------------
Disclaimer: Those opinions are mine alone, not my employers'.

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 04:29:04 GMT
From:      ficc!ihsan@uunet.uu.net  (jaleel ihsan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Please not yet again
In article <25880@netnews.upenn.edu>, farber@pcpond.cis.upenn.edu. (David J. Farber) writes:
> While I know it will not help to stop the religious wars, please take a peek at
> the report produced by the Board on telecommunications and Computer
> Applications of the National Research Council dated 1985 (work started
> in 1983) titled:
> 
> Transport Protocols for the DOD Data Networks -- report to the DoD and the NBS
> it compared TP/4 and TCP.
> 
> Dave

How can I get a copy, preferably electronic.

Jaleel
-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jun 90 12:21:59 PDT
From:      infmx!moose!kwang@uunet.UU.NET (Kwang Sung)
To:        infmx!nsc!cs.UMD.EDU!pete@uunet.UU.NET, infmx!nsc!gateway.mitre.org!reichlen@uunet.UU.NET, infmx!nsc!ico.isc.com!dougm@uunet.UU.NET, mrose@CHEETAH.NYSER.NET, db@East.Sun.COM, dawei@Eng.Sun.COM, torben@FORALIE.ICS.HAWAII.EDU, richardt@Legato.COM, bob@MorningStar.Com, kzm@NMS.HLS.COM, Stef@NRTC.NORTHROP.COM, schoff@PSI.COM, louie@SAYSHELL.UMD.EDU, Allen_Rochkind@SPD.3Mail.3Com.COM, cperry@STARBASE.MITRE.ORG, galvin@TIS.COM, UCBCMSA!CLIFF@uunet.UU.NET, VitaM6!marciano@uunet.UU.NET, YAKOV@YKTVMX.BITNET, cmt@apollo.com, att!lzaz!jer@uunet.UU.NET, zopalka@bbn.com, mundy@beast.ddn.mil, callon@bigfut.enet.dec.com, dino@bridge2.ESD.3Com.COM, merritt@brl.mil, ggm@brolga.cc.uq.oz.au, goldstein@carafe.enet.dec.com, collins@ccc.mfecc.llnl.gov, haun@ccc.mfecc.llnl.gov, cire@cisco.com, grieve@cos.com, dab@cray.com, hagens@cs.wisc.edu, ietf-osi@cs.wisc.edu, merlin@csvax.seas.smu.edu, roki@dhafeu52.bitnet, curt@dtix.dt.navy.mil, david@elroy.Jpl.Nasa.Gov, keith@excelan.COM, gmalkin@ftp.com, dscott@gateway.mitre.org, epg@gateway.mitre.org, kit@gateway.mitre.org, patb@gateway.mitre.org, rick@gateway.mitre.org, saunders@gesundheit.West.Sun.Com, dennis@gpu.utcs.utoronto.ca, jsherida@ibm.com, yakov@ibm.com, karn@ka9q.bellcore.com, amanda@mermaid.intercon.com, jdr@mlb.semi.harris.com, netwrx1!graham@uunet.UU.NET, iso@nic.ddn.mil, isode@nic.ddn.mil, tcp-ip@nic.ddn.mil, nsc!amdahl!ames!harvard!talcott!wellflt!swillis@uunet.UU.NET, nsc!asylum.sf.ca.us!karl@uunet.UU.NET, nsc!wellfleet.com!bstreile@uunet.UU.NET, martin@protolaba.dca.mil, jessop@rlgvax.OPCR.ICL.COM, oberman@rogue.llnl.gov, moose!in@uunet.UU.NET
fmx!uunet!rti.rti.org!mystie.rtp.dg.com!don%xyzzy,
        infmx!uunet!sacto.West.Sun.COM!sparc2!ts,
        infmx!uunet!salt.acc.com!lionel, infmx!uunet!sics.se!laraqui,
        infmx!uunet!sparta.com!harris, infmx!uunet!sun!bridge2!fjd,
        infmx!uunet!sun.soe.clarkson.edu!nelson, infmx!uunet!un

x.dec.com!jjf
    infmx!uunet!uvcw.uvic.ca!eskovgaa infmx!uunet!voder!ucbvax!nrtc.northrop.com!Stef
    infmx!uunet!watcgl.waterloo.edu!aparghi infmx!uunet!watmath!ria.ccs.uwo.ca!csd.uwo.ca!mike
    infmx!uunet!wrs!yuba!hwajin kwang



			

Dear Mr. Bob Sutterfield:


	Now I would like to finalize my proposal on creation of a new
newsgroup "comp.protocols.iso.migration".

	Here is a list of all persons who have responded to my postings 
so far as of 11:00 PST, June 13, 1990. They voted with a serious mind. 
I've collected the info to make a decision for all of us.

	Obviously, majority wanted to create such a newsgroup on USENET.
Among 54, 30 said "Yes", 17 said "No", and 7 were not clear.

	Since there are many companies who are interested in migration/
transition to OSI without having Internet connection, I proposed such a 
newsgroup on USENET. I hope we can have always close relationships with
already existing groups such as X3S3.3 (the ANSI group for network and
transport layers), IETF-OSI.

	This new newsgroup will discuss any technical or non-technical
issues on any protocols/strategies even besides TCP/IP which might be 
helpful to migrate/transit to OSI world.

	As I've mentioned earlier, I am sure this newsgroup will resolve
our networking future, and will give us a right direction to OSI. 

	So, could you create a new newsgroup "comp.protocols.iso.migration"
as soon as possible so that we can discuss seriously and aggressively,
and nobody can bother either "comp.protocols.iso" or "comp.protocols.tcp-ip"
any more ??

	Thank you for your help !!


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang


-------------------------------------------------------------------------------
Persons who have responded to my proposal so far:                    	Vote:
-------------------------------------------------------------------------------

uunet!YKTVMX.BITNET!YAKOV Tue Jun 12 08:15:38 1990			Yes
uunet!SPD.3Mail.3Com.COM!Allen_Rochkind					Yes
Amit Parghi <uunet!watcgl.waterloo.edu!aparghi>				No
bob@MorningStar.Com (Bob Sutterfield)					Yes
Bill Streilein <nsc!wellfleet.com!bstreile>				?
cire|eric <uunet!cisco.com!cire>					No
CLIFF@UCBCMSA (Cliff Frost {415} 642-5360)				?
cperry@STARBASE.MITRE.ORG (Chris Perry)					Yes
uunet!elroy.Jpl.Nasa.Gov!david (David Robinson)				?
uunet!Eng.Sun.COM!dawei (David Yang)					Yes
uunet!East.Sun.COM!db (David Brownell)					No
dennis@gpu.utcs.utoronto.ca (Dennis Ferguson)				?
Stef@NRTC.NORTHROP.COM (Einar Stefferud)				No
uunet!gateway.mitre.org!epg						Yes
Erik Skovgaard <uunet!uvcw.uvic.ca!eskovgaa>				Yes
James M Galvin <uunet!TIS.COM!galvin>					Yes
ggm@brolga.cc.uq.oz.au (George Michaelson)				No
goldstein@carafe.enet.dec.com (Fred R. Goldstein)			Yes
grieve@cos.com (David Grieve)						Yes
uunet!wrs!yuba!hwajin (Hwa Jin Bae)					No
att!lzaz!jer								Yes
uunet!rlgvax.OPCR.ICL.COM!jessop (Lynn Jessop)				?
uunet!unx.dec.com!jjf (John J. Franey)					Yes
nsc!asylum.sf.ca.us!karl (Karl Auerbach)				No
keith@excelan.COM (Keith Brown)						No
uunet!gateway.mitre.org!kit						Yes
uunet!infmx!kwang (Kwang Sung)						Yes
Hakiml Laraqui  <uunet!sics.se!laraqui>					?
louie@SAYSHELL.UMD.EDU (Louis A. Mamakos)				Yes
David Hayes <uunet!csvax.seas.smu.edu!merlin>				No
mrose@CHEETAH.NYSER.NET (Marshall Rose)					No
Russ Nelson <uunet!sun.soe.clarkson.edu!nelson>				No
oberman@rogue.llnl.gov							Yes
uunet!gateway.mitre.org!patb (Pat Blankenship)				Yes
karn@ka9q.bellcore.com (Phil Karn)					Yes
richardt@Legato.COM							Yes
saunders@gesundheit.West.Sun.Com (Gene Saunders)			Yes	
schoff@PSI.COM ("Martin Lee Schoffstall")				Yes	
Einar Stefferud <voder!ucbvax!nrtc.northrop.com!Stef>			Yes
Steven Willis <nsc!amdahl!ames!harvard!talcott!wellflt!swillis>	 	Yes	
torben@FORALIE.ICS.HAWAII.EDU (Torben Nielsen)				No
uunet!sacto.West.Sun.COM!sparc2!ts (Troy Schumaker)			Yes
amanda@mermaid.intercon.com (Amanda Walker)				No
curt@dtix.dt.navy.mil (Welch)						Yes
<uunet!bigfut.enet.dec.com!callon>					?
David Hayes <uunet!csvax.seas.smu.edu!merlin>				No
uunet!rti.rti.org!mystie.rtp.dg.com!don%xyzzy (Don Lehman)		No
"Doug McCallum" <nsc!ico.isc.com!dougm>                             	No
uunet!netwrx1!graham							Yes
uunet!mlb.semi.harris.com!jdr (Jim Ray)				 	No	
uunet!VitaM6!marciano (Marciano Pitargue)				Yes
JM Bennett <uunet!watmath!ria.ccs.uwo.ca!csd.uwo.ca!mike>		Yes
nsc!cs.UMD.EDU!pete (Pete Cottrell)					Yes
nsc!gateway.mitre.org!reichlen						Yes

-------------------------------------------------------------------------------
Disclaimer: Those opinions are mine alone, not my employers'.

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jun 90 10:02:33 EDT
From:      "Don Garner (CADIG STAFF) " <don@usna.navy.MIL>
To:        mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
Cc:        snorkelwacker!bu.edu!bu-it!kwe@tut.cis.ohio-state.edu, tcp-ip@NIC.DDN.MIL
Subject:   Re:  Mourning of the passing of the ARPANET

Are there no comments on what it means to lose ARPANET?
-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jun 90 10:50:06 EDT
From:      Jack Haverty <haverty@BBN.COM>
To:        CSYSMAS@oac.ucla.edu
Cc:        haverty@BBN.COM, tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
Perhaps instead of retiring #10 to a museum, we could have a ceremony
at Interop where the number is officially "retired", and a banner hoisted
to the ceiling - anybody volunteer to make a banner out of fishnet?
Then net 10 could be assigned to be used to create a bunch of class B
numbers for aspiring neonetworks who want to follow in the Arpanet's
footsteps (yes I know that's technically difficult).

Jack

Dan Lynch - are you listening....
-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jun 90 15:28:32 -0400
From:      "Louis A. Mamakos" <louie@sayshell.umd.edu>
To:        infmx!kwang@uunet.uu.net (Kwang Sung)
Cc:        infmx!nsc!cs.UMD.EDU!pete@uunet.uu.net, infmx!nsc!gateway.mitre.org!reichlen@uunet.uu.net, infmx!nsc!ico.isc.com!dougm@uunet.uu.net, mrose@cheetah.nyser.net, db@east.sun.com, dawei@eng.sun.com, torben@foralie.ics.hawaii.edu, richardt@legato.com, bob@morningstar.com, kzm@nms.hls.com, Stef@nrtc.northrop.com, schoff@psi.com, Allen_Rochkind@spd.3mail.3com.com, cperry@starbase.mitre.org, galvin@tis.com, UCBCMSA!CLIFF@uunet.uu.net, VitaM6!marciano@uunet.uu.net, YAKOV@yktvmx.bitnet, cmt@apollo.com, att!lzaz!jer@uunet.uu.net, zopalka@bbn.com, mundy@beast.ddn.mil, callon@bigfut.enet.dec.com, dino@bridge2.esd.3com.com, merritt@brl.mil, ggm@brolga.cc.uq.oz.au, goldstein@carafe.enet.dec.com, collins@ccc.mfecc.llnl.gov, haun@ccc.mfecc.llnl.gov, cire@cisco.com, grieve@cos.com, dab@cray.com, hagens@cs.wisc.edu, ietf-osi@cs.wisc.edu, merlin@csvax.seas.smu.edu, curt@dtix.dt.navy.mil, david@elroy.jpl.nasa.gov, keith@excelan.com, gmalkin@ftp.com, dscott@gateway.mitre.org, epg@gateway.mitre.org, kit@gateway.mitre.org, patb@gateway.mitre.org, rick@gateway.mitre.org, saunders@gesundheit.west.sun.com, dennis@gpu.utcs.utoronto.ca, jsherida@ibm.com, yakov@ibm.com, karn@ka9q.bellcore.com, amanda@mermaid.intercon.com, jdr@mlb.semi.harris.com, netwrx1!graham@uunet.uu.net, iso@nic.ddn.mil, isode@nic.ddn.mil, tcp-ip@nic.ddn.mil, nsc!amdahl!ames!harvard!talcott!wellflt!swillis@uunet.uu.net, nsc!asylum.sf.ca.us!karl@uunet.uu.net, nsc!wellfleet.com!bstreile@uunet.uu.net, martin@protolaba.dca.mil, jessop@rlgvax.opcr.icl.com, oberman@rogue.llnl.gov, mystie.rtp.dg.com!don%xyzzy@rti.rti.org, sparc2!ts@sacto.west.sun.com, lionel@salt.acc.com, laraqui@sics.se, harris@sparta.com, sun!bridge2!fjd@uunet.uu.net, sun.soe.clarkson.e@uunet.uu.net
You seem to be confused.

When someone mentioned setting up a mailing list, they meant a discussion
group to talk about the topic you proposed.  It certainly does not mean a
list of people who happened to be fool enough to comment on your posting
in comp.protocols.tcpip.

This is not how a new newsgroup is created.  You should probably post a
note in news.group, and I'm sure someone will tell you what the proper 
procedure is.  Usually an announcement is made, discussion follows, and then
a call for votes is taken.  These votes are usually collected by some 
neutral party.  There's a good reason for that; for example you thought that
I was somehow in favor of such a newsgroup; I am NOT.

There are rules which determine what a "passing" vote for a newsgroup are.  I
believe that you need 100 more "YES" votes than "NO" votes.  I'm probably
wrong or mistaken.  If you really want to pursue this folly, I suggest that
you do it in the correct forum, which is most definately NOT the comp.protocols.
tcpip newsgroup/TCP-IP@NIC.DDN.MIL mailing list. 

Again, for the record, I'm against a newsgroup.  Existing newsgroup should be
used to discuss this sort of thing unless the traffic is too heavy to bear or
wanders from the scope of the newsgroup.

louie
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jun 90 13:41:45 EDT
From:      Frank Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET>
To:        sdd.hp.com!uakari.primate.wisc.edu!ark1!volleydog!rhott@UCSD.EDU, tcp-ip@NIC.DDN.MIL
Subject:   Re:  IP Addresses (Subnets)
 > From tcp-ip-RELAY@NIC.DDN.MIL Wed Jun 13 13:08:44 1990
 > From: sdd.hp.com!uakari.primate.wisc.edu!ark1!volleydog!rhott@ucsd.edu  (The VolleyDog)
 > Organization: Naval Surface Warfare Center, Dahlgren VA
 > Subject: IP Addresses (Subnets)
 > Sender: tcp-ip-relay@nic.ddn.mil
 > To: tcp-ip@nic.ddn.mil
 > 
 > I have a quick question, hopefully you will not flame to loudly with
 > regard to  viewing RFCs.  I looked through RFC 950 to try to determine
 > how to specify a host when using a subnet.  In my particular instance we
 > have a class B network.  I am interested in how one would specify
 > addresses when a subnet of 6 bits is used.
 > 
 > Suppose I want the 300th host on the 1 subnet of a class B network with
 > a netmask of 255.255.252!  Should I specify the IP address as
 > 128.38.1.300 or 128.38.253.44
 > 
 > I guess my overall question is:  Should I specify the addressing using
 > the 3rd octet field in the dot notation as the subnet or as the 3rd
 > octet of the 32 bit field? 
Bob:

From RFC 1117 (Internet Numbers):
	
   One commonly used notation for internet host addresses divides the
   32-bit address into four 8-bit fields and specifies the value of each
   field as a decimal number with the fields separated by periods.  This
   is called the "dotted decimal" notation.  For example, the internet
   address of VENERA.ISI.EDU in dotted decimal is 010.001.000.052, or
   10.1.0.52.

So, the correct number is 128.38.253.44.

This is not an "official standard" but it is common usage to the degree that
no one does anything different.

Frank Kastenholz
Racal Interlan

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Jun 90 13:48:47 EDT
From:      Doug Nelson <08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu>
To:        The VolleyDog, <sdd.hp.com!uakari.primate.wisc.edu!ark1!volleydog!rhott@ucsd.edu>, "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>
Subject:   Re: IP Addresses (Subnets)
>I have a quick question, hopefully you will not flame to loudly with
>regard to  viewing RFCs.  I looked through RFC 950 to try to determine
>how to specify a host when using a subnet.  In my particular instance we
>have a class B network.  I am interested in how one would specify
>addresses when a subnet of 6 bits is used.
>
>Suppose I want the 300th host on the 1 subnet of a class B network with
>a netmask of 255.255.252!  Should I specify the IP address as
>128.38.1.300 or 128.38.253.44
>
>I guess my overall question is:  Should I specify the addressing using
>the 3rd octet field in the dot notation as the subnet or as the 3rd
>octet of the 32 bit field?

The best answer is "none of the above".  If your netmask is 255.255.252.0,
and you are on the first subnet of network 128.38, then your address range
begins with 128.38.0.0, and ends with 128.38.3.255 (the latter being your
subnet broadcast address).  So, if your first host was numbered 128.38.1.1,
then your 300th host would be 128.38.2.44.

Doug Nelson
Network Software Manager
Michigan State University
-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 14:48:55 GMT
From:      shlump.nac.dec.com!carafe.enet.dec.com!goldstein@decwrl.dec.com  (Fred R. Goldstein)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP reliability

In article <9006130114.AA05996@vax.ftp.com>, jbvb@VAX.FTP.COM (James B. Van Bokkelen) writes...
>What Ethernet has that SLIP doesn't is a link-layer CRC-16, which can
>do a pretty good job of detecting damage while on the cable.  SLIP
>has no error detection at all at the link layer.  Of course, the
>Ethernet CRC-16 may not detect packets damaged in the interface, or
>in the host before transmission or after reception.  

Slight correction.  Ethernet, like 802.{3,4,5}, has a 32-bit CRC, not a 
16-bit CRC.  (BTW, "CRC-16" is the name of the bisync/DDCMP 16-bit 
checksum; "CRC-CCITT" is the 16-bit HDLC checksum.  CRC-32 is the 
LAN checksum, also optional in HDLC, and historically developed for 
Autodin-II.)

The 32-bit Ethernet checksum maintains a Hamming distance of 4 up to the 
maximum Ethernet packet, or for that matter up to about 12K bytes.  Thus 
ANY 3 bit errors will be caught, or any one error of under 32 bits.
A 16-bit CRC maintains a Hamming distance of 3 up to 4K bytes.  Exceed
that error limit and you're subject to a "crap shoot" of 2**n for n bits 
of CRC.  With 32 bits, that's a very low probability of undetected error 
no matter how you slice it.

The TCP and IP checksums are straight arithmetic.  Frog two 16-bit words 
and you've got an undetected error.  The right two-bit error combo will
be undetected.  It's a whole lot better than nothing, but not as good as 
the Fletcher checksum and that's not as good as the more computationally 
intensive CRC (which is usually done in hardware).

SLIP, with no checking whatsoever, is a bad joke.  PPP uses CRC-CCITT,
which is pretty good (for reasonable MTUs).  Ethernet is close to 
bulletproof, with regard to line noise induced error.  (Host error is, 
as the man said, another story.  TCP's checksum is mainly there to 
detect it.)
---
Fred R. Goldstein   goldstein@carafe.enet.dec.com 
                 or goldstein@delni.enet.dec.com
                    voice:  +1 508 486 7388 
opinions are mine along; sharing requires permission
-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 14:50:06 GMT
From:      haverty@BBN.COM (Jack Haverty)
To:        comp.protocols.tcp-ip
Subject:   Re: Mourning of the passing of the ARPANET

Perhaps instead of retiring #10 to a museum, we could have a ceremony
at Interop where the number is officially "retired", and a banner hoisted
to the ceiling - anybody volunteer to make a banner out of fishnet?
Then net 10 could be assigned to be used to create a bunch of class B
numbers for aspiring neonetworks who want to follow in the Arpanet's
footsteps (yes I know that's technically difficult).

Jack

Dan Lynch - are you listening....

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 14:51:53 GMT
From:      sdd.hp.com!uakari.primate.wisc.edu!ark1!volleydog!rhott@ucsd.edu  (The VolleyDog)
To:        tcp-ip@nic.ddn.mil
Subject:   IP Addresses (Subnets)
I have a quick question, hopefully you will not flame to loudly with
regard to  viewing RFCs.  I looked through RFC 950 to try to determine
how to specify a host when using a subnet.  In my particular instance we
have a class B network.  I am interested in how one would specify
addresses when a subnet of 6 bits is used.

Suppose I want the 300th host on the 1 subnet of a class B network with
a netmask of 255.255.252!  Should I specify the IP address as
128.38.1.300 or 128.38.253.44

I guess my overall question is:  Should I specify the addressing using
the 3rd octet field in the dot notation as the subnet or as the 3rd
octet of the 32 bit field? 

Thanks,
  Bob Hott


=============================================================================

Fullname:         Robert W. (Bob) Hott
Mailing Address:  Naval Surface Warfare Center
                  Networks Branch (Code E41)
                  Dahlgren, Virginia  22448
DDN Mail:         rhott@relay.nswc.navy.mil
DDN Mail:         rhott@volleydog.nswc.navy.mil
Telephone:        (703) 663 - 7745

"If man were not meant to play volleyball, why are there so many beaches?"
	 - Bob Hott -
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 18:14:32 GMT
From:      voder!pyramid!infmx!kwang@ucbvax.Berkeley.EDU  (Kwang Sung)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Vote for/against "comp.protocols.iso.migration"

Dear Mr. Bob Sutterfield:


	Now I would like to finalize my proposal on creation of a new
newsgroup "comp.protocols.iso.migration".

	Here is a list of all persons who have responded to my postings 
so far as of 11:00 PST, June 13, 1990. They voted with a serious mind. 
I've collected the info to make a decision for all of us.

	Obviously, majority wanted to create such a newsgroup on USENET.
Among 54, 30 said "Yes", 17 said "No", and 7 were not clear.

	Since there are many companies who are interested in migration/
transition to OSI without having Internet connection, I proposed such a 
newsgroup on USENET. I hope we can have always close relationships with
already existing groups such as X3S3.3 (the ANSI group for network and
transport layers), IETF-OSI.

	This new newsgroup will discuss any technical or non-technical
issues on any protocols/strategies even besides TCP/IP which might be 
helpful to migrate/transit to OSI world.

	As I've mentioned earlier, I am sure this newsgroup will resolve
our networking future, and will give us a right direction to OSI. 

	So, could you create a new newsgroup "comp.protocols.iso.migration"
as soon as possible so that we can discuss seriously and aggressively,
and nobody can bother either "comp.protocols.iso" or "comp.protocols.tcp-ip"
any more ??

	Thank you for your help !!


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang


-------------------------------------------------------------------------------
Persons who have responded to my proposal so far:                    	Vote:
-------------------------------------------------------------------------------

uunet!YKTVMX.BITNET!YAKOV Tue Jun 12 08:15:38 1990			Yes
uunet!SPD.3Mail.3Com.COM!Allen_Rochkind					Yes
Amit Parghi <uunet!watcgl.waterloo.edu!aparghi>				No
bob@MorningStar.Com (Bob Sutterfield)					Yes
Bill Streilein <nsc!wellfleet.com!bstreile>				?
cire|eric <uunet!cisco.com!cire>					No
CLIFF@UCBCMSA (Cliff Frost {415} 642-5360)				?
cperry@STARBASE.MITRE.ORG (Chris Perry)					Yes
uunet!elroy.Jpl.Nasa.Gov!david (David Robinson)				?
uunet!Eng.Sun.COM!dawei (David Yang)					Yes
uunet!East.Sun.COM!db (David Brownell)					No
dennis@gpu.utcs.utoronto.ca (Dennis Ferguson)				?
Stef@NRTC.NORTHROP.COM (Einar Stefferud)				No
uunet!gateway.mitre.org!epg						Yes
Erik Skovgaard <uunet!uvcw.uvic.ca!eskovgaa>				Yes
James M Galvin <uunet!TIS.COM!galvin>					Yes
ggm@brolga.cc.uq.oz.au (George Michaelson)				No
goldstein@carafe.enet.dec.com (Fred R. Goldstein)			Yes
grieve@cos.com (David Grieve)						Yes
uunet!wrs!yuba!hwajin (Hwa Jin Bae)					No
att!lzaz!jer								Yes
uunet!rlgvax.OPCR.ICL.COM!jessop (Lynn Jessop)				?
uunet!unx.dec.com!jjf (John J. Franey)					Yes
nsc!asylum.sf.ca.us!karl (Karl Auerbach)				No
keith@excelan.COM (Keith Brown)						No
uunet!gateway.mitre.org!kit						Yes
uunet!infmx!kwang (Kwang Sung)						Yes
Hakiml Laraqui  <uunet!sics.se!laraqui>					?
louie@SAYSHELL.UMD.EDU (Louis A. Mamakos)				Yes
David Hayes <uunet!csvax.seas.smu.edu!merlin>				No
mrose@CHEETAH.NYSER.NET (Marshall Rose)					No
Russ Nelson <uunet!sun.soe.clarkson.edu!nelson>				No
oberman@rogue.llnl.gov							Yes
uunet!gateway.mitre.org!patb (Pat Blankenship)				Yes
karn@ka9q.bellcore.com (Phil Karn)					Yes
richardt@Legato.COM							Yes
saunders@gesundheit.West.Sun.Com (Gene Saunders)			Yes	
schoff@PSI.COM ("Martin Lee Schoffstall")				Yes	
Einar Stefferud <voder!ucbvax!nrtc.northrop.com!Stef>			Yes
Steven Willis <nsc!amdahl!ames!harvard!talcott!wellflt!swillis>	 	Yes	
torben@FORALIE.ICS.HAWAII.EDU (Torben Nielsen)				No
uunet!sacto.West.Sun.COM!sparc2!ts (Troy Schumaker)			Yes
amanda@mermaid.intercon.com (Amanda Walker)				No
curt@dtix.dt.navy.mil (Welch)						Yes
<uunet!bigfut.enet.dec.com!callon>					?
David Hayes <uunet!csvax.seas.smu.edu!merlin>				No
uunet!rti.rti.org!mystie.rtp.dg.com!don%xyzzy (Don Lehman)		No
"Doug McCallum" <nsc!ico.isc.com!dougm>                             	No
uunet!netwrx1!graham							Yes
uunet!mlb.semi.harris.com!jdr (Jim Ray)				 	No	
uunet!VitaM6!marciano (Marciano Pitargue)				Yes
JM Bennett <uunet!watmath!ria.ccs.uwo.ca!csd.uwo.ca!mike>		Yes
nsc!cs.UMD.EDU!pete (Pete Cottrell)					Yes
nsc!gateway.mitre.org!reichlen						Yes

-------------------------------------------------------------------------------
Disclaimer: Those opinions are mine alone, not my employers'.
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 18:15:36 GMT
From:      hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU  (Rick Jones)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCPtrace port to HP

>I have a colleague who needs to know the effort required to
>port TCPtrace to an HP 3000.  I don't know if there's some
>...
>	Walt Lazear
>	lazear@gateway.mitre.org
>----------

Did you say 3000 ??? Or did you really mean 9000? The 3000 runs one of
two versions of the MPE OS (MPE/V for the 'classic' h/w and MPE/XL for
the 'spectrum' (new whizzy risc ;-) h/w. It's TCP/IP is an in-house
implementation that does not look at all like standard BSD TCP/IP. It
also uses NetIPC and not BSD sockets, so the interface to the
transport layer is not the same... It's the 9000 that runs the BSD
bits... 

rick jones

___   _  ___
|__) /_\  |    Richard Anders Jones   | MPE/XL Networking Engineer
| \_/   \_/    Hewlett-Packard  Co.   | (;place deprication here;)
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply
-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 18:26:15 GMT
From:      bunny!jdg0@husc6.harvard.edu  (Jose Diaz-Gonzalez)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP reliability
In article <12435@shlump.nac.dec.com> goldstein@carafe.enet.dec.com (Fred R. Goldstein) writes:
>
>SLIP, with no checking whatsoever, is a bad joke.  PPP uses CRC-CCITT,
>which is pretty good (for reasonable MTUs).  Ethernet is close to 

Could some one explain what PPP is, or where can I find more info about
it?  Thanks.

	-- Jose


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+				     +					+
+	Jose Pedro Diaz-Gonzalez     +		                    	+
+	SrMTS			     +					+
+	GTE Laboratories, Inc.       +	   Tel:   (617) 466-2584	+
+	MS-46                 	     +	   email: jdiaz@gte.com    	+
+	40 Sylvan Rd.		     +					+
+	Waltham, MA 02254	     +					+
+				     +					+
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 18:29:26 GMT
From:      ssc-vax!voodoo!howie@beaver.cs.washington.edu  (howie)
To:        tcp-ip@nic.ddn.mil
Subject:   Question About Gateway Machines

Here's something that I've wondered about:

How does a gateway machine know which ethernet connection to use?


I understand there could be times that you would want to broadcast through 
both ethernet connections.  But aren't there times you just want to send
data out of one connection, leaving the other one alone?  

Where can I find documentation on this?  Most of anything I've read, deals 
with single-homed systems.

					
				      thanks,

-- 
				       howie              

				       uw-beaver!ssc-vax!voodoo!howie 
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 18:58:00 GMT
From:      escher@Apple.COM (Michael Crawford)
To:        comp.protocols.tcp-ip
Subject:   Re:  Growing sentiment against gateways


In article <25174@usc.edu> kmeyer@pollus.usc.edu writes:
>
>Most, if not all, of the regional networks attached to the NSFnet backbone
>have appropriate usage guidelines.  Traffic which is solely for commercial
>purposes is prohibited from traversing the NSFNet backbone--there are most
>definitely rules which govern Internet access.  However, in the case of

I am curious how a commercial UUCP site would post to misc.jobs.offered,
and guarantee that their ad did not traverse the backbone.  Suppose
their upstream site was on UUCP, and so on for a few hops, and all these
commercial companies provide each other UUCP for commercial purposes.

It seems to me that it is absurd for a company to have to consider what
political requirements a distant network layer might have when posting
to the news.

Or consider this: suppose a company has a network that links itself and
its clients.  Suppose the company and the client each have an internet
connection, but the shortest-hop is to go over the internal network.

It is perfectly legitimate in this case that the company should bill its
client via SMTP mail.

Suppose the regional or the NSF backbone now installed a router that made the
hop count from accounts receivable to the client's account payable office
shorter than the hop count on the internal network.  Current protocols
will shortly send all the bills over the NSF backbone.

I am not advocating that the NSF or the regionals should provide free
communications services to companies, but really, there should be some
realistic thought on this.

Perhaps one could set a bit in the IP header that says this packet is
not "Used Appropriately", and NSF routers could drop such packets.  (Just
kidding).  What would be more reasonable is for the companies to pay
for the usage they actually incur on the net, in some manner that is
simple and manageable.

-- 
Michael D. Crawford
Oddball Enterprises		Consulting for Apple Computer Inc.
606 Modesto Avenue		escher@apple.com
Santa Cruz, CA 95060		Applelink: escher@apple.com@INTERNET#
oddball!mike@ucscc.ucsc.edu	The opinions expressed here are solely my own.

		alias make '/bin/make & rn'

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 19:05:43 GMT
From:      usc!zaphod.mps.ohio-state.edu!rpi!uupsi!ccavax!tinkelman@ucsd.edu
To:        tcp-ip@nic.ddn.mil
Subject:   <None>
In article <12369@shlump.nac.dec.com>, goldstein@carafe.enet.dec.com (Fred R.
Goldstein) writes a bit about DECnet/OSI  Phase V in response to a previous
posting from John Franey (also of Digital)

Franey> DEC has commited itself to OSI.  All of its customers computer 
Franey> network nodes are going to be converted to OSI with the release of 
Franey> DECnet Phase V.  I work for DEC but not in communications engineering 
Franey> but please don't think this is a plug.  
 
Goldstein> While I'm not a spokesman, I do work for DEC in communications 
Goldstein> engineering.  We have certainly taken a leading role in OSI.  But 
Goldstein> we are also building TCP/IP.  And while Phase V is OSI up to Layer 
Goldstein> 3 it supports OSI and non-OSI in parallel using a "towers" approach. 
Goldstein> Most DEC-DEC applications won't use the OSI upper layers.  Note that
Goldstein> it's the upper layers of OSI that are most controversial.

DEC is making a significant change in direction, or at least agreeing to the
option of using a fairly length detour.  

DEC made a number of announcements at the New Orleans DECUS Symposium (early
May) that indicated that TCP/IP will play a very strong role in Phase V.  
As a starter, _all_ of the DECnet Phase V routers will be multiprotocol
routers, supporting DECnet Phase IV, OSI (DECnet Phase V) *and* IP.  

Given the Phase V architectural support for protocol towers in the DNS, I
would expect (hope for?) support of towers based on a TCP/IP stack.  Fred, 
is that what will happen?
-- 
Bob Tinkelman, Cambridge Computer Associates, Inc., 212-425-5830              
bob@camb.com  or ...!{uupsi,uunet}!camb.com!bob      
-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 21:07:54 GMT
From:      accur8!levinson@uunet.uu.net  (Edward Levinson)
To:        tcp-ip@nic.ddn.mil
Subject:   WIN/OSI phases
In UNIX Today!, June 11, 1990, on pg. 38 an article entitled "Net Tools
Ease Move From TCP/IP To OSI" appears about The Wollongong Group's OSI
product, WIN/OSI.

The following statement sounded strange to me.  Can anyone shed some
light on what Wollongong really means.

	"Wollongong recommends a four-part strategy for migration to
	OSI, starting with modifications to lower-level TCP/IP
	communications.  Phase 2 allows OSI applications to run over
	TCP/IP lower-level protocols.  Phase 3 introduces the TSB
	gateway from TCP/IP to OSI.  And, finally, full OSI compliance
	occurs in Phase 4."

Except for Phase 1 this sounds like ISODE.  Is this really a
productized ISODE?  What does the first phase mean?  (Could it be
adding RFC1066 code?)  Earlier in the story a "mixed stack" is
referred to, again implying ISODE.

The next paragraph is stranger.  It says that there is a SNMP agent
that "allows OSI devices to access Internet SNMP stations."  This
suggests to me that TWG has an SNMP agent on top of an OSI stack.  At
$200 sounds too good to be true.   Can anyone shed some light here?

Mostly it sounds like a garbled press release.  Garbled when it got
close to the real technical issues.

Thanks.../Ed

Edward Levinson                         Disclaimer:  The opinions expressed
levinson%accur8.uucp@uunet.uu.net       here are my own and not that of
                                        Accurate Information Systems Inc.

Accurate Information Systems Inc.
3000 Hadley Road
South Plainfield, NJ  07080
(201) 754-7714
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 21:34:00 GMT
From:      zaphod.mps.ohio-state.edu!mips!ultra!shj@tut.cis.ohio-state.edu  (Steve Jay)
To:        tcp-ip@nic.ddn.mil
Subject:   Multi-homed hosts and parallel networks
Fast networks (FDDI or UltraNet) are being installed in parallel with
existing ethernet networks.  Hosts are becoming multi-homed (more than
one IP address) for reasons other than IP routing.  Have there been any
discussions on how IP can cope with multi-homed hosts and (semi-)parallel
networks, such that traffic automatically takes the "best" path between
hosts?

Consider the following combination of networks and hosts.  Network 1 is
ethernet, Network 2 is something much faster.  Hosts B and C are connected
to both networks, host A is on network 1 only, and host D is on 2 only.

                         1                        2

        +-------+        |                        |
	|       |	 |                        |
	|   A   +--------+                        |
	|       |	 |       +------+         |
        +-------+        |       |      |         |
			 +-------+  B   +---------+
			 |       |      |         |
                         |       +------+         |
	         	 |       +------+         |
                         |       |      |         |
			 +-------+  C   +---------+
			 |       |      |         |        +------+
                         |       +------+         |        |      |
			 |                        +--------+   D  |
                         |                        |        |      |
			 |                        |        +------+


How can it be arranged so that IP traffic between any two hosts travels
over the "best" path?

I put "best" in quotes for a reason.  It may be considered better to have
some traffic between B & C go over the ethernet rather than the faster
network.  You may not want to clog up the fast network with the tiny
packets generated by rlogin, but ftp data connections should be on the
fast network.

One of the reasons that this isn't easy is that names and IP addresses
refer to specific interfaces, not hosts.  In the above configuration,
host A has one interface (call it A-1), host B whas B-1 and B-2, host C
has C-1 and C-2, and host D has D-2.  Normally, in this situation, the
system administrator would alias the name B to B-1 or B-2 in /etc/hosts
(or equivalent). This leads to very inefficient routing.  If B is aliased
to B-2, then IP traffic between A and B could end up routing through host
C, rather than using the direct A-1 <-> B-1 path.  If B is aliased to B-1,
traffic between D and B could go through C.

The issue is not how to route an IP packet once an IP addresse has been
selected.  The issue is, how to decide what interface (and which network)
to use when there is more than one choice.  It's possible that the "best"
choice will vary during the life of one connection, based on packet sizes
and network loading.

I'm not looking for "clever" ways to assign names to IP addresses.  I'm
looking for ideas which might challenge some of the basic IP concepts,
like names being associated with interfaces instead of hosts, and routing
decisions based on a name specified by the user/application.  Have these
issues already been discussed anywhere?  A quick look at the RFC index
didn't help me.
 
I'm looking forward to benefiting from the accumulated wisdom on the net.
Thanks in advance.

Steve Jay
shj@ultra.com  ...ames!ultra!shj
Ultra Network Technologies / 101 Dagget Drive / San Jose, CA 95134 / USA
(408) 922-0100 x130	"Home of the 1 Gigabit/Second network"
 
-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      13 Jun 90 23:21:24 GMT
From:      weintrau%mpx0.lampf.lanl.gov@lanl.gov  (Weintraub, B. L.)
To:        tcp-ip@nic.ddn.mil
Subject:   Help with Non-Homogeneous LAN?

We are in the process of planning a non-homogeneous LAN.  We are an engineering
group, and only a couple of us are reasonably computer-literate.  Nobody really
knows how to connect all of these machines.  For that matter, none of the 
computer experts around here have ever constructed such a diverse LAN either.  
So, please excuse any misuse of terminology in this posting.            

Here is a list of computers to be included:
1)  Several Hewlett-Packard 9000 series 300 workstations.  These belong to the
design/drafting section and are used primarily for CAD.
2)  One DEC VAXstation 3100.  Primary use is in running finite element codes. 
3)  Many varieties of Apple Macintosh.  
4)  IBM AT's running MS-DOS.
5)  IBM PS/2's running MS-DOS.
6)  IBM PS/2's running OS/2.

We wish file transfer capability between all of the above, as well as output
spooling to the following devices:
1)  HP plotter connected to HP workstation.
2)  HP plotter on DECserver.
3)  HP plotter on Localtalk. (Is this possible?)
4)  Apple Laserwriters, currently on Appletalk.
5)  Various HP printers, either connected to the HP workstations, or ?
6)  Possibly a DEC LN03 connected via a DECserver to a DECnet network.

We are also considering using one of the HP workstations or the VAXstation as a
fileserver.  Currently, the VAXstation is connected via DECnet over ethernet
to a site-wide network of numerous other VAXes.  The HP workstations are also
on the ethernet backbone.  We have a site license for Multinet which has not
been installed on the VAXstation yet.  It's a reasonable assumption that the
protocol-of-choice is TCP/IP, but please feel free to disagree.

Some of the options being considered are:
1)  Leave the Mac's on Appletalk and install a gateway Appletalk <--> Ethernet. 
Use some version of TCP/IP to talk to the HP's and IBM's, and either TCP/IP 
or Alisatalk or LANworks (when it's released) to talk to the VAX(es).  Or 
install ethernet cards in the Mac's.  Any comments on how well either option 
will work?  Any other suggestions?  
2)  Put the IBM's on Appletalk, or install Ethernet cards.  We tested Apple's
"Localtalk for MS-DOS", and it was less than satisfactory.  Evidently,
character formatting is lost in printing on a laserwriter.  Perhaps, there's
some patch that we did not discover.  Besides, are there equivalent cards for 
PS/2's?  Again, any comments or suggestions?
3)  What's the best way of accessing the plotters?  The most critical use for
the plotters is for the design/drafting section.  However, we'd like to access
them from other computers as well. We've been told to set up a "Block-mode 
Terminal", and use one of the HP workstations as a fileserver and print spooler.
Will this work?  Can other machines besides the HP's reach the plotters in this
configuration?  How about putting it on localtalk?  I've heard that there's a 
piece of hardware for this purpose.  Or, would it be best to connect them 
directly off the ethernet through a DECserver?
4)  We think that the connections VAXstation <--> HP workstation are pretty
obvious.  Anyone have experience with this one?

Does anybody know _specifically_ which hardware and software to use?  Has 
anyone ever done this?  Obviously, compatibility between various parts is a 
consideration as transparency of the completed network.  

Please e-mail or telephone.
Much thanks.

Barbara Weintraub
MP-8:  Accelerator Engineering and Maintenance
Los Alamos National Lab
(505)667-9742
-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 00:50:16 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!thucydides.cs.uiuc.edu!morrison@ucsd.edu  (Vance Morrison)
To:        tcp-ip@nic.ddn.mil
Subject:   PCroute 2.1 release out

Hello,

PCroute2.1 is now available via anonymous FTP from accvuax.nwu.edu
(129.105.49.1).   This version is not too different from version 2.0.
The only differences are

	1) a BUG fix for the slip code.  If you are running SLIP,
   	   you should get the update.  The bug causes PCroute to hang
	   under high load.  The main reason for this this release is 
	   to get this bug fix out.

	2) Slight changes to the WD8003e driver that should allow
	   the router to work with some of the more recient western
	   digital cards (WD8013EBT and the WD8003EBT).   I have
	   no way of testing if these cards will work (since I 
	   don't have them).  I also have not written the changes
	   into the documentation.  If however, you do have one of
	   these cards and would like to beta-test this aspect of
	   the code, please contact me.  

If all goes well, a 'real' release will happen soon,  which should
feature (slow) packet driver support and true support for the expanded
buffer and 16 bit cards.  This release is really only to get the SLIP 
bug fix out.  

Vance
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 09:05:45 PDT
From:      postel@venera.isi.edu
To:        bunny!jdg0@husc6.harvard.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: PPP Info (was SLIP reliability)

Jose Diaz-Gonzalez:

For info on PPP see RFC-1134.

--jon.
-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 02:15:22 GMT
From:      vixie!asylum!karl@decwrl.dec.com  (Karl Auerbach)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Efficiency (or lack thereof) of ASN.1.
In article <8020@mirsa.inria.fr> huitema@jerry.inria.fr (Christian Huitema) writes:
>A few comment on the efficiency of ASN.1. We did quite a lot of work on
>that at INRIA

>* the handling of the strings is comparable to what can be found in
>other syntaxes: the coding of the tag and length field may take 20
>instructions instead of 1 or 2, but it is outweighted by the copying of
>the string itself, which is syntax independant. The decoding can however
>be made much longer if your partner insists on passing its strings as
>``sequences of segments''.

I've found that constructorization of strings can add substaintially
to the overhead of the decoder.  Have you considered this in your numbers?

Thanks for your comments.

				--karl--
-----------[000269][next][prev][last][first]----------------------------------------------------
From:      lefty@obelix.twg.com
To:        Kwang Sung <infmx!kwang@uunet.uu.net>
Cc:        tcp-ip@nic.ddn.mil
Subject:   
Kwang--

I'm tired!

And annoyed!!

Please, please, please, before we waste further bandwidth on this, look at the 
article "How to Create a New Newsgroup" in comp.announce.newusers.  This item, 
which you seem to be completely unaware of, describes the ESTABLISHED and 
LONG-STANDING procedure for creating a new newsgroup.

You haven't made even a minimal effort to a] determine what the proper 
procedure is or b] follow it.  You haven't posted a call for discussion, you 
haven't allowed anything remotely like a reasonable discussion peroiod, you 
haven't taken a proper vote or allowed the time for one; in short, you haven't 
made any attempt at all to do this in a "by the book" fashion.

Regardless of the merit (or lack thereof) of your proposal, the net effect of 
this is that we have to wade through a lot of extraneous nonsense in your 
(possibly misguided) quest to not 'bother either "comp.protocols.iso" or 
"comp.protocols.tcp-ip"any more'.

PLEASE!  READ THE PROCEDURE!  FOLLOW IT!  We've only been doing this on the 
Net for several years now.  And please, try to refrain from clogging this 
mailing list up with much nore of this.  There is an appropriate forum for 
this discussion, AND THIS MAILING LIST IS _NOT_ IT!!

|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|
|           David N. Schlesinger || "When I have nothing to say,       |
|           The Wollongong Group ||  my lips are sealed;               |
| Internet: Lefty@twg.com        ||  say something once,               |
| POTS:     415/962-7219         ||  why say it again?" -- David Byrne |
|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|

-----------[000270][next][prev][last][first]----------------------------------------------------
From:      lefty@obelix.twg.com
To:        "Don Garner (CADIG STAFF) " <don@usna.navy.mil>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:   Re:  Mourning of the passing of the ARPANET
In <90Jun13.100238edt.190@staff.ecs.usna.navy.mil>, "Don Garner (CADIG STAFF) 
" <don@usna.navy.mil> writes:

> Are there no comments on what it means to lose ARPANET?


"Live in the future; it starting now."

|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|
|           David N. Schlesinger || "When I have nothing to say,       |
|           The Wollongong Group ||  my lips are sealed;               |
| Internet: Lefty@twg.com        ||  say something once,               |
| POTS:     415/962-7219         ||  why say it again?" -- David Byrne |
|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 08:39:45 EDT
From:      mep@aqua.whoi.edu (Michael E. Pare)
To:        sdd.hp.com!uakari.primate.wisc.edu!ark1!volleydog!rhott@ucsd.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  IP Addresses (Subnets)
>I have a quick question, hopefully you will not flame to loudly with
>regard to  viewing RFCs.  I looked through RFC 950 to try to determine
>how to specify a host when using a subnet.  In my particular instance we
>have a class B network.  I am interested in how one would specify
>addresses when a subnet of 6 bits is used.

>Suppose I want the 300th host on the 1 subnet of a class B network with
>a netmask of 255.255.252!  Should I specify the IP address as
>128.38.1.300 or 128.38.253.44

>I guess my overall question is:  Should I specify the addressing using
>the 3rd octet field in the dot notation as the subnet or as the 3rd
>octet of the 32 bit field? 

>Thanks,
>  Bob Hott

The first subnet using 6 bits will be 4.  Decimal 300 in binary is
100101100. The rightmost 8 bits belongs to the first field and is 44.
The leftmost 1 is part of the next field.  The resulting binary format
for the first two fields will be :

			00000101 00101100
			------
			subnet|---------|
				host
The resulting decimal values are 5 and 44 respectively.  Thus the IP address
will be 128.38.5.44 for the 300th host of the first subnet.
-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Thu 14 Jun 90 09:45:44-CDT
From:      Matt Jonson <AFDDN.JONSON@GUNTER-ADAM.AF.MIL>
To:        sdd.hp.com!uakari.primate.wisc.edu!ark1!volleydog!rhott@ucsd.edu, rhott@relay.nswc.navy.mil
Cc:        tcp-ip@nic.ddn.mil, afddn.beach@GUNTER-ADAM.AF.MIL, afddn.pm@GUNTER-ADAM.AF.MIL
Subject:   Re: IP Addresses (Subnets)
Bob Hott <rhott@relay.nswc.navy.mil> writes:
>Suppose I want the 300th host on the 1 subnet of a class B network with
>a netmask of 255.255.252!  Should I specify the IP address as
>128.38.1.300 or 128.38.253.44

>I guess my overall question is:  Should I specify the addressing using
>the 3rd octet field in the dot notation as the subnet or as the 3rd
>octet of the 32 bit field?


The dot decimal notation must break apart into octets, so there is no way
to go over 255 in any given piece.  So, depending on what you mean by
"the 1 subnet", it should look something like this:

     128.38. <6 subnet bits> <2 host bits> . <8 host bits>

host 1,300:            (1)  (256) + (32)+(8)+(4)
     128.38. <0 0 0 0 0 1> <0 1>. <0 0 1 0 1 1 0 0>
			4  +  1       32 + 8+4
  =  128.38.5.44
which is the 300th host on subnet 1, and is on a subnet whose first host is
128.38.4.1, and whose last host (the 1022nd) is 128.38.7.254.  You must
bear in mind that all ones and all zeros in the host portion is reserved.
I think your first subnet would actually be subnet 0, extending from
128.38.0.1 to 128.38.3.254.

Note your netMASK is still 128.38.252.0.  The netmask is only used for
the purpose of masking off the net portion of an ip address, because a logical
AND is performed on the netmask and any given host address (so the zeros knock
off the host number, and the ones pass just the net number) when you're
trying to determine a route for a particular packet. It looks like you got a
little confused on how your netmask relates to your address.

Hope I've been helpful,
MWJ
-------
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 08:47:23 EDT
From:      Frank Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET>
To:        CSYSMAS@OAC.UCLA.EDU, haverty@BBN.COM
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Mourning of the passing of the ARPANET
 > From tcp-ip-RELAY@NIC.DDN.MIL Thu Jun 14 08:37:24 1990
 > From: Jack Haverty <haverty@BBN.Com>
 > Subject: Re: Mourning of the passing of the ARPANET
 > To: CSYSMAS@oac.ucla.edu
 > Cc: haverty@BBN.Com, tcp-ip@nic.ddn.mil
 > Mail-System-Version: <MacEMail_1.2.2@BBN.COM>
 > 
 > Perhaps instead of retiring #10 to a museum, we could have a ceremony
 > at Interop where the number is officially "retired", and a banner hoisted
 > to the ceiling - anybody volunteer to make a banner out of fishnet?
 > Then net 10 could be assigned to be used to create a bunch of class B
 > numbers for aspiring neonetworks who want to follow in the Arpanet's
 > footsteps (yes I know that's technically difficult).
 > 
 > Jack
 > 
 > Dan Lynch - are you listening....
 > 

How about officially assigning NET 10 to Interop - then it could be brought out
of retirement each year for all of the newcomers to look at - sort of like
the IMP last year. Maybe during the "off season" Interop could keep 2 PC's
running in a backroom on some Ethernet, pinging each other - on NET 10.

Frank Kastenholz
Racal Interlan
-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 09:05:38 EDT
From:      jbvb@vax.ftp.com  (James B. Van Bokkelen)
To:        goldstein@carafe.enet.dec.com  (Fred R. Goldstein)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP reliability
Normally I know better than to say CRC-16, but...  Sorry.

In my personal experience (which includes supporting a lot of TCP/IP
nodes), I have only had one report of undetected data corruption in
TCP (a transposition caused by a device driver bug while transferring
a very repetitive raster file).  The combination of TCP and IP on
SLIP seems fairly robust in practice: For two years our Internet link
was leased-line SLIP, and I am using dial-up SLIP to send this, and
I've never seen an error that got past the checksum.  This may be
because there is a good match between the errors asynch lines tend to
generate and those the checksum is likely to detect.

James B. VanBokkelen				FTP Software Inc.
jbvb@ftp.com					617-246-0900
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 11:56:12 -0400
From:      Hans-Werner Braun <hwb@merit.edu>
To:        hayes!wisner@decwrl.dec.com, tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET

>Oh, come now. Nobody's big enough to need a class A network. Entities
>that have class A networks now didn't get them because they've got big
>networks; they got them for political reasons. MIT and Stanford were
>big with DARPA. MERIT runs NSFNET. It'll be a long, long time before
>anyone with a class A net manages to accumulate sixteen million hosts.

Your comment is misleading. Merit had a class A network number long
before we had to do with NSFNET. The NSFNET backbone itself uses a Class B
network number. The reason why Merit has a network number was exclusively
on grounds of mapping addresses to the probably 200 or so packet switching
nodes that Merit had in that state of Michigan at that time (now much
more than 200). Potentially all those nodes map to what Merit calls
"hosts" and those (several different) hosts can map to many "ports."
Took Jon Postel and me quite a while to "fight" this out at that time.
It was not possible to fit this into a Class B space.
	
	-- Hans-Werner
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 13:06:23 -0400
From:      Stephen Wolff <steve@cise.nsf.gov>
To:        hayes!wisner@DECWRL.DEC.COM
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Mourning of the passing of the ARPANET
> Oh, come now. Nobody's big enough to need a class A network. Entities
> that have class A networks now didn't get them because they've got big
> networks; they got them for political reasons. MIT and Stanford were
> big with DARPA. MERIT runs NSFNET.

Merit had net 35 a long time before there was an NSFNET.  Don't forget that
the Merit Computer Network grew up contemporaneously with the ARPANET - and
seems likely to outlast it by some time.  -s
-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 08:22:36 GMT
From:      hayes!wisner@decwrl.dec.com  (Bill Wisner)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
CSYSMAS@OAC.UCLA.EDU (Michael Stein) writes:

>Net 10 is a class A network number.  As we run out of network
>numbers someone is going to need it, don't stick it in some
>museum.

Oh, come now. Nobody's big enough to need a class A network. Entities
that have class A networks now didn't get them because they've got big
networks; they got them for political reasons. MIT and Stanford were
big with DARPA. MERIT runs NSFNET. It'll be a long, long time before
anyone with a class A net manages to accumulate sixteen million hosts.

Bill Wisner <wisner@hayes.fai.alaska.edu> Gryphon Gang Fairbanks AK 99775
Any member introducing a dog into the Society's premises shall be liable to
a fine of one pound. Any animal leading a blind person shall be deemed to be
a cat. -- Rule 46, Oxford Union Society, London
-----------[000278][next][prev][last][first]----------------------------------------------------
From:      lefty@obelix.twg.com
To:        tcp-ip@nic.ddn.mil, infmx!nsc!cs.UMD.EDU!pete@uunet.uu.net, infmx!nsc!gateway.mitre.org!reichlen@uunet.uu.net, infmx!nsc!ico.isc.com!dougm@uunet.uu.net, mrose@cheetah.nyser.net, db@east.sun.com, dawei@eng.sun.com, torben@foralie.ics.hawaii.edu, richardt@legato.com, bob@morningstar.com, kzm@nms.hls.com, Stef@nrtc.northrop.com, schoff@psi.com, louie@sayshell.umd.edu, Allen_Rochkind@spd.3mail.3com.com, cperry@starbase.mitre.org, galvin@tis.com, UCBCMSA!CLIFF@uunet.uu.net, VitaM6!marciano@uunet.uu.net, YAKOV@yktvmx.bitnet, cmt@apollo.com, att!lzaz!jer@uunet.uu.net, zopalka@bbn.com, mundy@beast.ddn.mil, callon@bigfut.enet.dec.com, dino@bridge2.esd.3com.com, merritt@brl.mil, ggm@brolga.cc.uq.oz.au, goldstein@carafe.enet.dec.com, collins@ccc.mfecc.llnl.gov, haun@ccc.mfecc.llnl.gov, cire@cisco.com, grieve@cos.com, dab@cray.com, hagens@cs.wisc.edu, ietf-osi@cs.wisc.edu, merlin@csvax.seas.smu.edu, roki@dhafeu52.bitnet, curt@dtix.dt.navy.mil, david@elroy.jpl.nasa.gov, keith@excelan.com, gmalkin@ftp.com, dscott@gateway.mitre.org, epg@gateway.mitre.org, kit@gateway.mitre.org, patb@gateway.mitre.org, rick@gateway.mitre.org, saunders@gesundheit.west.sun.com, dennis@gpu.utcs.utoronto.ca, jsherida@ibm.com, yakov@ibm.com, karn@ka9q.bellcore.com, amanda@mermaid.intercon.com, jdr@mlb.semi.harris.com, netwrx1!graham@uunet.uu.net, iso@nic.ddn.mil, isode@nic.ddn.mil, tcp-ip@nic.ddn.mil, nsc!amdahl!ames!harvard!talcott!wellflt!swillis@uunet.uu.net, nsc!asylum.sf.ca.us!karl@uunet.uu.net, nsc!wellfleet.com!bstreile@uunet.uu.net, martin@protolaba.dca.mil, jessop@rlgvax.opcr.icl.com, oberman@rogue.llnl.gov, moose!in@uunet.uu.net
Cc:        Kwang Sung <infmx!moose!kwang@uunet.uu.net>
Subject:   Creation of new NewsGroup
I would like to propose the creation of a new newsgroup.

                   "alt.flame.kwang"

KWANG!

READ THE PROCEDURE!

IT'S IN news.announce.newusers!

IT'S CALLED "HOW TO CREATE A NEW NEWSGROUP"!

IT TELLS YOU HOW TO CREATE A NEW NEWSGROUP!

THAT'S WHY IT'S CALLED THAT!

READ IT!

NOW!!

PLEASE!!!

CAN YOU HEAR ME, KWANG??

|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|
|           David N. Schlesinger || "When I have nothing to say,       |
|           The Wollongong Group ||  my lips are sealed;               |
| Internet: Lefty@twg.com        ||  say something once,               |
| POTS:     415/962-7219         ||  why say it again?" -- David Byrne |
|<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>|

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 15:07:00 CST
From:      "Dan Kellen" <kellen@uv4.eglin.af.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   Thanks: I need help with subnetting

   Thanks to all the people that sent help or solutions to my problem.
   I was trying to set up the first subnet on a class B network, without 
   converting the whole network.  We have been assigning addresses as if 
   we were subnetted; each building has a unique third octet.
   The buildings are tied together with ethernet bridges, not IP routers.

   Here's the solution I implemented.  

   I have configured both interfaces on the subnet gateway and all subnet
   machines on the subnet with class C netmask's and broadcast addresses.
   Meanwhile all other hosts on the network still have their class B netmask.
   I consider this a temporary configuration.

   Getting routing to work was my biggest problem.  Here's what I've done.

   On the subnet machines, I added a default route pointing to the 
   subnet gateway. 
       route add default 129.61.9.2 1

   On the subnet gateway, I added a default route pointing to the main 
   network with a metric of zero. 
       route add default 129.61.2.40 0

   On main network machines that want to talk to the subnet machines I have 
   had to add host routes.  I could not get dynamic routing to do this.
       route add 129.61.9.4 129.61.2.40 1

   Since that time, I have changed my main network gateways to announce a 
   default route via RIP.  I probably should have done this sooner, but we 
   are still moving from static routes to RIP.  I won't have to add the 
   default routes on the next subnet.
   
   I have been watching for broadcast storms, and have seen none.  But, when 
   the subnet gateway RIP's to the subnet 2 broadcast, other RIPers send it 
   a redirect.

   Here's how it looks.

  network: 129.61.0.0       network: 129.61.2.0         network: 129.61.9.0
  netmask: 255.255.0.0      netmask: 255.255.255.0      netmask: 255.255.255.0

                            this int. only             +-----+
                                |                      |     |
                    /\          \/               +-----| SUN |
                    |                            |     |     |
                    |             +-----+        |     +-----+
                    |      129.61 |     | 129.61 |
                    |-------------| SUN |--------+
                    |        2.40 |     | 9.2    |
                    |             +-----+        |     +-----+
                    |                            |     |     |
                    |                            +-----| SUN |
                    \/                                 |     |
                                                       +-----+

   Dan
   ------------------------------------------------------------------
   Digital Equipment Corp.    Internet:  kellen@odixie.enet.dec.com
                              EASYnet:   ODIXIE::KELLEN
   System/Network Manager     Internet:  kellen@uv4.Eglin.AF.MIL
   Eglin AFB, Florida         PHONEnet:  (904)882-5498

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 16:39:59 EDT
From:      Rafat Y. Shaheen <shaheen@cs.odu.edu>
To:        rhott@volleydog.nswc.navy.mil, tcp-ip@nic.ddn.mil
Subject:   Subnet Addressing
Robert W. (Bob) Hott writes:
 > 
 > I have a quick question, hopefully you will not flame to loudly with
 > regard to  viewing RFCs.  I looked through RFC 950 to try to determine
 > how to specify a host when using a subnet.  In my particular instance we
 > have a class B network.  I am interested in how one would specify
 > addresses when a subnet of 6 bits is used.
 > 
 > Suppose I want the 300th host on the 1 subnet of a class B network with
 > a netmask of 255.255.252!  Should I specify the IP address as
 > 128.38.1.300 or 128.38.253.44
 > 
 > I guess my overall question is:  Should I specify the addressing using
 > the 3rd octet field in the dot notation as the subnet or as the 3rd
 > octet of the 32 bit field? 
Bob:

With all the ansewrs I have' read so far, only one answer looks allright:
It was from Michael.E.Pare mep@aqua.whoi.edu.
The following is to confirm:

To get things straight now:

You want to have 6 bits for a subnet:

Your mask is : 255.255.252.0
And you can address up to 2**6 = 63 physical network
And up to 2**10 = 1023 hosts within one such network.

You declared the first 6 bits of the third octet to be the physical nets:

	11111111|11111111|11111100|00000000	<---- Subnet Mask
The first subnet will be to set the first bit in the physical net address,
which is the third position from the right in the third octet, that is:
	10000000|00100110|00000100|00000001
This correspond to:
	128.38.4.1 	<-----For the 1st host in the 1st subnet.
and for the 300th host:
	10000000|00100110|00000101|00101100
Which corresponds to:
	128.38.5.44 	<---- Same answer as Michael

Another example, for the second subnet and the 300th host:

	10000000|00100110|00001001|00101100
Which corresponds to:
	128.38.9.44

References:
[1] InterNetworking with TCP/IP, Douglas Comer (Purdu University),1988
RFCs:

The standard for subnet addressing comes from Mogul[RFC 950];
Clark [RFC 932], Karels [RFC 936], Gads [RFC 940], and Mogul[RFC 917]

All contain early proposals for subnet addressing schemes. Mogul[RFC 932] 
discusses broadcasting in the presence of subnets. Postel [RFC 925] 
considers the use of proxy ARP for subnets. Carl-Mitchell and
Quarterman [RFC 1027] discusses using proxy ARP to implement transparent
subnet gateways.

Best Regards.		

	... Shaheen

Old Dominion University (ODU)
Rafat Y. Shaheen
shaheen@cs.odu.edu

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 16:53:25 EDT
From:      Bob Stewart <stewart@xyplex.com>
To:        infmx!moose!kwang@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Messages about comp.protocols.iso.migration
Am I the only one who's getting annoyed about these long, ISO/egocentric
messages that I tend to get in multiple copies?  Are they going to stop soon?

I like to see discussions of semirelevant topics for a while, and have been
accused of being impressed with myself, but enough is enough.

This opinion is my own, end-of-a-long-day, not well considered, and real. :-|

	Bob

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 13:49:51 GMT
From:      bu.edu!dartvax!litle!tom@uunet.uu.net  (tom hampton)
To:        tcp-ip@nic.ddn.mil
Subject:   How long before I can reopen a closed socket?

We have a problem with a socket-based server application which needs to
restart quickly.  What we find instead is that it may take a minute
before the passively binding program can reopen a socket after both
the active and passive binders have terminated.

Is this because

1) We have a bug in ISC 2.2 TCP/IP

2) We are using a "well known address" and these things don't recycle
   instantly after closing (just a wild guess...)

3) We aren't cloising things properly?  We sure think we are, but 
   we notice that the problem gets even worse after an abnormal 
   termination...

-- 
===============================================================================
 Tom Hampton, Mgr. New Technology, Litle & Co. | POB A218, Hanover, NH 03755
 603 643 1832 
-------------------------------------------------------------------------------
 Design is about figuring out what you won't be able to do.
-------------------------------------------------------------------------------
tom@litle.com  tom@litle.uucp  {backbone}!dartvax.dartmouth.edu!litle!tom
===============================================================================
-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 17:51:34 EDT
From:      Dennis E. Baasch (516) 271-4525 <etinc!dennis@uu.psi.com>
To:        tcp-ip@nic.ddn.mil
Subject:   OSI, X.25 and the INTERNET

	This isn't in response to any particular message, but all of the banter
about OSI and the INTERNET (philosophically speaking) has really been getting
on my nerves. I usually tend to stay out of nonsensical arguments, but in this
case I feed compelled to express my views.

	It seems totally amazing to me that so many very well educated folks
can have such a limited understanding about what's going on in this country
( the United States, that is). Whether its arrogance or ignorance isn't yet
clear, but with all of the propaganda floating around (these lists not
withstanding), I suppose it isn't too surprising. Perhaps the truth isn't as
clear when you don't have many FACTS to work with.

	It seems that anyone with even limited networking experience could
easily come to the conclusion that there is no single solution that will
unite the world. The diversity of applications is much too great, and the
investment in applications much to great to expect any real migration to
any networking concept very much different to what currently exists. The
proponants of OSI are kidding themselves if they think that their concept is
leading them to some sort of utopia; there's a price to pay for generality
and a world screaming for more throughput and functionality is not likely
to sacrifice speed and comfort for 4-wheel drive.

	There's exactly two reasons for the existence (and success) of the 
INTERNET: The AT&T breakup and the fact that it is virtually the only 
supported nationwide network. 

The AT&T breakup: The reasoning behind this may not be obvious to the average
reader, but the AT&T breakup may be the single most significant event in 
modern networking history. In a negative sort of way, that is. In virtually
every modern country in the world all networking is based on a centralize
packet-switching backbone run by the equivalent of what used to be AT&T.
The breakup makes such a network ILLEGAL in the US, at least if implemented
by the phone companies, and has also left the individual phone companies
so talentless that data networking is practically out of their realm of 
understanding. This fact has also left this country so far behind in X.25
technology that few even think about it and almost no-one understands it.
I read a message in which someone referred to X.25 as "ancient technology",
which is quite ironic since in reality it hasn't yet arrived in the US.
This from the people who have proposed PPP, a protocol with half of the
functionality of X.25, none of the networking capabilities and twice the
overhead. The fact is that X.25 is so vastly superior to anything thats 
been proposed in the last 10 years that there's very little reason to 
come up with something else. Its generic transport with a single basic 
concept: logical multiplexing is faster and more efficent than physical
interface management; something that will hold true until busses are
faster than CPUs. The only thing "ancient" about X.25 is the public
switches, most of which are still based on 6809s. But new technology
products with X.25 at T1 speeds are creeping into the marketplace, and 
when they do, the Europeons will be laughing out loud.

While the INTERNET isn't really the only national network, its the only one
thats run for fundamentally unselfish reasons. For E-MAIL and shuffling
around public domain code, its just fine. But if someone came into your board
room and proposed this ratsnest with all of the patchwork protocols,
overburdened routers and (how many hops?) with no link-level error
correction, what would you think?

	I don't have a conclusion to all of this, only a collection of fears.
I'm not sure that I'm even trying to make a point, but if I am, it might be 
something like this: The Europeans may be trying to build a tall building with
short cranes (OSI over X.25), but in the US we're trying to build an equally
ugly edifice on sand (IP over ?). Neither will stand a hurricane, but at least
the Europeans have a basement.


					Dennis
					Emerging Technologies
					etinc!dennis@uu.psi.com

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 14:04:16 GMT
From:      curt@isa.uucp (Curt Gedak)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Re: tcp for VMS and tcp over fiber-optics

In article <1481@ssc-bee.ssc-vax.UUCP> maa@ssc-vax.UUCP (Mark A Allyn) writes:
>In the future, we may want to install a Sun or other Unix/tcp/nfs type
>goody in the same room as the Macintosh and the printer. What I need help is
>with the following.
>
>The VAX has VMS and DECNET. Because we may have future Unix/tcp type 
>stuff in our environment, we would like to have all communication via TCP.
>I need some suggestions on what software to get for the VAX so that it can 
>run TCP and preferably also NFS. I would also like something that includes
>the necessary libraries and include files so that I can write applications
>using sockets for both stream stuff and datagrams. I have heard of some names
>including Wollengrad (sp?) but don't know anything about them. I need 
>company names and phone numbers.
>
 ... Stuff deleted ....

Process Software Corporation offers a product for the VAX/VMS that supports
FTP, SMTP, TELNET, and NFS.  It can run over the same ethernet that is
concurrently running DECNET.  It is also one of the only products that
states that it supports the DEQNA board (which is not totally IEEE 802.3
compliant).  Their phone number is (508)879-6994.

Note that in no way do I work for Process Software Corporation.  I only
have experience with their products, and have found their technical
support to be very professional.


-- 
Curt Gedak                           uucp: {uunet,alberta}!ncc!isagate!curt
ISA Corporation                       bus: (403) 420-8081
Edmonton, Alberta, Canada.           Home: (403) 992-0591

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 18:16:02 ET
From:      "Rich Woundy" <RWOUNDY@IBM.COM>
To:        tcp-ip@nic.ddn.mil
Subject:   IP Addresses (Subnets)
 >From: sdd.hp.com!uakari.primate.wisc.edu!ark1!volleydog!rhott@ucsd.edu (The
 >VolleyDog)
 >Subject: IP Addresses (Subnets)
 >I have a quick question, hopefully you will not flame to loudly with
 >regard to  viewing RFCs.  I looked through RFC 950 to try to determine
 >how to specify a host when using a subnet.  In my particular instance e
 >have a class B network.  I am interested in how one would specify
 >addresses when a subnet of 6 bits is used.
 >
 >Suppose I want the 300th host on the 1 subnet of a class B network wit
 >a netmask of 255.255.252!  Should I specify the IP address as
 >128.38.1.300 or 128.38.253.44
 >
 >I guess my overall question is:  Should I specify the addressing using
 >the 3rd octet field in the dot notation as the subnet or as the 3rd
 >octet of the 32 bit field?
 >
 >Thanks,
 >  Bob Hott
Bob,
   Per RFC 1117, you should specify the addressing using the 3rd octet
of the 32 bit address. The 32 bit address of the 300th host on subnet 1
on network 128.38 should be (by my reading/implementation of RFC 950):

NNNNNNNN NNNNNNNN SSSSSSHH HHHHHHHH N = network,S = subnet,H = host bits
10000000 00100110 00000101 00101100 N = "128.38",S = 1,H = 300
 128    . 38     . 5      . 44      Dotted Decimal Notation

The 6 bit subnet mask you chose allows you to have subnets numbered
1 to 62 (see bottom of page 6 in RFC 950).

As another illustration, note the example (p. 13 bottom, RFC 950)
of the same subnet mask for network 128.99. Address 128.99.4.123
specifies host 123 on subnet 1 on class B network 128.99.0.0.


> From: Frank Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET>
> From RFC 1117 (Internet Numbers):
> :
>    One commonly used notation for internet host addresses divides the
>    32-bit address into four 8-bit fields and specifies the value of eah
>    field as a decimal number with the fields separated by periods.  Ths
>    is called the "dotted decimal" notation.  For example, the internet
>    address of VENERA.ISI.EDU in dotted decimal is 010.001.000.052, or
>    10.1.0.52.
>
> So, the correct number is 128.38.253.44.
>
> This is not an "official standard" but it is common usage to the degre that
> no one does anything different.
>
> Frank Kastenholz
> Racal Interlan

If this is "common usage", then a router literally following
RFC 950 will handle 128.38.253.44 as net 128.38.0.0, subnet 63 ("252"),
host 300 ("1.44"), assuming the router is privy to the subnet mask.
See RFC 1122 (Requirements for Internet Hosts -- Communication Layers),
pp. 30-31 (condensed here):
  IP addresses are not permitted to have the value 0 or -1 for any of
  the <Host-number>, <Network-number>, or <Subnet-number> fields,
  except in the special cases listed here as either
   <Network-number>,<Host-number>   or
   <Network-number>,<Subnet-number>,<Host_number>
  (a) 0,0   (b) 0,<Host-number>   (c) -1,-1   (d) <Network-number>,-1
  (e) <Network-number>,<Subnet-number>,-1   (f) <Network-number>,-1,-1
  (g) 127,<any>
{See caveats in RFC for cases (a)-(g)}
Note that subnet 63 is equivalent to -1 in the description above.


> From:     Doug Nelson <NELSON%MSU.EDU@CORNELLC.cit.cornell.edu>
> The best answer is "none of the above".  If your netmask is 255.255.25.0,
> and you are on the first subnet of network 128.38, then your address rnge
> begins with 128.38.0.0, and ends with 128.38.3.255 (the latter being yur
> subnet broadcast address).  So, if your first host was numbered 128.381.1,
> then your 300th host would be 128.38.2.44.
>
> Doug Nelson
> Network Software Manager
> Michigan State University

Interpreting RFC 950 literally again, 128.38.2.44 specifies host # 556
on subnet 0 on network 128.38.0.0.
The host number space on subnet 1 of network 128.38.0.0 would be
from 128.38.4.1 to 128.38.7.254.

If my answer seems brain-dead, please notify myself and the list.
Otherwise, we're likely to retain three interpretations of the RFCs
to answer a straightforward question. Bob, this was obviously not
a dumb question to ask.

-- Rich
Richard Woundy, IBM Advanced Solutions Development, Milford, CT
Flames to: rwoundy@ibm.com
Disclaimer: IBM nor any other corporation or entity takes responsibility
 for the irresponsible things quoted in this message.

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 17:19:04 GMT
From:      usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ark1!volleydog!rhott@ucsd.edu  (The VolleyDog)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP Addresses (Subnets)
I would like to thank the folks that responded to my request aabout IP
Addresses (Subnetting).  The following is a summary of the responses,
the attachment at the end are the responses I recieved.

  Basically, I asked how to specify the IP address for a class B network
with a 6 bit subnet field and 10 bit host field.  The subnet was # 1, and
the host was # 300.  (I want to thank you for not flaming my mistake for
the octet representation.)  I suggested and octet representation and
a subnet representation.  I suggested an octet representation of
128.38.253.44 (it actually should have been 128.38.5.44) and a subnet
representation of 128.38.1.300.  The responses indicate that the octet 
representation should be used!

  I think it is a shame, since it makes it a little nasty to look
at address 128.38.4.2 and 128.38.5.44 and instantaneously know that they
are actually the same subnet.  I do understand why, and I expected that
this was going to be the case.

  As an aside, the reason I am asking it that I plan to originally
assign the subnet mask as 255 (all 8 bits), but I am afraid that I
may need less subnets, but more host addresses, some I am "planning
ahead".

  Once again, I appreciate your assistance, and your tolerance with
this type of question.

Bob Hott

			Responses Follow
------------------------------------------------------------------------
--------
From: ckollars@Sun.COM (Chuck Kollars - DSGG Technical Marketing - Boston)
Subject: Re: IP Addresses (Subnets)
Organization: Sun Microsystems, Billerica MA

In article <1990Jun13.145153.29190@relay.nswc.navy.mil> you write:
>I have a quick question, hopefully you will not flame to loudly with
>regard to  viewing RFCs.  I looked through RFC 950 to try to determine
>how to specify a host when using a subnet.  In my particular instance we
>have a class B network.  I am interested in how one would specify
>addresses when a subnet of 6 bits is used.
>
>Suppose I want the 300th host on the 1 subnet of a class B network with
>a netmask of 255.255.252!  Should I specify the IP address as
>128.38.1.300 or 128.38.253.44

Neither.  Host 300 on subnet 1 of net 128.38 with a subnet mask of 
255.25.252.0 should be 128.38.5.44.  

To see why, work it out in binary:

net field mask  11111111.11111111.00000000.00000000 (implied by Class B
address)
net value       10000000.00100110.xxxxxxxx.xxxxxxxx (128.38 w/in its field)

subnet mask     11111111.11111111.11111100.00000000 (255.255.252.0)
subnet field    00000000.00000000.11111100.00000000 (implied, subnet
mask w/o net field)
subnet value    xxxxxxxx.xxxxxxxx.000001xx.xxxxxxxx (1 w/in its field)

host mask       00000000.00000000.00000011.11111111 (implied, inverse of
subnet mask)
host value      xxxxxxxx.xxxxxxxx.xxxxxx01.00101100 (300 w/in its field)

final value     10000000.00100110.00000101.00101100 (128.38.5.44)
 (concatenation of all fields)

>I guess my overall question is:  Should I specify the addressing using
>the 3rd octet field in the dot notation as the subnet or as the 3rd
>octet of the 32 bit field? 

The octet.octet.octet.octet notation is very old, predating subnets by 
many years.  It happens that if your subnet mask falls on a byte 
boundary (is a multiple of 8 bits long), you can think of one of the 
fields as the "subnet number".  This convenient shortcut doesn't work 
if your subnet mask splits a byte.
--
chuck kollars    <ckollars@East.Sun.COM>
DSGG Technical Marketing, Sun's Boston Development Center

------------------------------------------------------------------------
--------
From djw@BBN.COM Wed Jun 13 14:00:01 1990
Subject: Re: IP Addresses (Subnets)

Hi,

In comp.protocols.tcp-ip you write:
}Suppose I want the 300th host on the 1 subnet of a class B network with
}a netmask of 255.255.252!  Should I specify the IP address as
}128.38.1.300 or 128.38.253.44

The a.b.c.d addressing notation has each portion being one octet.  So,
use 128.38.253.44 for maximum correctness.  But, some versions of some
operating systems may be more permissive: under SunOS 4.0.3, when I
telnet to 128.38.1.300 it responds with: "Trying 128.38.1.44 ...".
Telneting to 10.51 responds with "Trying 10.0.0.51 ...".

-david

------------------------------------------------------------------------
--------
From: rodk@Corp.Sun.COM (Rod King - Sun Consulting Mtn. View)
Subject: Re: IP Addresses (Subnets)
Organization: Sun Microsystems, Mt. View, Ca.

In article <1990Jun13.145153.29190@relay.nswc.navy.mil> you write:
>I have a quick question, hopefully you will not flame to loudly with
>regard to  viewing RFCs.  I looked through RFC 950 to try to determine
>how to specify a host when using a subnet.  In my particular instance we
>have a class B network.  I am interested in how one would specify
>addresses when a subnet of 6 bits is used.
>
>Suppose I want the 300th host on the 1 subnet of a class B network with
>a netmask of 255.255.252!  Should I specify the IP address as
>128.38.1.300 or 128.38.253.44

This is my vote (and I'm not saying its correct).

The last 2 bytes look like this:
76543210 76543210
subnet|---host--|

host 300 converts to 0x18c in hex.
Filling the bits in the 2 bytes, and using subnet 1, you get
76543210 76543210
00000101 10001100

Converting to IP address notation, you get
5.140 

for an overall IP address of
128.38.5.140.

Life's a lot easier with 8-bit subnets.

Can you also summarize your results?


        Rod King                  email:  rodk@sun.com
        Consultant                office: (415) 336-1897
        Sun Microsystems          FAX:    (415) 968-4356

------------------------------------------------------------------------
--------
From: cpw%snow-white@lanl.gov (C. Philip Wood)
Subject: Re:  IP Addresses (Subnets)

For Class B network:

	128.38.0.0		thats 10000000.00100110.00000000.00000000
				in binary
				
If your subnet is 6 bits then subnet 1 would be:

	128.38.4.0		thats 10000000.00100110.00000100.00000000
	
Host number 300 on subnet 1 would have IP address:

	128.38.5.44		thats 10000000.00100110.00000101.00101100


Did I get that right?

Phil

------------------------------------------------------------------------
--------
From: Frank Kastenholz <kasten%europa.interlan.com@relay.cs.net>
Subject: Re:  IP Addresses (Subnets)

 > From tcp-ip-RELAY@NIC.DDN.MIL Wed Jun 13 13:08:44 1990
 > From:
sdd.hp.com!uakari.primate.wisc.edu!ark1!volleydog!rhott@ucsd.edu  (The
VolleyDog)
 > Organization: Naval Surface Warfare Center, Dahlgren VA
 > Subject: IP Addresses (Subnets)
 > Sender: tcp-ip-relay@nic.ddn.mil
 > To: tcp-ip@nic.ddn.mil
 > 
 > I have a quick question, hopefully you will not flame to loudly with
 > regard to  viewing RFCs.  I looked through RFC 950 to try to determine
 > how to specify a host when using a subnet.  In my particular instance we
 > have a class B network.  I am interested in how one would specify
 > addresses when a subnet of 6 bits is used.
 > 
 > Suppose I want the 300th host on the 1 subnet of a class B network with
 > a netmask of 255.255.252!  Should I specify the IP address as
 > 128.38.1.300 or 128.38.253.44
 > 
 > I guess my overall question is:  Should I specify the addressing using
 > the 3rd octet field in the dot notation as the subnet or as the 3rd
 > octet of the 32 bit field? 
Bob:

>From RFC 1117 (Internet Numbers):
	
   One commonly used notation for internet host addresses divides the
   32-bit address into four 8-bit fields and specifies the value of each
   field as a decimal number with the fields separated by periods.  This
   is called the "dotted decimal" notation.  For example, the internet
   address of VENERA.ISI.EDU in dotted decimal is 010.001.000.052, or
   10.1.0.52.

So, the correct number is 128.38.253.44.

This is not an "official standard" but it is common usage to the degree that
no one does anything different.

Frank Kastenholz
Racal Interlan

------------------------------------------------------------------------
--------
From: romkey@asylum.sf.ca.us (John Romkey)
Subject: IP Addresses (Subnets)

The dotted-decimal notation (128.38.253.44) is just a direct
representation of the 32 bit IP address. It doesn't (necessarily)
break apart neatly into net, subnet and host numbers at dot
boundaries. So the 3rd octet field in the dot notation is equivalent
to the third octet in the 32 bit number.
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
"There is no loyalty except loyalty to the party. There is no love except love
of Big Brother. All competing pleasures we will destroy." - 1984 (film)

------------------------------------------------------------------------
--------
From: Matt Jonson <AFDDN.JONSON@gunter-adam.af.mil>
Subject: Re: IP Addresses (Subnets)

Bob Hott <rhott@relay.nswc.navy.mil> writes:
>Suppose I want the 300th host on the 1 subnet of a class B network with
>a netmask of 255.255.252!  Should I specify the IP address as
>128.38.1.300 or 128.38.253.44

>I guess my overall question is:  Should I specify the addressing using
>the 3rd octet field in the dot notation as the subnet or as the 3rd
>octet of the 32 bit field?


The dot decimal notation must break apart into octets, so there is no way
to go over 255 in any given piece.  So, depending on what you mean by
"the 1 subnet", it should look something like this:

     128.38. <6 subnet bits> <2 host bits> . <8 host bits>

host 1,300:            (1)  (256) + (32)+(8)+(4)
     128.38. <0 0 0 0 0 1> <0 1>. <0 0 1 0 1 1 0 0>
			4  +  1       32 + 8+4
  =  128.38.5.44
which is the 300th host on subnet 1, and is on a subnet whose first host is
128.38.4.1, and whose last host (the 1022nd) is 128.38.7.254.  You must
bear in mind that all ones and all zeros in the host portion is reserved.
I think your first subnet would actually be subnet 0, extending from
128.38.0.1 to 128.38.3.254.

Note your netMASK is still 128.38.252.0.  The netmask is only used for
the purpose of masking off the net portion of an ip address, because a logical
AND is performed on the netmask and any given host address (so the zeros knock
off the host number, and the ones pass just the net number) when you're
trying to determine a route for a particular packet. It looks like you got a
little confused on how your netmask relates to your address.

Hope I've been helpful,
MWJ
-------

------------------------------------------------------------------------
--------
From: mep@AQUA.WHOI.EDU (Michael E. Pare)
Subject: Re:  IP Addresses (Subnets)
Organization: The Internet

>I have a quick question, hopefully you will not flame to loudly with
>regard to  viewing RFCs.  I looked through RFC 950 to try to determine
>how to specify a host when using a subnet.  In my particular instance we
>have a class B network.  I am interested in how one would specify
>addresses when a subnet of 6 bits is used.

>Suppose I want the 300th host on the 1 subnet of a class B network with
>a netmask of 255.255.252!  Should I specify the IP address as
>128.38.1.300 or 128.38.253.44

>I guess my overall question is:  Should I specify the addressing using
>the 3rd octet field in the dot notation as the subnet or as the 3rd
>octet of the 32 bit field? 

>Thanks,
>  Bob Hott

The first subnet using 6 bits will be 4.  Decimal 300 in binary is
100101100. The rightmost 8 bits belongs to the first field and is 44.
The leftmost 1 is part of the next field.  The resulting binary format
for the first two fields will be :

			00000101 00101100
			------
			subnet|---------|
				host
The resulting decimal values are 5 and 44 respectively.  Thus the IP address
will be 128.38.5.44 for the 300th host of the first subnet.

------------------------------------------------------------------------
--------

=============================================================================

Fullname:         Robert W. (Bob) Hott
Mailing Address:  Naval Surface Warfare Center
                  Networks Branch (Code E41)
                  Dahlgren, Virginia  22448
DDN Mail:         rhott@relay.nswc.navy.mil
DDN Mail:         rhott@volleydog.nswc.navy.mil
Telephone:        (703) 663 - 7745

"If man were not meant to play volleyball, why are there so many beaches?"
	 - Bob Hott -
-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 18:32:41 GMT
From:      bu.edu!bu-it!kwe@uunet.uu.net  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Multi-homed hosts and parallel networks
In article <1990Jun13.213400.299@ultra.com>, shj@ultra.com (Steve Jay) writes:
>... Have there been any
> discussions on how IP can cope with multi-homed hosts and (semi-)parallel
> networks, such that traffic automatically takes the "best" path between
> hosts?
> ...
> I put "best" in quotes for a reason.  It may be considered better to have
> some traffic between B & C go over the ethernet rather than the faster
> network.  You may not want to clog up the fast network with the tiny
> packets generated by rlogin, but ftp data connections should be on the
> fast network.
> ...
> The issue is not how to route an IP packet once an IP addresse has been
> selected.  The issue is, how to decide what interface (and which network)
> to use when there is more than one choice...
>
> I'm not looking for "clever" ways to assign names to IP addresses.  I'm
> looking for ideas which might challenge some of the basic IP concepts,
> like names being associated with interfaces instead of hosts, and routing
> decisions based on a name specified by the user/application.  Have these
> issues already been discussed anywhere?  A quick look at the RFC index
> didn't help me.
>
> I'm looking forward to benefiting from the accumulated wisdom on the net.
>

        You might want to consider use of the Type of Service bits
in IP.  We are at the point where we will soon have some new routing
protocols deployed in the Internet which can support TOS routing.

        I noticed TOS coming up a lot at the Pittsburgh IETF meeting
and I did not get the feeling that very many people agreed on what
TOS meant.  Perhaps our wisdom accumulates more like dustballs than
pearls.  Now, if
you can figure out what TOS means according to the "accumulated wisdom"
of the IETF, you might be able to modify your applications to use TOS
with, for example, OSPF routing.  If you don't want to be compliant with
our accumulated wisdom, you might be able to use TOS as you please to
define parameters such as latency, packet size, or even dollar cost.

        You might also have a look at the Open Routing work.  Policy
based routing has a slightly different point of view, but it might
be able to subsume your concerns, on a longer timeframe than TOS routing.
Start with Dave Clark's RFC 1102 and Debra Estrin's RFC 1125.

        Kent England, Boston University
-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 18:52:04 GMT
From:      m2c!seqp4!markr@husc6.harvard.edu  (Mark Roddy)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How long before I can reopen a closed socket?
In <4847@litle.litle.COM> tom@litle.litle.COM (tom hampton) writes:

[How Long Must I Wait?]

>We have a problem with a socket-based server application which needs to
>restart quickly.  What we find instead is that it may take a minute
>before the passively binding program can reopen a socket after both
>the active and passive binders have terminated.

>2) We are using a "well known address" and these things don't recycle
>   instantly after closing (just a wild guess...)

In fact you must wait:

	CHORUS: Two Times the Maximum Segment Lifetime!

Which is the minute or two you describe.

The solution is to not use the well known address for the connection -
TCP allows you to accept a connection on a different port address than
the destination address in the connection request.

This is the mechanism used by most *nix TCP/IP services. 

The well-known address is always available to service the 
next incoming connection request.
-- 
-Mark Roddy
Sequoia Systems, Inc.          (508) 480-0800 x1284
markr@seqp4.uucp               m2c!seqp4!markr
-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 19:03:51 GMT
From:      escher@apple.com  (Michael Crawford)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Vote for/against "comp.protocols.iso.migration"
In article <4488@infmx.UUCP> kwang@infmx.UUCP (Kwang Sung) writes:
>
>	Now I would like to finalize my proposal on creation of a new
>newsgroup "comp.protocols.iso.migration".
>

It is not clear to me that the proper procedure for proposing a new
group, allowing a month or so for discussion, then a month or so for
voting, has been followed.

Please review the policies on this in the groups "news.groups" and
"news.announce.newusers".

It sure seems to me that it is not the proper thing to do to up and
announce a new group for what might more properly be a thread
of discussion in an existing group.

Personally, I would vote against this group until the traffic in the
existing groups on the thread has become enough that it is obnoxious
to filter out by those who are not interested in it.  Also, I would
like to see the discussion exist long enough to be sure it will not
die out after a few weeks.

Please don't be offended, but there has been quite a rash of new groups
lately, like psu.passwd.ne.security.  I would like to see this reigned
in a little.

>	So, could you create a new newsgroup "comp.protocols.iso.migration"
>as soon as possible so that we can discuss seriously and aggressively,
>and nobody can bother either "comp.protocols.iso" or "comp.protocols.tcp-ip"
>any more ??

You do this yourself by asking the news administrator at your site to
issue a "newgroup" command.

-- 
Michael D. Crawford
Oddball Enterprises		Consulting for Apple Computer Inc.
606 Modesto Avenue		escher@apple.com
Santa Cruz, CA 95060		Applelink: escher@apple.com@INTERNET#
oddball!mike@ucscc.ucsc.edu	The opinions expressed here are solely my own.

		alias make '/bin/make & rn'
-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 21:07:00 GMT
From:      kellen@UV4.EGLIN.AF.MIL ("Dan Kellen")
To:        comp.protocols.tcp-ip
Subject:   Thanks: I need help with subnetting


   Thanks to all the people that sent help or solutions to my problem.
   I was trying to set up the first subnet on a class B network, without 
   converting the whole network.  We have been assigning addresses as if 
   we were subnetted; each building has a unique third octet.
   The buildings are tied together with ethernet bridges, not IP routers.

   Here's the solution I implemented.  

   I have configured both interfaces on the subnet gateway and all subnet
   machines on the subnet with class C netmask's and broadcast addresses.
   Meanwhile all other hosts on the network still have their class B netmask.
   I consider this a temporary configuration.

   Getting routing to work was my biggest problem.  Here's what I've done.

   On the subnet machines, I added a default route pointing to the 
   subnet gateway. 
       route add default 129.61.9.2 1

   On the subnet gateway, I added a default route pointing to the main 
   network with a metric of zero. 
       route add default 129.61.2.40 0

   On main network machines that want to talk to the subnet machines I have 
   had to add host routes.  I could not get dynamic routing to do this.
       route add 129.61.9.4 129.61.2.40 1

   Since that time, I have changed my main network gateways to announce a 
   default route via RIP.  I probably should have done this sooner, but we 
   are still moving from static routes to RIP.  I won't have to add the 
   default routes on the next subnet.
   
   I have been watching for broadcast storms, and have seen none.  But, when 
   the subnet gateway RIP's to the subnet 2 broadcast, other RIPers send it 
   a redirect.

   Here's how it looks.

  network: 129.61.0.0       network: 129.61.2.0         network: 129.61.9.0
  netmask: 255.255.0.0      netmask: 255.255.255.0      netmask: 255.255.255.0

                            this int. only             +-----+
                                |                      |     |
                    /\          \/               +-----| SUN |
                    |                            |     |     |
                    |             +-----+        |     +-----+
                    |      129.61 |     | 129.61 |
                    |-------------| SUN |--------+
                    |        2.40 |     | 9.2    |
                    |             +-----+        |     +-----+
                    |                            |     |     |
                    |                            +-----| SUN |
                    \/                                 |     |
                                                       +-----+

   Dan
   ------------------------------------------------------------------
   Digital Equipment Corp.    Internet:  kellen@odixie.enet.dec.com
                              EASYnet:   ODIXIE::KELLEN
   System/Network Manager     Internet:  kellen@uv4.Eglin.AF.MIL
   Eglin AFB, Florida         PHONEnet:  (904)882-5498

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 21:26:30 GMT
From:      bacchus.pa.dec.com!kmeyer@decwrl.dec.com  (Kraig Meyer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
In article <1990Jun14.082236.16832@hayes.fai.alaska.edu> wisner@hayes.fai.alaska.edu (Bill Wisner) writes:
||Oh, come now. Nobody's big enough to need a class A network. Entities
||that have class A networks now didn't get them because they've got big
||networks; they got them for political reasons. MIT and Stanford were
||big with DARPA. MERIT runs NSFNET.

For the record, Merit had its class A net number long before it had
even considered running NSFnet.  The network number Merit got for NSFnet 
was a class B net number.

*****************************************************************************
Kraig Meyer                                                kmeyer@wrl.dec.com
On parole from the University of Southern California.     All views expressed
are my own and may or may not be the same as those of Digital Equipment Corp.
-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 22:59:53 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu  (Edward Vielmetti)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
In article <1990Jun14.212630.26295@wrl.dec.com> kmeyer@wrl.dec.com (Kraig Meyer) writes:

   For the record, Merit had its class A net number long before it had
   even considered running NSFnet.  The network number Merit got for NSFnet 
   was a class B net number.

it's also a bit ironic that Merit schools are going to get off of the
class A net number and onto their own class B net(s), at least for
the parts of Merit which will no longer be behind the PDP-11 based
backbone structure (the design which required the class A net in
the first place).   such a shame, I just printed up my Network 35
ID card....

--Ed

Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
"i hear pdp-11's make good flowerpots"
-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      14 Jun 90 23:46:00 GMT
From:      TAYBENGH@NUSDISCS.BITNET
To:        comp.protocols.tcp-ip
Subject:   UDP socket broadcast problem


        I tried to broadcast using UDP socket in Sun OS 4.0.3, sendto() failed
giving error 51 -> Network is Unreachable, is there anything wrong in the
following code segment:

        on = 1;
        if (setsockopt(id, SOL_SOCKET, SO_BROADCAST, (char *)&on, sizeof(on))
            < 0)
           syserr("bs_broadcast: setsockopt")

        if (getsockopt(id, SOL_SOCKET, SO_BROADCAST, (char *)&on, &onlen) <0)
           syserr("bs_broadcast: getsockopt")
        printf("on=%d, onlen=%d\n", on, onlen);

        /*
         * broadcast address
         */
        remote_sock.sin_addr.s_addr = INADDR_BROADCAST; ------> ???
        remote_sock.sin_family = AF_INET;
        remote_sock.sin_port = htons(remote_port);

        size = sendto(id, buf, buflen, 0, (struct sockaddr *)&remote_sock,
                      sizeof(remote_sock));

        --------------------------------------------------------------------

        I suspect it is something to do with the INADDR_BROADCAST, can anybody
please tell me how broadcast UDP properly? Please reply to me directly.
        Thanks.

- Beng Hang Tay (email: taybengh@nusdiscs)

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 01:45:56 GMT
From:      sdd.hp.com!samsung!cs.utexas.edu!texbell!sugar!ficc!peter@ucsd.edu  (Peter da Silva)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
Just for interest sake... would someone on the Internet like to post a list of
the other class A networks. Before any more of them disappear.

I realise it's not likely to be useful to us folks in our little TCP-IP
islands, but what the hell...
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.
<peter@ficc.ferranti.com>
-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jun 90 13:30:38 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        ico!ism780c!mchale!johnan@handies.ucar.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
With all of the ill-maintained systems in this world, would you want a net 10
number for your system?  Let it rest in peace until all other Class A numbers
have been assigned.

As for carving the net 10 address space into additional Class B and Class C
networks, what are the values of the high-order bits of net 10?  As an exer-
cise, explain how you would accomplish this task.  Give examples, if neces-
sary, of what changes you would propose.  If there are any cost impacts, please
identify those costs and provide a plan for recovery of those costs.

You have 2 hours to complete this examination.  Good luck!

Merton
-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 01:51:00 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Mourning of the passing of the ARPANET

In article <9006141247.AA10456@europa.Com>, kasten@europa.interlan.COM (Frank Kastenholz) writes:
> How about officially assigning NET 10 to Interop - then it could be brought out
> of retirement each year for all of the newcomers to look at - sort of like
> the IMP last year.

Great idea, but make it operational.  After all, the conference net
needs a number; call it net 10, and all the private nets can be subnets
of it.

		--Steve Bellovin

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jun 90 09:00:08 PDT
From:      postel@venera.isi.edu
To:        sdd.hp.com!samsung!cs.utexas.edu!texbell!sugar!ficc!peter@ucsd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Class A Networks (was Mourning of the passing of the ARPANET)

Peter da Silva:

See RFC-1117 "Internet Numbers".

--jon.

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 02:26:02 GMT
From:      excelan!keith@ames.arc.nasa.gov  (Keith Brown)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Vote for/against "comp.protocols.iso.migration"

|TCP/IP is NOT popular in Europe.  It doesn't surprise me that its not popular
|in Korea either.  The big reason here is that the PTTs that implement and
|use the networks in Europe are connection oriented.  They wand Virtual
|Circuits.  TCP/IP is a datagram network and is not acceptable.

***Rubbish!***

This is a subject I feel qualified to talk about. I'm English and spent the
last 5 years working for Excelan (the bulk of who's revenue was derived from the
sale of TCP products) providing support and consulting to our customers
all over Europe. If TCP wasn't popular then somebody was playing a very
cruel trick on me giving me so much work to do every day!

Yes the majority of European WAN's are X.25. That's the service that most of
the PTT's offer to their customers. However, you don't have to be
Gypsy Rose Lee to see that numerous commercial and university sites
are using the X.25 service to carry IP packets between remote locations.
In fact, IP routers that operate across X.25 were becoming very popular
when I left.

The work on ISO is a noble effort. However, speaking as network user
who can today, from the single screen and keyboard on my desk, log in to
all the systems that I need to, get transparent access to the same set
of files from almost all of them, non-transparent access from those
that I can't, shunt files from coast to coast at perfectly acceptable
transfer rates *and* send mail to all my colleagues and friends (even
the ones in the UK), I'm left scratching my head as to what powerful new
goodies the ISO folks are going to bestow upon me. Anybody know?

I'll consider migrating/transitioning/whatever my desktop machine the day
I look over someones shoulder and see him/her doing something useful with
ISO protocols that I can't...

Anyway, this will probably be my last posting on the subject as there
are a few engineers not a million miles from where I'm sitting who'll
probably read this and lynch me in the car park....

These are my humble opinions, not Novell's.
----------------------------------------------------------------------------
Keith Brown                                      Phone: (408) 473 8308
Novell San Jose Development Centre               Fax:   (408) 433 0775
San Jose, California 95131                       Net:   keith@novell.COM
----------------------------------------------------------------------------
-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 03:34:15 GMT
From:      brian@ucsd.edu  (Brian Kantor)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  Mourning of the passing of the ARPANET
We held the wake for net 10 at the Usenix conference, and toasted
it well.  We got well toasted ourselves.  A good time was had by all
reminiscing about all the old good times, fun, and hacks that were
inspired by the grandaddy network of them all.

Bye-bye Arpanet - it was swell!

	- Brian
-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 04:45:21 GMT
From:      mips!prls!pyramid!infmx!kwang@apple.com  (Kwang Sung)
To:        tcp-ip@nic.ddn.mil
Subject:   CALL FOR DISCUSSION: comp.protocols.iso.migration

Hi...

	I would like to apologize for my previous incorrect procedures
to create a new newsgroup. I didn't know how to do it. Please discuss at
"news.groups".

	I would like to propose sincerely to create a new newsgroup 
"comp.protocols.iso.migration".  Here is the purpose on creation:

	Since there are many companies who are interested in migration/
transition to OSI without having Internet connection currently, I proposed 
such a newsgroup on USENET. I hope we also can have close relationships with
already existing groups such as X3S3.3 (the ANSI group for network and
transport layers), IETF-OSI, etc.

	This new newsgroup will discuss any technical or non-technical
issues on any protocols/strategies even besides TCP/IP which might be 
helpful to migrate/transit to OSI world. For example, we might be able to
discuss many deficiencies on our U.S. GOSIP.

	As I've mentioned earlier, I am sure this newsgroup will resolve
our networking future, and will give us a right direction to OSI. 

	So, could you discuss more about a new newsgroup "comp.protocols
.iso.migration" so that we can create it in the near future ??

	Thank you for your help !!


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang

-------------------------------------------------------------------------------
Disclaimer: Those opinions are mine alone, not my employers'.
-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      Thu, 14 Jun 90 15:46 H
From:      <TAYBENGH%NUSDISCS.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   UDP socket broadcast problem

        I tried to broadcast using UDP socket in Sun OS 4.0.3, sendto() failed
giving error 51 -> Network is Unreachable, is there anything wrong in the
following code segment:

        on = 1;
        if (setsockopt(id, SOL_SOCKET, SO_BROADCAST, (char *)&on, sizeof(on))
            < 0)
           syserr("bs_broadcast: setsockopt")

        if (getsockopt(id, SOL_SOCKET, SO_BROADCAST, (char *)&on, &onlen) <0)
           syserr("bs_broadcast: getsockopt")
        printf("on=%d, onlen=%d\n", on, onlen);

        /*
         * broadcast address
         */
        remote_sock.sin_addr.s_addr = INADDR_BROADCAST; ------> ???
        remote_sock.sin_family = AF_INET;
        remote_sock.sin_port = htons(remote_port);

        size = sendto(id, buf, buflen, 0, (struct sockaddr *)&remote_sock,
                      sizeof(remote_sock));

        --------------------------------------------------------------------

        I suspect it is something to do with the INADDR_BROADCAST, can anybody
please tell me how broadcast UDP properly? Please reply to me directly.
        Thanks.

- Beng Hang Tay (email: taybengh@nusdiscs)
-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jun 90 11:52:36 EDT
From:      jbvb@vax.ftp.com  (James B. Van Bokkelen)
To:        Frank Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET>
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Mourning of the passing of the ARPANET
	How about officially assigning NET 10 to Interop - then it
	could be brought out of retirement each year for all of the newcomers
	to look at - sort of like the IMP last year.....

	Frank Kastenholz

This is an excellent hack!  I'll second it...

jbvb


-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jun 90 16:21:10 PDT
From:      postel@venera.isi.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Network Numbers (was Mourning of the passing of the ARPANET)

Hey!

We've got more important problems to solve than to hack the address space.

There are about 16,000 class B address of which we've assigned about
2,500, and only 1,600 active nets of all classes in the interconnected
Internet.

--jon.
 
-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 10:44:26 GMT
From:      eru!luth!sunic!mcsun!hp4nl!ruuinf!ruunsa!fysaj!muts@bloom-beacon.mit.edu  (Peter Mutsaers/100000)
To:        tcp-ip@nic.ddn.mil
Subject:   broadcast-like kind of stream socket needed
We want to use broadcasts to transmit a lot of data to many computers
at the same time. I wrote a reliable broadcast routine, using (reliable)
stream sockets for a protocol to ensure delivery of arbitrarely large
blocks of data to all receivers. But alas, sending 100k to one host
in this way was about 8 times slower as with stream sockets, so it would
only be useful with 8 or more receivers. I think it must be possible to
do it much better.
I would like to have a new socket type, that has one connection to one
side, and many to the other side, if you know what I mean.
Does anyone know if something like this has ever been written, or
produced on a lower layer, e.g. using raw sockets?
--
Peter Mutsaers                          email:    muts@fysaj.fys.ruu.nl     
Rijksuniversiteit Utrecht                         nmutsaer@ruunsa.fys.ruu.nl
Princetonplein 5                          tel:    (+31)-(0)30-534504
3584 CG Utrecht, Netherlands                                  
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jun 90 16:10:10 EDT
From:      hal@gateway.mitre.org (Hal Feinstein)
To:        -v@gateway.mitre.org, tcp-ip@nic.ddn.mil
Subject:   Ethernet2 and IEEE 802.3

I've been trying to resolve if 
Ethernet2 can interoperate with
(be on the same cable, talk together) a IEEE 802.3
at the *physical layer*.  I've asked
a number of knowledgeable folk and, while these
discussions were useful, I was left with a range
of answers.  I figure the question 
can't be that hard and someone must have already   
been through this. Roughly, I got these answers:

(1) NO. Both Ethernet2 and IEEE802.3  
can use the same LAN cable system BUT, they cannot
talk (communicate) with each other at the physical layer.

(2) MAYBE. Both (Ethernet2 and IEEE802.3) are very *very*
close (at the physical layer) and maybe functionally 
equivalent.  They SHOULD be above to interoperate and 
coexist on the same cable.

(3) YES. Of course they can. They are a little different
(IEEE802.3 physical layer has a heartbeat and one or two
optional signals) but YES, they can interoperate and 
coexist on the same cable.  

Are any of these the correct answer? SUN seems
to support both physical layers from a single interface. So
I assume that (3) is correct. Am I right?
 
-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 12:31:23 GMT
From:      eru!luth!sunic!mcsun!hp4nl!ruuinf!ruunsa!fysaj!muts@bloom-beacon.mit.edu  (Peter Mutsaers/100000)
To:        tcp-ip@nic.ddn.mil
Subject:   Why is broadcast so much slower?
When I do a sendmsg() or sendto() on a datagramsocket, the system CPU-time
increases by a factor of ten, on several computers, if I write to a
broadcast address instead of to a single address.
I did ask permission to broadcast on the socket.

Does anyone have an idea why broadcasting is about 10 times as slow,
and maybe know a method to broadcast without so much overhead?
--
Peter Mutsaers                          email:    muts@fysaj.fys.ruu.nl     
Rijksuniversiteit Utrecht                         nmutsaer@ruunsa.fys.ruu.nl
Princetonplein 5                          tel:    (+31)-(0)30-534504
3584 CG Utrecht, Netherlands                                  
-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 14:24:41 GMT
From:      scamp.concert.net!jrr@mcnc.org  (Joe Ragland)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET

In article <9006141247.AA10456@europa.Com>, kasten@europa.interlan.COM
(Frank Kastenholz) writes:
|> How about officially assigning NET 10 to Interop - then it could be
brought out
|> of retirement each year for all of the newcomers to look at - sort of like
|> the IMP last year. 

Yea, maybe in good ham radio DXpedition style,  Dan Lynch could issue a
certificate for exchanging mail with a net 10 host at Interop?
-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 14:38:50 GMT
From:      ico!ism780c!mchale!johnan@handies.ucar.edu  (John Antypas)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
In article <9006141247.AA10456@europa.Com> kasten@europa.interlan.COM (Frank Kastenholz) writes:
>
>How about officially assigning NET 10 to Interop - then it could be brought out
>of retirement each year for all of the newcomers to look at - sort of like
>the IMP last year. Maybe during the "off season" Interop could keep 2 PC's
>running in a backroom on some Ethernet, pinging each other - on NET 10.
>
A nice idea, but with all of the talk about address spacing becoming
hard to find, the idea of re-using 10 as a Class A, or splitting it into
256 class B's needs to be considered.  That's a lot of new customers
for Internet.  Consider that net is over 65535 class C spaces!  Do we
want to give Interop 16x10^6 addresses!

John Antypas / Interactive Systems Corp.
uucp: ...!uunet!ism.isc.com!johnan    Internet: johnan@ism.isc.com
All statements above responsability of the author.
-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Fri, 15 Jun 90 20:32:35 EDT
From:      Rob Austein <sra@lcs.mit.edu>
To:        TCP-IP@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
   Date: 5 Jun 90 19:16:59 GMT
   From: stev@VAX.FTP.COM

   i know alot of people who have used the ITS systems at MIT. i never recall
   them telling me of problems with people "breaking in" and damaging
   something. what security ITS had was based on obsurity. i would like to hear
   from some of the ITS wizards about how security-through-obscurity wrked for
   them. 

It seems that at one point during his romp, Cliff Stoll's "Hanover
Hacker" made his way onto MX.LCS.MIT.EDU (Cliff calls it the "MIT MX
Computer").  According to Cliff, the guy spent about two hours poking
around before giving up.  His net accomplishment during that time was
to figure out how to list one of the GUESTn directories.  I don't
think he got as far as listing the contents of files.  The ITS command
processor is a little, er, eccentric.

--Rob Austein
-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 17:14:24 GMT
From:      merlyn@iwarp.intel.com (Randal Schwartz)
To:        comp.protocols.tcp-ip
Subject:   Re: Mourning of the passing of the ARPANET

In article <43957@ism780c.isc.com>, johnan@mchale (John Antypas) writes:
| A nice idea, but with all of the talk about address spacing becoming
| hard to find, the idea of re-using 10 as a Class A, or splitting it into
| 256 class B's needs to be considered.  That's a lot of new customers
| for Internet.  Consider that net is over 65535 class C spaces!  Do we
| want to give Interop 16x10^6 addresses!

Finding 65535 class C-type customers that all wanted to have their
nets adjacent and one naming authority is a bit much.  There isn't any
way in the current software (pardon my ignorance if there is) to have
non-adjacent subnets.  You can only have "route to net 10" not "route
to 10.11.23", unless you happen to have interfaces that are current
net 10 subnets.

Just to throw my vote in the ring, I don't know who Interop is, but if
they had something to do with the early net, let'em have the number.
By the time we need the 126'th class A address, we'll be hurting in
other ways. :-)

Just another net hacker,
-- 
/=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\
| on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III      |
| merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn |
\=Cute Quote: "Welcome to Portland, Oregon, home of the California Raisins!"=/

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 17:20:49 GMT
From:      usc!snorkelwacker!paperboy!meissner@ucsd.edu  (Michael Meissner)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
In article <43957@ism780c.isc.com> johnan@mchale.ism.isc.com (John
Antypas) writes:

| In article <9006141247.AA10456@europa.Com> kasten@europa.interlan.COM (Frank Kastenholz) writes:
| >
| >How about officially assigning NET 10 to Interop - then it could be brought out
| >of retirement each year for all of the newcomers to look at - sort of like
| >the IMP last year. Maybe during the "off season" Interop could keep 2 PC's
| >running in a backroom on some Ethernet, pinging each other - on NET 10.
| >
| A nice idea, but with all of the talk about address spacing becoming
| hard to find, the idea of re-using 10 as a Class A, or splitting it into
| 256 class B's needs to be considered.  That's a lot of new customers
| for Internet.  Consider that net is over 65535 class C spaces!  Do we
| want to give Interop 16x10^6 addresses!

I suspect you will either have a massive flag day or lots of systems
that will refuse to talk to the proposed carved up addresses.  I
thought there were only ~30-40 class A networks, out of ~126 possible
class A network numbers.  I also seem to remember dimly that class E
network numbers which are not used, were mentioned as means of adding
massive new network numbers.
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA

Catproof is an oxymoron, Childproof is nearly so
-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 17:25:59 GMT
From:      usc!samsung!interlan.InterLan.COM!interlan.interlan.com!towfiq@ucsd.edu  (Mark Towfigh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Vote for/against "comp.protocols.iso.migration"
In article <4488@infmx.UUCP> kwang@infmx.UUCP (Kwang Sung) writes:

	   Now I would like to finalize my proposal on creation of a new
   newsgroup "comp.protocols.iso.migration".

Gaah!

	   Here is a list of all persons who have responded to my postings 
   [.....]
	   Obviously, majority wanted to create such a newsgroup on USENET.
   Among 54, 30 said "Yes", 17 said "No", and 7 were not clear.

I think this may have been proper procedure in 1982.

   [.....]
	   So, could you create a new newsgroup "comp.protocols.iso.migration"
   as soon as possible so that we can discuss seriously and aggressively,
   and nobody can bother either "comp.protocols.iso" or "comp.protocols.tcp-ip"
   any more ??

Bother the people directly involved in this issue?

   Persons who have responded to my proposal so far:
   [list deleted]

This is ridiculous.  Comp.protocols.iso *maybe* had about two articles
a day in it before this "proposal" came up, and it jumped to a
whopping five after that.  I see *no reason* for the creation of a new
newsgroup, especially since the normal procedures for group creation
have been disregarded, or garbled at best.

Kwang: read news.announce.newusers.  I think you would probably
realize from there that there is *no need* for an ISO migration group;
relevant articles can just be crossposted to
comp.protocols.{iso,tcp-ip}.

Mark
--
Mark Towfigh, Racal InterLan, Inc.                 towfiq@interlan.Interlan.COM
W: (508) 263-9929 H: (617) 488-2818                       uunet!interlan!towfiq

  "The Earth is but One Country, and Mankind its Citizens" -- Baha'u'llah
-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 19:27:50 GMT
From:      netwrx1!mindel@uunet.uu.net  (Joshua L Mindel)
To:        tcp-ip@nic.ddn.mil
Subject:   UUCP (AT&T BNU) over STREAMS-based TCP/IP/(Ethernet,X.25)

Initial part of question:
-------------------------
Does anyone have experience with setting up uucp (AT&T BNU) files on 
AT&T 3B2s for a STREAMS-based network?  In particular, for AT&T Enhanced 
TCP/IP WIN/3B Release 3.0 over Ethernet and X.25.

Background:
-----------
I'd like to configure BNU files (on AT&T 3B2s with UNIX System V Release 3.2.2)
so that uucp and cu requests both go through login to connect over an Ethernet
and X.25 network.

Section 9.6 of the AT&T 3B2 Computer UNIX System V Release 3 Sys Admin guide 
provides guidelines for setting up uucp on a STREAMS-based network.  An example
procedure is included for uucp on the AT&T STARLAN network, with the qualifier 
that a similar procedure could be applied for setting up uucp to run on a 
transport provider that is compatible with the AT&T Transport Interface (TLI).

The WIN/3B TCP/IP Release 3.0 product is a transport provider compatible with 
TLI.

After scouring the AT&T Sys Admin guide, WIN/3B docs, and talking with 
Wollongong, I came to realize that there is one critical piece missing from
this picture; the STREAMS module(s) providing the interface between the TTY 
server and TCP.  Using AT&T's terminology for describing the software 
components of a uucp-over-STARLAN configuration, these STREAMS modules are
called Remote Login Modules.  For uucp over STARLAN, these STREAMS modules are 
called LDO and NTTY.

Final part of question:
-----------------------
Do these remote login modules exist for TCP/IP?  If yes, how and where can
I obtain them?

Further clarification of question:
----------------------------------
Leaning heavily on the definition used within the STARLAN environment, I presume
the precise function of these missing modules can be stated as follows:

The remote login modules are the software modules that act as an interface
between the TCP modules and the remote login services provided by the TTY
server.  These modules provide the UNIX character processing and read/write
interface of the standard TTY driver.  This allows existing UNIX TTY
services ("sh", "cu", etc.) to operate over the TCP/IP network.

Paper references for this note:
-------------------------------
 WIN/3B TCP/IP Install/Admin Guide : pages 1-20 to 1-23
 AT&T STARLAN User's Guide	   : pages 4-3 to 4-4

------------------------------
Thanks in advance.

-- 
-------------------------------------------------------------------------------
Joshua L Mindel, Senior Analyst		Internet:  mindel%netwrx1@uunet.uu.net
NetWorks One				Usenet:	   uunet!netwrx1!mindel
Vienna, VA				Phone:     (703) 827-7767
-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 20:25:06 GMT
From:      intercon!news@uunet.uu.net  (Amanda Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
In article <2339@speedy.mcnc.org>, jrr@scamp.concert.net (Joe Ragland) writes:
> Yea, maybe in good ham radio DXpedition style,  Dan Lynch could issue a
> certificate for exchanging mail with a net 10 host at Interop?

I'm beginning to like this idea more and more...

It could also be fun to give the show backbone routers "historically
significant" IMP names, so that you could do traceroutes and so on...

--
Amanda Walker, InterCon Systems Corporation
--
"Y'know, you can't have, like, a light, without a dark to stick it in...
 You know what I'm sayin'?"     --Arlo Guthrie
-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 20:41:14 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: How long before I can reopen a closed socket?

In article <515@seqp4.UUCP>, markr@seqp4.ORG (Mark Roddy) writes:
> The solution is to not use the well known address for the connection -
> TCP allows you to accept a connection on a different port address than
> the destination address in the connection request.
> 
> This is the mechanism used by most *nix TCP/IP services. 
> 
> The well-known address is always available to service the 
> next incoming connection request.

No, that's not quite correct.  A TCP connection is defined by the
4-tuple <localhost,localport,remotehost,remoteport>.  Servers define
the first two parts -- on Berkeley-derived systems, via the bind() call.
When a client connects, a connection is instantiated with a fixed
pair of values for <remotehost,remoteport>.  The server's partial
connection -- or rather, the under-specified TCB for its passive
open -- can still exist; that's an implementation issue.

What happens on Berkeley-derived systems is that you get a new file
descriptor in the server for each connection; the port numbers
don't change.  However, the kernel will not let you bind even a
server port if any TCBs exist with the same <localhost,localport>
portion, even if all of the others have <remotehost,remoteport>
filled in.  You can override this via setsockopt() with the
SO_REUSEADDR option.  Inetd does exactly that.

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      15 Jun 90 22:21:21 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!dkuug!freja.diku.dk!skinfaxe.diku.dk!thorinn@ucsd.edu  (Lars Henrik Mathiesen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How long before I can reopen a closed socket?
markr@seqp4.ORG (Mark Roddy) writes:

>In <4847@litle.litle.COM> tom@litle.litle.COM (tom hampton) writes:
>>2) We are using a "well known address" and these things don't recycle
>>   instantly after closing (just a wild guess...)

>In fact you must wait:

>	CHORUS: Two Times the Maximum Segment Lifetime!

>Which is the minute or two you describe.

>The solution is to not use the well known address for the connection -
>TCP allows you to accept a connection on a different port address than
>the destination address in the connection request.

>This is the mechanism used by most *nix TCP/IP services. 

This turns out not to be the case, at least in the Berkeley
implementation of TCP/IP (also known as Berkeley sockets). This is
what happens: The server process creates a socket and uses bind(2) to
associate it with the well known port number for its service. However,
a socket has two address/port pairs, one local and one foreign.
Bind(2) only sets the local part, so that the socket will accept
connections from any client. (Each client uses connect(2) to set the
foreign part on its socket and make a connection).

When a connection is established, a new socket is created and passed
to the server process (returned from accept(2)). This new socket has
its foreign address part set to the client's.

When a TCP connection ends, the party which sends the last packet in
the protocol (the FIN ACK) has to wait a short time after that to see
if it was lost (if so, the other party resends its last packet, the
first sends FIN ACK and waits again). That's your minute. Note that
its the party that closes first that gets to wait.

When you try to start a new server, it has to bind(2) the same
address. The system will not allow that if there an existing protocol
control block conflicts with the address. In 4.3-tahoe, conflict is
defined as follows:
	A) The address pairs are the same. In UNIX, this may happen if
some server subprocesses haven't closed the original socket descriptor
(Berkeley rlogind, e.g.).
	B) The new address pair would match some packets which
``belong'' to an existing control block. In 4.3-tahoe, this test is
not performed if either
		1) SO_REUSEADDR has been set with setsockopt(2) or
		2) listen(2) has been called on the socket and the
protocol is connection-oriented (as TCP is). If the test is done,
server-client connections in the wait state will block the bind(2),
even though the file descriptor has been closed.

So: Check if all child processes of the server have gone away; if not,
take care that they close the original socket before they start
processing. Also, call listen(2) before bind(2) if your implementation
allows it, otherwise set SO_REUSEADDR (ditto), otherwise complain to
your vendor.

It is strange that the 4.3 IPC tutorials all show the use of bind(2)
before listen(2), when the kernel works ``better'' with the opposite
order.

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      thorinn@diku.dk
-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 90 02:24:01 GMT
From:      rogue.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ethernet2 and IEEE 802.3
In article <9006152010.AA15384@gateway.mitre.org>, hal@GATEWAY.MITRE.ORG (Hal Feinstein) writes:
> 
> I've been trying to resolve if 
> Ethernet2 can interoperate with
> (be on the same cable, talk together) a IEEE 802.3
> at the *physical layer*.  I've asked
> [Text deleted]

3 is correct. There is a difference between SQE and heartbeat, but those are
really specific to transceivers, not the media. In any case, they certainly do
operate on the same cable.

I understand that interoperation on a common physical layer was a requirement
for the 802 committee.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 90 02:28:54 GMT
From:      portal!cup.portal.com!thinman@apple.com  (Lance C Norskog)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP reliability
jvbv@ftp.com says:

> In my personal experience (which includes supporting a lot of TCP/IP
> nodes), I have only had one report of undetected data corruption in
> TCP (a transposition caused by a device driver bug while transferring
> a very repetitive raster file).  The combination of TCP and IP on
> SLIP seems fairly robust in practice: For two years our Internet link
> was leased-line SLIP, and I am using dial-up SLIP to send this, and
> I've never seen an error that got past the checksum.  This may be
> because there is a good match between the errors asynch lines tend to
> generate and those the checksum is likely to detect.

2 points: 
	1) If your NFS uses WD cards or any other card based on the National
chip set and does not use UDP checksums, you will get file data corruption
big-time.  The National 8390 Ethernet chip likes to randomly add and drop
bytes when copying twixt RAM and Ethernet; this is, of course, outside the 
enforcement range of the Ethernet checksum.

	2) If your SL/IP tosses packets when the hardware gives framing
or lost-byte errors, SL/IP should be very reliable.  If you run SL/IP over
modems, be sure to use MNP or some other error-corrected protocol.  These 
modems are so cheap that it's pointless running on a raw one.

Lance Norskog
Sales Engineer
Streamlined Networks
408-727-9909
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Sat, 16 Jun 90 09:18:55 EDT
From:      Hans-Werner Braun <hwb@merit.edu>
To:        list@merit.edu
Subject:   NSFNET Expansion and T3 upgrades.
Subject: NSFNET Expansion
Date: Wed, 13 Jun 90 16:52:04 EDT
From: Douglas Gale <dgale@note2.nsf.gov>

NSF creates worlds fastest openly available network for 
research and education.

The National Science Foundation (NSF) has announced a $7.9 
million expansion of its nationwide computer network,  the 
NSFNET.  In addition to adding three new nodes or connections 
to the backbone of the NSFNET, data transmission speed on 
several key links of the existing network will be increased to 
45 million bits of information per second to create the world's 
fastest openly available network for research and education.

The sites that will be linked by the higher speed connections are 
Cambridge, Massachusetts, Ithaca, New York, Pittsburgh, 
Pennsylvania, Ann Arbor, Michigan, Urbana-Champaign, Illinois, 
Argonne, Illinois, San Diego, California, and Palo Alto, California.  
The technology used to support the higher transmission speeds will 
support the development of the proposed very high speed National 
Research and Education Network (NREN).

The new nodes on the NSFNET backbone network will be located 
at the Massachusetts Institute of Technology in Cambridge, 
Massachusetts, Argonne National Laboratory in Argonne, 
Illinois, and Georgia Institute of Technology in Atlanta, 
Georgia.  The Cambridge node will connect the New England 
Academic and Research Network, NEARnet, to the NSFNET.  In 
addition to providing connections to Argonne National 
Laboratory, the Argonne node will provide additional 
connections to CICnet which serves institutions in the upper 
Midwest.  The Atlanta node will provide additional connections 
to the Southeastern University Research Association Network, 
SURAnet.

The new sites will augment the existing 13 nodes which 
connect mid-level networks to the network backbone.  The 
mid-level networks in turn link computers in more than 1,000 
university, government and industrial research institutions 
throughout the world.

"The network is used to access resources such as 
supercomputers, libraries, and satellite data, as well as to 
link geographically dispersed researchers, educators, and 
scholars," according to Dr.Stephen Wolff, Director of the 
Division of Networking and Communications Research and 
Infrastructure at the National Science Foundation.

The NSFNET backbone network is managed and operated by the 
Merit Computer Network from its state-of-the-art network 
operations center on the campus of the University of Michigan 
in Ann Arbor, Michigan, as part of a cooperative agreement 
with NSF. Merit's partners in the project include IBM 
Corporation, MCI Communications Corporation, and the State of 
Michigan through its Strategic Fund.  MCI Communications 
Corporation will provide advanced circuit switching 
technology for the expansion capable of a twenty-eight fold 
increase in current backbone transmission speed.  IBM 
Corporation will deploy a new generation of technology to take 
advantage of the increased capacity of the expanded network.


-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 90 07:46:07 GMT
From:      cca.ucsf.edu!wet!sue@cgl.ucsf.edu  (Sue Miller)
To:        tcp-ip@nic.ddn.mil
Subject:   RCP sources/info wanted
Hi, I'm looking for publicly available source for a RCP (remote copy program)
to transfer files from a UNIX host under TCP/IP protocols.  Either a socket or
other implementation would be useful.  I'm trying to put a copy function within
the body of another program.

Any communication on this subject would be welcome - my uucp address
is  ...!sun!hoptoad!wet!sue.  Thanks!

Seth Olitzky
Louth Systems
(415) 329-9498
-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jun 90 00:08:02 PDT
From:      ho@la.tis.com (Hilarie K. Orman)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Mourning of the passing of the ARPANET
Networks whose response was lame,
And the packets dropped, before the name.

Do not ask for whose net the ^G tolls ...


  Hilarie Orman (ho@la.tis.com)
-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jun 90 06:59:04 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        postmaster@cup.portal.com, postmaster@sun.com, tcp-ip@nic.ddn.mil
Subject:   My Cup Overfloweth
What's with this:

        sun!portal!cup.portal.com!sun!portal!cup.portal.com!
        sun!portal!cup.portal.com!sun!portal!cup.portal.com!
        sun!portal!cup.portal.com!sun!portal!cup.portal.com!
        sun!portal!cup.portal.com!sun!portal!cup.portal.com!
        ...

I'm beginning to prefer the discussion on our collective short-sightedness
for not having ten blind men define the Internet protocol suite for DARPA
and being so destitute that we can't afford to follow the one, true Faith.

If there are any PAC*BELL readers of this group, a slip down the racks and
a sudden, unscheduled service outage would not go unappreciated.

Merton

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 90 19:24:33 GMT
From:      van-bc!sl@ucbvax.Berkeley.EDU  (Stuart Lynne)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP reliability
In article <30819@cup.portal.com> thinman@cup.portal.com (Lance C Norskog) writes:
>	2) If your SL/IP tosses packets when the hardware gives framing
>or lost-byte errors, SL/IP should be very reliable.  If you run SL/IP over
>modems, be sure to use MNP or some other error-corrected protocol.  These 
>modems are so cheap that it's pointless running on a raw one.

There are other issues. When you turn MNP on you increase (the already bad)
latency of packets traversing the link.

We run SLIP over a V.32 modem (T2500). We could turn on the reliable mode,
but find we get better performance if we don't. 

-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 
-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      16 Jun 90 21:07:18 GMT
From:      news@intercon.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Motrning of the parsinf of the ARP@NET

In article <2339@rpeedy.mbnc.org>, jrr@scamp.boncert.ndt (Joe Ragland( writes:
> Yea, maybe in good h`m radio DXpedithnn rtyle,  Dan Lynch could hssud a
> certifhcatd for exbhanfing mail with a net 10 host at Interop?

I'm befinnhng to like this ide` more and more...

It could also be fun to five the shov backbond routers "historically
significant" IMP nales, so that you could do tracernutes and so on...

--
Amanda Walker, InterCnn Systems Corporatinn
--
"Y'knov, you can't have, lhke, a light, without a dark to stick it in...
 Ynu know what I'm sayin'>"     -,@rln Guthrid

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jun 90 12:28:48 -0700
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        tcp-ip@nic.ddn.mil
Subject:   Computer Project Would Speed Data
Computer Project Would Speed Data 


NY Times, Friday, June 8, 1990

Businesses, Schools and U.S. Agencies to Join in Effort

By JOHN MARKOFF

The National Science Foundation plans to announce today that a large  
group of the nation's leading communications  and computer companies  
universities  and research laboratories and several Government agencies  
will begin development of a high-speed network that will allow computer  
data to be transmitted at speeds almost 700 times faster than possible  
over existing networks. It would be the first comprehensive attempt in  
the United States to advance the critical technological area of computer  
networks and is being called an important model for cooperation between  
business and government.

The widespread support for the computer network project stands in sharp  
contrast to the reception received by other recent cooperative projects  
in high technology such as the effort to finance research in high- 
definition television and the joint venture known as U.S. Memories, that  
was intended to strengthen the United States in the semiconductor  
business. Those projects have foundered for lack of money or enthusiasm  
among Government and business. In Japan, the government and large  
corporations have already begun work on high-speed computer networks,  
known as data highways, that enable the transmission of the equivalent  
of about 160 hefty novels every second compared with only about two  
novels every second in even the fastest networks today.

By conveying so much data so quickly, using the same optical-fiber  
cables now used by some long-distance telephone carriers, high-speed  
computer networks hold the promise of many new scientific and commercial  
uses , that could be available by the middle of this decade. These  
include the ability to transmit to and receive data from a hybrid of  
television and computer. The new device would have a picture and sound  
of movie-like quality and the capacity to allow the viewer to manipulate  
the images and data displayed on the screen and instantaneously exchange  
the information with other users.

Other potential uses that could evolve from the new project include  
three-dimensional medical imaging that allows doctors thousands of miles  
apart to analyze lifelike, high- resolution images; far more accurate  
understanding and prediction of weather and climate because of the  
ability to link the power of supercomputers around the country, and  
multimedia teleconferencing that would combine video images and computer  
data, allowing business meetings without the need to travel.

$100 Million From Companies

The data network is being initiated with $15 million from the National  
Science Foundation and from a Pentagon agency that has financed research  
in basic technology. But more than $100 million will come from  
companies. including the International Business Machines Corporation and  
the American Telephone and Telegraph Company, during the three-year  
project, executives at the foundation said.

The venture "marks an important step forward," said Robert B. Reich, a  
Harvard University economist. "There are a host of technological areas  
in which the United States is falling behind to which this model might  
be directly applicable if it means developing skills and insights in new  
technological areas," he said.

The computer-network project will draw together dozens of corporations  
and universities, including I.B.M. AT.&T., the MCI Communications  
Corporation, the regional Bell telecommunications companies and  
universities including the Massachusetts Institute of Technology, the  
University of Pennsylvania, the California Institute of Technology and  
the University of California at Berkeley. Government laboratories  
including those in Los Alamos, N.M., and Livermore, Calif. and the  
nation's five supercomputer centers will also participate.

A Pioneer's Brainchild

The project is the brainchild of Robert E. Kahn, a pioneer of the  
nation's first computer network experiment, called Arpanet, and David J.  
Farber, a computer scientist at the University of Pennsylvania. Mr. Kahn  
is president of the Corporation for National Research Initiatives, a  
computer technology research group in Reston, Va., that will receive the  
Government grant expected to be announced today.

Mr. Kahn was director of computer science research at the Defense  
Advanced Research Projects Agency, the Pentagon agency participating in  
the project. Mr. Kahn said that he would not comment on the project  
until it had been formally announced by the National Science Foundation.

Computer scientists said significant technical challenges remain to  
allow the transmission and reception of computer data at speeds above a  
billion bits per second, a goal of the new network.

Transmitting computer data is clone in a way similar to the way mail has  
traditionally been sorted in post offices, said William A. Wulf, a  
computer scientist at the University of Virginia. Postal employees read  
addresses and place envelopes in particular slots.

Similarly computer networks break data into packets, send them as  
strings of digital signals and then sort them when they arrive at their  
destination. The problem with very high speed networks, said Dr. Wulf,  
is that even the fastest machines that serve as gateways between the  
data highway and the computers they connect are not able to keep up with  
the stream of 1's and 0's possible with new networks. The challenge is  
therefore to develop a new class of ma- chines to serve as gateways.

The development project consists of five experimental networks.

The effort represents the first phase of a multi-year endeavor that  
supporters hope will ultimately create the national data highway.

Project developers said they are still uncertain about the cost of  
deploying a nationwide high-speed network. It is possible, they contend,  
that the rapidly increasing technology of long-distance optical-fiber  
networks may generates a surplus in capacity, permitting low-cost  
delivery of data and digital video services.

Support of Gore

"This represents a great example of how industry and government can work  
together to develop a key technology needed for the effective use of a  
national network of data super- highways soon to put in place," said  
Senator Albert Gore Jr., Democrat of Tennessee. "It's not a huge amount  
of money but if it will provide a great many useful applications for the  
network."


Senator Gore has introduced legislation that would finance the cost o  
developing a high-speed compute network to link the nation's super  
computer centers.

The Bush Administration has said it supports a national high-speed  
computer network but has not committed to backing new financing for the  
project.

One scientific project that will rely on the network will link a radio  
telescope array at the University of California at Berkeley with a Cray  
II supercomputer at the National Center for Supercomputer Applications  
in Champagne-Urbana, ILL., and computer work stations at the University  
of Maryland. Such a network would permit astronomers to use radio  
telescopes interactively in ways never before possible, said Larry  
Smarr, director of the supercomputer center.

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      17 Jun 90 04:17:27 GMT
From:      dhc@lanl.gov  (Dave Carter)
To:        tcp-ip@nic.ddn.mil
Subject:   Networking RT11

i have some micro pdp11/23's running rt11 which collect large amounts
of data, which i then transfer to our file server, a microvax II
running ultrix.  this part of our network is running tcp/ip.
currently i am using a pc as the console for the pdp, and i have to
kermit the files from the pdp to a drive on the pc which is actually
on the file server - the pc is running pc/tcp/nfs. (funny how i have
to use an ibm to get two pieces of dec equipment to talk to each 
other :-) kermitting the files is getting tedious, and i would like
to be able to store the files directly on the file server.

i know that rt11 does not support decnet over ethernet, so my question
is this: does anyone have a simple solution with a tcp/ip network?  is
there an nfs-type solution?  (i would like to get rid of rt11, but
that is not a possibility.)

							- dave
dhc@lanl.gov
-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jun 90 17:09:22 EDT
From:      stev@vax.ftp.com
To:        tcp-ip@nic.ddn.mil
Subject:   more to argue about . . . . . .

i mean, hey, life is *too* short, right?


last monday, at the router requirments working group, we discussed subnet
bits. we discussed what we would require a router to support. there is talk
about variable lenght subnet bits. there is talk about someone writing an
RFC on such things. if you are out there, please mail to me. we also talked
about non-contigious subnet bits. we were not sure that anyone was using
non-contigious subnet bits. there does seem to be strong interest in
variable lenght subnet masks, though.


so, where is the arguement, you ask? i mean, you *know* i am getting there,
right? 

router requirments is thinking of requiring support for variable lenght
subnet bits, but explicitly saying that a router does not have to implement
non-contigious subnet bits (MAY in host requirments parlance).


he ya go, campers. anyone wish to rise up and define a good reason to keep
non-contigious subnet bits, assuming we require the ability to have more
than one address on an interface . . . . . .

your input on this matter is most appreciated.

stev knowles
stev@ftp.com
617-246-0900

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Jun 90 23:55:01 MDT
From:      cpw%snow-white@LANL.GOV (C. Philip Wood)
To:        tcp-ip@nic.ddn.mil
Subject:   The Portal System (TM)

I'm tired of it.

Phil Wood
-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 00:24:50 MDT
From:      cpw%snow-white@LANL.GOV (C. Philip Wood)
To:        tcp-ip@nic.ddn.mil
Subject:   Who would mourn the passing of the Portal System (TM)?

Not me.

Phil
-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 09:49:07 -0700
From:      jqj@rt-jqj.Stanford.EDU
To:        stev@vax.ftp.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: router requirements (was: more to argue about)

Steve Knowles suggests that variable length subnet masks should be a
requirement while non-contigious subnet bits should become a MAY in the new
router requirements.  This may not be an issue that needs to be addressed on
the general TCP-IP list; however, since it has been raised:

I believe such a change in policy is premature.  In general, I believe that
changes in basic Internet requirements should be made with caution, since each
change has major significance for all the vendors who try to track the IP
suite, and each change decreases our credibility as a stable networking
platform.  Of course, we have to make necessary changes...

I don't see much wrong with dropping the requirement for support of
non-contiguous masks.  Granted, this feature has been enshrined in code and
standards for years, but few sites actually use it, and some existing IP
protocols (notably the new DNS network number stuff and OSPF) break it.  I'm
all for simplicity.

However, the other proposed change is one whose time has not yet come.  No
standard reachability protocol currently supports variable length subnets, and
only one of the competing routing protocols does so (if and when OSPF becomes
a required standard, that will change things!  Does the router requirements
working group propose to require OSPF also?).  Realistically, it will be a
long time before most vendors of products that do routing are ready to support
OSPF (concrete and important example: Shiva FastPath); a warning that this is
the intended direction of the Internet is appropriate now, but a requirement
is not.

Conclusion:  make variable masks a SHOULD, not a MUST.  Make OSPF a SHOULD
too.
-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 12:01 -0700
From:      <chao@cs.sfu.ca>
To:        morrison%thucydides.cs.uiuc.edu%ux1.cso.uiuc.edu%uwm.edu%zaphod.mps.ohio-state.edu%swrinde.uucp@ucsd.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  PCroute 2.1 release out

I got 'permission denied' when I was trying ftp for PCroute2.1.

Chao@cs.sfu.ca
-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 06:11 EST
From:      VGCHAC <0003786240@mcimail.com>
To:        TCP-IP Interest Group <TCP-IP@nic.ddn.mil>
Cc:        "Prof. Frank Vanacek" <802-485-2580%FAX@mcimail.com>
Subject:   

Subject: Voice Recognition Conference


In the absence of knowledge of other distribution lists
more appropriate, I am taking the liberty of posting this
conference notice on TCP-IP at the request of the conference
organizers.

Vint Cerf

-------

        VOICE RECOGNITION CONFERENCE

August 22-24, 1990
Stowe Flake Inn
800-782-9009
Stowe, VT 05672


The conference is sponsored by the Weschester County Chapter
of the ACM and organized by:

   Prof. Frank Vanacek         Prof. Walter Kosinsky
   Norwich University          Cybertree, Inc.
   Northfield, VT 05663        RFD #1
   FAX: 802-485-2580           Wolcott, VT 05680
   TEL: 802-485-2205

Topics:

  Recognition algorithms
    speech units, language model, spoken language understanding

  Applications

  Feature Extraction (e.g. metrics)

  Recognition database (creation, maintenance, search)

  Speaker training/adaptation

  Unique hardware devices


Conference registration fees:

  $65 for non-ACM members
  $55 for ACM members (note your member number)
  $45 for students

All fees due and payable in US currency before conference
and are non-refundable

Provisions for demonstration equipment at Stoweflake Inn
can be provided - must arrange with Prof. Kosinsky or
Prof. Vanacek in advance.

A 1 page abstract should be mailed or faxed to Prof. Vanacek.
Papers should be limited to 10-20 pages total.


-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 08:40:10 MST
From:      loa@nddsun2.sps.mot.com (Kanchei Loa)
To:        tcp-ip@nic.ddn.mil
Subject:   add to mailing list
  Please add me to the tcp/ip mailing list.

Thanks


Kanchei Loa
Email: loa%motsps@uunet.uu.net
Phone# 602-8975122
Software Engineer/Networking
Network Design & Development
Semiconductor Products Sector
Motorola Inc.
-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 08:41:43 PDT
From:      <tep@tots.Logicon.COM>
To:        postmaster@cup.portal.com, root@cup.portal.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   more important things to do (was Network Numbers (was Mourning of the passing of the ARPANET))
   From: hamachi!Sun.COM!portal!cup.portal.com!sun!portal!cup.portal.com!sun!venera.isi.edu!portal!
   Lines: 11
   Date: Sat, 16-Jun-90 23:07:41 PDT
   X-Origin: The Portal System (TM)
   X-Possible-Reply-Path: sun!portal!cup.portal.com!sun!venera.isi.edu!portal!
    cup.portal.com!postel@cup.portal.com
   X-Possible-Reply-Path: sun!portal!cup.portal.com!sun!portal!cup.portal.com!
    sun!venera.isi.edu!portal!cup.portal.com!postel

Could you *PLEASE* DO SOMETHING ABOUT THIS!!!!!!!!!!!!

Sorry to yell, but its been going on for a while.

I had 20+ copies of each and every tcp-ip message for the last several
days. Its not nice to put over 300 messages into people's mailboxes.

note to tcp-ip'ers: can I claim a record for most-abused (most
overstuffed) mailbox ?? :-(

How about a new RFC: "A Protocol For the Remote Disabling of
Mis-configured Mailing List Exploders and Aliases By Hardware
Detonation".

Nuke 'em 'til they glow, shoot 'em in the dark.

Tom Perrine (tep)                       |Internet: tep@tots.Logicon.COM
Logicon                                 |UUCP: nosc!hamachi!tots!tep
Tactical and Training Systems Division  |-or-  sun!suntan!tots!tep
San Diego CA                            |GENIE: T.PERRINE
"Harried: with preschoolers"            |+1 619 455 1330
-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 02:08:25 GMT
From:      RW.OUNDY@IBM.COM ("Rich_Woundy"_@cup.portal.cnm@cup.portal.com@cup.portal.com@cup.portal.com@cup.port, al.com)
To:        comp.protocols.tcp-ip
Subject:   IP Addresses (Subnets)


 >Frol: sdd.hp.com!uakari.primate.wisc.edu!ark1!vnlleydog!rhott@ucsd.edu (The
 >VolleyDog)
 >Subject: IP Addresses (Subnets)
 >I have a quick question, hopefully you will not flame to loudly with
 >regard to  viewhng RFCs.  I looked through RFC 850 to try tn determine
 >how to specify a host when using a subnet.  In my particular instance e
 >have a class B network.  I al interested in how nne vould specify
 >addresses when a subnet nf 6 bits is used.
 >
 >Ruppose H want the 300th host on the 1 subnet of a class B network wit
 >a netmask of 255.255.252!  Should I specify the IP address as
 >128.38.1.300 or 128.38.253.44
 >
 >I guess my overall question hs:  Should I specify the addresring using
 >the 3rd octet field in the dot notation as the subndt or as the 3rd
 >octet of the 22 bit field>
 >
 >Thanks,
 >  Bnb Hott
Bob,
   Per RFC 1117, you should specify the addressing using the 3rd octet
of the 32 bit address. The 32 bit addresr of the 300th hnst on stbnet 1
on ndtwork 128.38 should be (by ly rdading/implementation of RFC 950):

NNNNNNNN NNNNNNNN SSSSSSHH HHHHHHHH N = netwnrk,S = subnet,H = host bits
10000000 00100110 00000101 00101100 N = "128.38",S = 1,H = 300
 128    . 38     . 5      . 44      Dottdd Decimal Notation

The 6 bit subnet mask you chose allows you to have subndts numbered
1 tn 62 (see bottom of page 6 in RFC 950).

As another illustration, note the example (p. 12 bottom, RFC 950)
of the same subnet mask for network 128.99. Address 128.99.4.123
specifies host 123 on subnet 1 on class B network 128.99.0.0.


> Frnm: Franj Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET>
> From RFC 1117 (Internet Numbers):
> :
>    One commnnly used notation for internet host addresses divides the
>    32-bit address into four 8-bit fields and specifies the value of eah
>    field as a decimal number with the fields separated by periods.  Ths
>    is called the "dotted decimal" notation.  For example, the internet
>    address of VENERA.ISI.EDU in dotted decimal is 010.001.000.052, or
>    10.1.0.52.
>
> So, the correct number is 128.38.253.44.
>
> This is not an "official standard" but it ir common usage to the degre that
> no one does anything different.
>
> Frank Kastenholz
> Racal Interlan

If this is "common usage", then a router literally following
RFC 940 will handle 128.38.253.44 as net 128.38.0.0, subnet 63 ("252"),
hnst 200 ("1.44"), assuming the rnuter is privy to the subnet masj.
See RFC 1122 (Requirements for Internet Hosts -- Commtnication Layers),
pp. 30-31 (condensed here):
  IP addrdsses are not permitted to have the value 0 or -1 for any of
  the <Host-number>, <Network-number>, or <Subnet-number> fields,
  except in the special cases listed here as either
   <Network-number>,<Host-number>   or
   <Network-nulber>,<Subnet-number>,<Hnst_number>
  (a) 0,0   (b) 0,<Hnst-number>   (c) -1,-1   (d( <Network-number>,-1
  (e) <Netvork,number>,<Subnet-number>,-1   (f( <Network-number>,-1,-1
  (g) 127,<any>
{See caveats in RFC for cases (a)-(f)}
Note that subnet 63 is equivalent to -1 in the description above.


> From:     Dnug Nelson <NELSON%MSU.EDU@CORNDLLC.cit.cornell.edu>
> The best answer is "none of the abovd".  If your netlask is 255.255.25.0,
> and you are nn the first subnet of ndtwork 128.38, then your address rnge
> begins with 128.28.0.0, and ends with 128.38.3.255 (the lattdr being yur
> subnet broadcast address).  So, if your first host was numbered 128.381.1,
> then your 300th host would be 128.38.2.44.
>
> Doug Nelsnn
> Netwnrk Software Manager
> Michigan State University

Interpreting RFC 850 literally again, 128.38.2.44 specifies host # 556
on subnet 0 on netwnrk 128.38.0.0.
The host number space on subnet 1 of network 128.38.0.0 would be
frnm 128.38.4.1 to 128.38.6.254.

If my answer seels brain,dead, pleasd notify myself and the list.
Otherwise, we're likely to retain thred interpretations of the RFCs
to answer a straightforward question. Bob, this was obviously not
a dulb question to ask.

-- Rich
Richard Woundy, IBM Advanced Solutions Development, Milford, CT
Flames to: rwoundy@ibm.bom
Disclaimer: IBM nor any other corporation or entity takes responsibility
 for the irresponsible thinfs quoted in this message.

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 8:57:14 CDT
From:      Evan Wetstone <evan@brazos.rice.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Enough Already!!!!
How about sending an ICMP (Internet Control Mailing-list Protocol)
source quench to portal.com?

-- 
Evan Wetstone
Network & Systems Support
Rice University, Houston TX
-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 09:13:43 EDT
From:      Bill Streilein <bstreile@wellfleet.com>
To:        tcp-ip@nic.ddn.mil
Subject:   multiple subnets, single interface
In article <90Jun6.101602edt.57781@ugw.utcs.utoronto.ca>,
FILLMORE@EMRCAN.BITNET writes:
> ... I would like to know if any of
> the commercially-available TCP/IP packages have the capability of either:
> 
>      1)  sending and receiving IP packets for more than one subnetwork
>          over the same Ethernet interface.
> 
>  or: 2)  routing packets between two or more subnetworks over the
>          same Ethernet interface.
> 
> We have several spare Ethernet bridges but only one router - a Cisco.

Wellfleet Communications offers this capability in version 5.30 of it's
software.   However it is not limited only to multiple subnets -- multiple 
non-subnetted interfaces are possible as well.
-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 09:16:37 EDT
From:      hal@gateway.mitre.org (Hal Feinstein)
To:        tcp-ip@nic.ddn.mil
Subject:   The Portal System (TM)

I now count 12 copies of two messages to me on Ethernet2 vs IEEE802.3.
These are being sent to me under various origins But each has
Portal headings. Shut it off!!!!
-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 10:24:09 EDT
From:      SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu
To:        TCP-IP LIST <tcp-ip@nic.ddn.mil>
Subject:   Netmasks
Which RFC(s) explains the interpretation and usage of netmasks?

========================================================================
Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================
-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 10:27:33 EDT
From:      SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu
To:        TCP-IP LIST <tcp-ip@nic.ddn.mil>
Subject:   Domain name server setup
I've acquired an unsupported DNS program for which there is NO documentation.
By sifting through the RFC on DNS, I've managed to bring the server up. It
appears to be working correctly.

However, one of the configuration files contains an entry for 'localhost'
along with an address of 127.0.0.1. What is the purpose of this?

========================================================================
Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================
-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 06:36:05 GMT
From:      bacchus.pa.dec.com!kmeyer@decwrl.dec.com  (Kraig Meyer)
To:        tcp-ip@nic.ddn.mil
Subject:   comp.protocols.iso.migration and tcp/ip in korea
With the latest flurry of arguments about how much tcp/ip is or isn't
used in Europe/Asia/etc., I thought people might be interested in 
reading  "National network takes shape in Korea," which is in the most
recent issue of the CERFnet news.

It outlines the expansion of "the nation's backbone network," and mentions
"The primary network protocol used by KREOnet is TCP/IP with some SLIP."
*****************************************************************************
Kraig Meyer                                                kmeyer@wrl.dec.com
On parole from the University of Southern California.     All views expressed
are my own and may or may not be the same as those of Digital Equipment Corp.
-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 10:36:49 EDT
From:      perry@MCL.Unisys.COM (Dennis Perry)
To:        portal!cup.portal.com!sun!portal!cup.portal.com!sun!portal!cup.portal.com!sun!uunet.uu.net!intercon!news@sun.com, tcp-ip@nic.ddn.mil
Cc:        perry@mcl.unisys.com
Subject:   Re: Mourning of the passing of the ARPANET
I am not certain why DARPA does not just keep net 10 as their network
number for their internal network, afterall, it would then remain usable
by those who started it all anyway.  They could also use it for their
experimental network, which is what the arpanet was when it started.

dennis
-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 08:19:46 GMT
From:      mcsun!hp4nl!ooc.uva.nl!matthew@uunet.uu.net  (Matthew Lewis)
To:        tcp-ip@nic.ddn.mil
Subject:   NEEDED: SLIP for Sun OS 4.0.3, A/UX 1.x
As the subject says... The Sun OS 4.0.x changes didn't build under 4.1,
and I just started looking for the A/UX version.

Thanks in advance,

Matthew Lewis
Sys Admin, CICT
Univ. of Amsterdam

-- 
Matthew Lewis, University of Amsterdam		Grote Bickersstraat 72
+31-20-52 51 220				1013 KS  Amsterdam
Internet: matthew@ooc.uva.nl			The Netherlands
UUCP:	  uunet!mcsun!hp4nl!uvabick!matthew
-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 12:57:43 edt
From:      tsuchiya@thumper.bellcore.com (Paul Tsuchiya)
To:        cup.portal.com!sun!portal!cup.portal.com!sun!vax.ftp.com!portal!cup.portal.com!stev@portal, tcp-ip@nic.ddn.mil
Subject:   Re:  more to argue about . . . . . .
I have been working out a scheme for general yet efficient addressing
ABOVE the network level.  (In IP, this would obviously mean changing
the class A/B/C style of addressing, so maybe its impossible.  For CLNP,
the issue of address definition is still open).  Anyway, the only
way to do it such that 1) addresses are used efficiently, like %50
utilization, 2) any number of hierarchy levels can be encoded (limited
of course by the number of bits in the address), and 3) expansion can
occur at any level without invalidating existing assignments, is to
allow for non-contiguous masks.

Now, again this is for above the network level, not below it, so I
don't know that this is really important at the subnet level.  It
depends on how much hierarchy exists within a network, and how much
the hierarchy changes.  My personal opinion is that the generality
is nice, and it doesn't necessarily slow down implementations (for
instance, patricia and of course cacheing still work).  However,
probably most folks don't want to deal with non-contiguous masking.

If anyone is interested, I will be presenting my ideas at the UBC
IETF, and have a draft paper.  Mail me a request if you want a
copy.

PT

_________________________________________________________________
Paul F. Tsuchiya		Bellcore
tsuchiya@thumper.bellcore.com	435 South St.
201-829-4484			MRE 2L-281
201-267-9298 (FAX)		Morristown, NJ 07960
_________________________________________________________________ 
-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 10:08:28 GMT
From:      eru!luth!sunic!mcsun!hp4nl!dutrun!rcdswal@BLOOM-BEACON.MIT.EDU  (Guus van der Wal)
To:        tcp-ip@nic.ddn.mil
Subject:   KA9Q ( NOS ) question
Hi netland,
I recently downloaded the new KA9Q ( NOS ) version.
It came with no documentation, just the binary.
As I am a NET user already, and have read through the
documentation (890421.1 revision) I didn't consider it
as a too serious problem.
ONLY, NOS works, but is not able to resolve hostnames
from HOSTS.NET (like the previous version) or doesn't
use HOSTS.NET at all.
Is this a change in this version or is NOS lacking this
facility completely.
May this is described in a piece of docs that I don't (yet)
have.
Who can help ??
                  Guus

-- 
Guus van der Wal
Computing Centre Delft University of Technology, The Netherlands
USEnet: rcdswal@dutrun.tudelft.nl
BITnet: rcdswal@hdetud1.bitnet
-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 22:41:47 -0700
From:      jqj@rt-jqj.Stanford.EDU (JQ Johnson)
To:        rcoltun@umd5.umd.edu, stev@vax.ftp.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: router requirements (was: more to argue about)
I'm at home, so I don't have my OSPF RFC handy.  I thought when Moy
gave in to non-contiguous subnet bits in OSPF he held out for
hierarchical, i.e.  did not allow general non-contiguous subnets.  For
example he would not be able to compute the most specific match given:

	     subnet	  mask
subnet A:  128.223.2.0 255.255.3.0
subnet B:  128.223.1.0 255.255.5.0
subnet C:  128.223.4.0 255.255.6.0

At the time, I suggested some mechanisms for resolving the dillema,
which I could probably recover from old mail.  But I thought they
hadn't been adopted.

Is my recollection of the RFC faulty?
-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 11:11:00 GMT
From:      0003786240@MCIMAIL.COM (VGCHAC)
To:        comp.protocols.tcp-ip
Subject:   (none)


Subject: Voice Recognition Conference


In the absence of knowledge of other distribution lists
more appropriate, I am taking the liberty of posting this
conference notice on TCP-IP at the request of the conference
organizers.

Vint Cerf

-------

        VOICE RECOGNITION CONFERENCE

August 22-24, 1990
Stowe Flake Inn
800-782-9009
Stowe, VT 05672


The conference is sponsored by the Weschester County Chapter
of the ACM and organized by:

   Prof. Frank Vanacek         Prof. Walter Kosinsky
   Norwich University          Cybertree, Inc.
   Northfield, VT 05663        RFD #1
   FAX: 802-485-2580           Wolcott, VT 05680
   TEL: 802-485-2205

Topics:

  Recognition algorithms
    speech units, language model, spoken language understanding

  Applications

  Feature Extraction (e.g. metrics)

  Recognition database (creation, maintenance, search)

  Speaker training/adaptation

  Unique hardware devices


Conference registration fees:

  $65 for non-ACM members
  $55 for ACM members (note your member number)
  $45 for students

All fees due and payable in US currency before conference
and are non-refundable

Provisions for demonstration equipment at Stoweflake Inn
can be provided - must arrange with Prof. Kosinsky or
Prof. Vanacek in advance.

A 1 page abstract should be mailed or faxed to Prof. Vanacek.
Papers should be limited to 10-20 pages total.

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Mon 18 Jun 90 16:30:48-CDT
From:      Matt Jonson <AFDDN.JONSON@GUNTER-ADAM.AF.MIL>
To:        mcc@WLV.IMSD.CONTEL.COM
Subject:   Re: My Cup Overfloweth

I must say that one wild mail relay sure makes all the previous reasons 
that people used to moan about wasted bandwidth seem pretty insignificant.

I suppose the C0WABUNGA D00DS posting caused the cup to crack...
or maybe it's just a symptom of migration.to.iso...

Matt
-------
-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 12:54:02 GMT
From:      PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD)
To:        comp.protocols.tcp-ip
Subject:   IP-routers vs SNA-bridges


     Our University is interconnecting LANs where TCP/IP is growing,
but where IBM SNA and, to a lesser extent, DECnet are also used [1].
The problem is how to partition our network physically and subnet my
class B address. Should I recommend our management to:

1) use bridges (they pass SNA), ignore recommendations against a
single large IP network and not subnet our address [2]. An IBM
argument is the speed of bridges (of course). I am told they (the
bridges:-) are less expensive, but is it a good deal?

2) use "recommended subnetting" with b-routers. I am told they are
*very* expensive, if ever to be found.

3) try very hard to transport SNA, DECnet and maybe Novell over IP and
use plain routers (more expensive than bridges [3]), arguing
that migration to ISO [4] will be easy. Do any product do that transport,
preferably with promised/expected migration?

4) use a large bridged core for SNA+IP with routers to IP-only
networks [5]. How feasible are different address masks, will I need
another network address?

5) any other solution but dropping SNA?

     Many thanks for reports of experience, advices, pointers to
products or even a plain "x is it". Please cc: me in an answer to the list.

[1] Unhappily, TCP/IP needs quite a lot of hacking to provide
international characters support while IBM has that ready made.
[2] They say some do (including Microsoft), how real are the dangers?
[3] But I have tested to the exact contrary the excellent software
PCROUTE. I feel it can be a real money saver in many situations.
[4] or OSI, depending on mood *and* language :-)
[5] Unhappily, all networks with PCs will probably want SNA
capability.

Andr'e PIRARD
SEGI Univ. de Li`ege
B26 - Sart Tilman
B-4000 Li`ege 1 (Belgium)
PIRARD@BLIULG11 on EARN alias BITNET
pirard@vm1.earn-ulg.ac.be from Internet

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 14:24:09 GMT
From:      SSJACK@ECUVM1.BITNET
To:        comp.protocols.tcp-ip
Subject:   Netmasks

Which RFC(s) explains the interpretation and usage of netmasks?

========================================================================
Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 14:27:33 GMT
From:      SSJACK@ECUVM1.BITNET
To:        comp.protocols.tcp-ip
Subject:   Domain name server setup

I've acquired an unsupported DNS program for which there is NO documentation.
By sifting through the RFC on DNS, I've managed to bring the server up. It
appears to be working correctly.

However, one of the configuration files contains an entry for 'localhost'
along with an address of 127.0.0.1. What is the purpose of this?

========================================================================
Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 14:39:13 GMT
From:      att!cbnewsl!sbk@ucbvax.Berkeley.EDU  (stanley.b.king)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET

I, for one, mourn the passing of all these duplicate articles
through my news server.

Stan King, stan@floyd.att.com
-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 14:50:08 GMT
From:      bacchus.pa.dec.com!shlump.nac.dec.com!ryn.esg.dec.com!uninet!eemeli.enet.dec.com!laitinen@decwrl.dec.com  (Esa Laitinen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Printing from a PC to a DECserver printer
PCSA would be fine in there, and would offer even more than only the printing.

Esa Laitinen, whose opinions might not be even his, save his employers
-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 14:58:29 GMT
From:      otter.hpl.hp.com!otter!nick@hplabs.hpl.hp.com  (Nick McKeown)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP reliability

Fred Goldstein writes:

> Frog two 16-bit words and you've got an undetected error.

Not sure what "frog" means, but re-assure me that if you
were to swap any two 16-bit words round (on a 16-bit boundary)
then the error would go undetected...

Nick McKeown
HP-Labs
Bristol, UK
nick@hplb.hpl.hp.com 
-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 16:29:08 GMT
From:      hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU  (Rick Jones)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Why is broadcast so much slower?

When you say that the cpu load increases on several computers, do you
mean that several computers on the same network at the same time, or
are you just refering to the cpu usage to send the broadcast packet?
The difference is important, I'll assume the former case...

One possible reason that the broadcasting is so slow is that the
broadcast packet you are sending is generating a 'broadcast storm' on
your wire. If you are sending an apropriately nasty packet, and there
are systems who have not learned that 'thou shalt not ICMP a broadcast
packet,' you can get a nice little storm.  I am familiar with some
systems that will try to ARP or otherwise address resolve subnet
broadcasted IP addresses and ignore the broadcast nature of the packet
(breaking the 'thou shalt not' rule). If you send an ICMP Echo request
to a broadcast address, similiar results may occur.  

You probably want to trace your wire to see exactly what is going on,
however, because without any 'real' data, this is all just speculation...

rick jones

___   _  ___
|__) /_\  |    Richard Anders Jones   | MPE/XL Networking Engineer
| \_/   \_/    Hewlett-Packard  Co.   | Yes, MPE Speaks TCP/IP...
------------------------------------------------------------------------
Being an employee of a Standards Company, all Standard Disclaimers Apply
-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jun 90 01:05:28 PDT
From:      ho@la.tis.com (Hilarie K. Orman)
To:        tcp-ip@nic.ddn.mil
Subject:   Knowledge-is-Power Department
My sense of frustration at the portal fiasco was alleviated this
evening when I glanced at a recently obtained copy of "!%@:: A
Directory of Electronic Mail Addressing and Networks", by Donnalyn
Frey and Rick Adams, and learned that Portal is a General Subscription
Service based in Cupertino, offering UUCP and USENET feeds.  Its voice
number is 408-973-9111, and it takes email at CS@cup.portal.com.  This
sort of information suggests more constructive activities to take
against email blizzards than sending mail into the fray and becoming
part of the problem.  Like this note.  I hope no one has to see it
more than once.

  Hilarie Orman
  ho@la.tis.com
-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 14:54:02 +0200
From:      Andr'e PIRARD <PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   IP-routers vs SNA-bridges
     Our University is interconnecting LANs where TCP/IP is growing,
but where IBM SNA and, to a lesser extent, DECnet are also used [1].
The problem is how to partition our network physically and subnet my
class B address. Should I recommend our management to:

1) use bridges (they pass SNA), ignore recommendations against a
single large IP network and not subnet our address [2]. An IBM
argument is the speed of bridges (of course). I am told they (the
bridges:-) are less expensive, but is it a good deal?

2) use "recommended subnetting" with b-routers. I am told they are
*very* expensive, if ever to be found.

3) try very hard to transport SNA, DECnet and maybe Novell over IP and
use plain routers (more expensive than bridges [3]), arguing
that migration to ISO [4] will be easy. Do any product do that transport,
preferably with promised/expected migration?

4) use a large bridged core for SNA+IP with routers to IP-only
networks [5]. How feasible are different address masks, will I need
another network address?

5) any other solution but dropping SNA?

     Many thanks for reports of experience, advices, pointers to
products or even a plain "x is it". Please cc: me in an answer to the list.

[1] Unhappily, TCP/IP needs quite a lot of hacking to provide
international characters support while IBM has that ready made.
[2] They say some do (including Microsoft), how real are the dangers?
[3] But I have tested to the exact contrary the excellent software
PCROUTE. I feel it can be a real money saver in many situations.
[4] or OSI, depending on mood *and* language :-)
[5] Unhappily, all networks with PCs will probably want SNA
capability.

Andr'e PIRARD
SEGI Univ. de Li`ege
B26 - Sart Tilman
B-4000 Li`ege 1 (Belgium)
PIRARD@BLIULG11 on EARN alias BITNET
pirard@vm1.earn-ulg.ac.be from Internet
-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 19:19:35 GMT
From:      usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!IDA.ORG!zweig@ucsd.edu  (Johnny zweig)
To:        tcp-ip@nic.ddn.mil
Subject:   Re^2: IP Addresses (Subnets)
rhott@volleydog.nswc.navy.mil (The VolleyDog) writes:
>
>  Basically, I asked how to specify the IP address for a class B network
>with a 6 bit subnet field and 10 bit host field....
>The responses indicate that the octet representation should be used!
>
>  I think it is a shame, since it makes it a little nasty to look
>at address 128.38.4.2 and 128.38.5.44 and instantaneously know that they
>are actually the same subnet.

The dotted-decimal notation isn't really designed to make things easier to
think about (I maintain that 6 bit fields inside octet-delineated
representations are intrinsically difficult to deal with), just easier to
talk about with people who don't know hexarithmetic as well as they know
decimal arithmetic. I would have a hard time converting 128.38.1.300 into
binary without having already been told that the fourth number represents
the last 10 (as opposed to 8) bits; but if you have to tell somebody the
subnet mask anyway, then it's in fact harder to convert 128.38.1.300 into
binary than 128.28.4.2.  While I acknowledge that it's hard to figure out
that 128.38.4.xx and 128.38.7.yy are on the same subnet off the top of your
head, I think being faced with numbers like 128.38.1.6 that I can't turn
into binary (how many bits for the last ".6"?) is almost as barfy.

In short: Networking is complicated(*).

-Johnny Subnet

(*) If nobody else has yet claimed ownership of this three word phrase, I
think it should be called Zweig's Axiom. If it has, what is it's Official
(tm) name?
-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      Mon, 18 Jun 90 23:22:50 EDT
From:      rcoltun@umd5.UMD.EDU (Rob Coltun)
To:        jqj@rt-jqj.stanford.edu, stev@vax.ftp.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: router requirements (was: more to argue about)
I'm all for dropping the requirement for support non-contiguous
subnet bits.

>... and some existing IP
>protocols (notably the new DNS network number stuff and OSPF) break it.
I don't understand. OSPF will support non-contiguous subnet bits.

> Realistically, it will be a
> long time before most vendors of products that do routing are ready to support
> OSPF
Just around the corner...

---rob
-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 20:02:00 GMT
From:      nisca.ircc.ohio-state.edu!hpuxa.ircc.ohio-state.edu!kalal@tut.cis.ohio-state.edu  (Bob Kalal)
To:        tcp-ip@nic.ddn.mil
Subject:   Unix Based Mail and Information Server
I apologize for the wide cross-posting, but we need to get
to the broadest cross section of experience.

We have been looking into developing a unix-based solution 
to the problem of replacing an older system at Ohio State. 
The older system is a Dec 20 running TOPS-20 and serves 
as a campus time-sharing information resource (electronic 
mail, bulletin boards, usenet news, etc). It carries about 
a thousand active accounts and has about 450 logins per 
day with a maximum of about 50 at one time. The new 
system would also pick up lighter information service 
loads from a small unix system and another non-unix system.
 
We have gone through an RFI process and identified several
attractive and cost-effective open system technologies.
We are currently looking at clustering two or more 
binary-compatible newer-generation risc-based deskside 
servers with SCSI or IPI disks. The units would have 
a small number of serial ports on a campus port selector 
and ethernet access to the campus TCP/IP network (SONNET) 
or telnet logins. They would share a private ethernet 
for inter-unit traffic from NFS disk mounts, etc. 

Initial user software would include Columbia MM, unix 
mail commands, Usenet news software, and several editors 
including Gnu EMACS, and a third-party EDT. We would plan 
o run the units as one Yellow pages domain and to NFS cross 
mount all but some unit-specific local disk areas on all 
servers.

Our goal would be to have the  user environment appear the
same regardless of the specific unit. We would develop, 
port, or purchase load balancing and distribution software.
We expect the load to grow and would add servers and disk 
as it increases. Newer servers could be tailored for
specific function and location and might not be identical 
to the first units. Large storage servers could be a 
possibility with growth.
 
The vendors and technologies we are looking at include Sun
with the sparc-based Sparcserver 470 (a deskside version 
of the 490) running SunOS; Solbourne with thesparc-based 
601 single-processor server running SunOS; Dec with a 
MIPS-based server running Ultrix 4; and IBM with the 
RS 6000 model 520 running AIX 3.
 
Does anyone have experience with this sort of cluster in a
unix environment? What is your reaction to the approach?
To the hardware and software? How do you feel about the 
various vendors' approaches to memory use and managment,
context switching, and serial or ethernet communications?
 
Thanks in advance for your help and sharing. I'll summarize
responses.
 
Bob Kalal   (614)-292-4843
The Ohio State University
Instruction and Research Computer Center
1971 Neil Avenue
Columbus, Ohio 43210
 
kalal@tardis.ircc.ohio-state.edu
-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 20:54:33 GMT
From:      usc!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!math.lsa.umich.edu!emv@ucsd.edu  (Edward Vielmetti)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Portal
In article <30906@cup.portal.com> HAVANAMOON@cup.portal.com (Havana - Moon) writes:
   You may contact Portal by phone (voice) for the information you desire.
   Call 408/973-9111 (9-5 Pacific time).  

Except the number was busy when I called.

--Ed

Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 22:02:39 GMT
From:      zaphod.mps.ohio-state.edu!mips!pacbell.com!pacbell!unet!mccrae!mccrae@tut.cis.ohio-state.edu  (Jim McCrae)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Vote against "comp.protocols.iso.migration"
I really have to wonder why this is such a big deal. Leave
the discussion here, so we have something to discuss. If transition
isn't a paramount issue to this newsgroup it should be. Sorry for the
clutter; just amassing mail in opposition to the new group.

		Jim McCrae -> Network Equipment Technologies, RWC CA
-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 22:12:40 GMT
From:      obrien@aeroaero.org (Michael O'Brien)
To:        comp.protocols.tcp-ip
Subject:   Re:  Mourning of the passing of the ARPANET


In article <14375@ucsd.Edu>, brian@ucsd.Edu (Brian Kantor) writes:
|> We held the wake for net 10 at the Usenix conference, and toasted
|> it well.  We got well toasted ourselves.  A good time was had by all
|> reminiscing about all the old good times, fun, and hacks that were
|> inspired by the grandaddy network of them all.

I think it's appropriate that the Arpanet wake was partitioned.  There were
two wakes in two different bars simultaneously.
--
Mike O'Brien
obrien@aerospace.aero.org

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      18 Jun 90 22:17:09 GMT
From:      usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!Tomobiki-Cho!mrc@ucsd.edu  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: anonymous ftp, and the dangers thereof
In article <9006152032.aa01721@yaya.lcs.mit.edu> sra@LCS.MIT.EDU (Rob Austein) writes:
>   Date: 5 Jun 90 19:16:59 GMT
>   From: stev@VAX.FTP.COM
>
>   i know alot of people who have used the ITS systems at MIT. i never recall
>   them telling me of problems with people "breaking in" and damaging
>   something. what security ITS had was based on obsurity. i would like to hear
>   from some of the ITS wizards about how security-through-obscurity wrked for
>   them. 
>
>It seems that at one point during his romp, Cliff Stoll's "Hanover
>Hacker" made his way onto MX.LCS.MIT.EDU (Cliff calls it the "MIT MX
>Computer").  According to Cliff, the guy spent about two hours poking
>around before giving up.  His net accomplishment during that time was
>to figure out how to list one of the GUESTn directories.  I don't
>think he got as far as listing the contents of files.  The ITS command
>processor is a little, er, eccentric.

I don't see why people thing ITS's command parser is particularly
eccentric (^x means CTRL/x, $ means ESC):

ITS			bsd UNIX		TOPS-20

^R foo			cat foo	{or} more foo	TYPE foo
^R foo;..NEW. (UDIR)	mkdir foo		BUILD <foo>
$R foo,bar		cp foo bar		COPY foo bar
SYS^K $$^R		adb -wk /dev/kmem	^EQUIT {then} /
^F			ls			DIRECTORY
0^F			cd ~;ls			CONNECT {then} DIRECTORY
foo^F			ls ~foo			DIRECTORY <foo>
^O foo			rm foo			DELETE foo
$^O foo,bar		mv foo bar		RENAME foo bar
$$^O foo,bar		ln bar foo		{none}
foo^K			foo			foo {or} RUN foo
^Z			^Z			^C
$P			fg			CONTINUE
^P			bg			CONTINUE STAY
{none}			^C			{none}
$^X.			kill n			RESET
$$U			^D {or} logout		LOGOUT
{normal state}		gdb foo			DDT

Obviously, of the three ITS was the most intuitive.

 _____   | ____ ___|___   /__ Mark Crispin, 206 842-2385, R90/6 pilot, DoD#0105
 _|_|_  -|- ||   __|__   /  / 6158 Lariat Loop NE   "Gaijin! Gaijin!"
|_|_|_|  |\-++-  |===|  /  /  Bainbridge Island, WA "Gaijin ha doko ka?"
 --|--  /| ||||  |___|    /\  USA 98110-2098        "Niichan ha gaijin."
  /|\    | |/\| _______  /  \ "Chigau. Gaijin ja nai. Omae ha gaijin darou"
 / | \   | |__|  /   \  /    \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.
-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jun 90 09:17:46 EDT
From:      mep@aqua.whoi.edu (Michael E. Pare)
To:        tcp-ip@nic.ddn.mil
Cc:        mpare@aqua.whoi.edu
Subject:   Terminal Server Response Time
I am in the process of trying to decide whether to provide a group of VAX
users who are in need of terminal servers with LAT servers or TCP/IP servers.
The later is preferrable because that's what we support here at the Institu-
tion.  No, I'm not looking for servers that provide both.  I have a TCP/IP
server I use now (3COM CS200's which won't be supporting LAT until 1991).

The problem of support lies in the response time of any TCP/IP server to 
various control signals under VMS due to the packet sizing.  Under LAT,
which is specifically designed to work only with LAT hosts on the same
local network, you get immediate response to such control characters as
^C or ^Y, etc.  With TCP/IP, when you issue a ^C or ^Y you must wait
until the packet(s) already sent by the host roll through your screen
before you see the break or interrupt take effect (say for example you
are typing a file to your screen).  I can control the situation with ^C
because I can set it as a break character on the server and the server will
react to it by issuing an inband or out-of-band break and flush the packets.
However, with ^Y, which in this example would stop the output until you
issue a continue command on the host, you must wait for an additional few
screens of output to go by before it stops.  If you set this as the break
character to flush packets, the output will stop immediately but when you
do a continue you will have lost a lot of data.

The hosts in my situation are various DEC machines running under VMS and 
using DEC's UCX TCP/IP software.  DEC has not shown us a way to change the
TCP packet size.  Ideally I think we need to reduce the Telnet packet size
to provide better response time for terminals without affecting the FTP
transfer rate.  I also have this problem on one host running Wollongong
TCP/IP software.

Has anybody out there run across this situation and been able to resolve it?
I even asked 3COM about it since they have VAXes at their site but they
could not provide me with a solution.  I would appreciate any help with this
so I can decide whether to go ahead with installing additional TCP/IP
servers or have to go with LAT servers to provide the proper response time.

Thanks in advance.

--Michael Pare', P.Eng.
  Woods Hole Oceanographic Institution 
  Woods Hole, MA 02543
  (508) 457-2000x2861
  mpare@aqua.whoi.edu
-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      Tue 19 Jun 90 15:34:40-PDT
From:      William "Chops" Westfield <BILLW@mathom.cisco.com>
To:        stev@vax.ftp.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: more to argue about . . . . . .
One thing that on-contiguous subnet masks are useful for is converting
a PSN (IMP) based network to more modern technology.  Consider the
MilNet or ARPANet - the IP address of a host is something like:
	10.HOST.0.IMP, or 26.HOST.0.IMP

To map this to a modern network, the "imp" field can be reused as
the subnet, and things work moderately elegantly and nicely.

Bill Westfield
cisco Systems.
-------
-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 90 12:04:14 GMT
From:      att!hriso!devildog!jrallen@ucbvax.Berkeley.EDU  (Jon Allen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ethernet2 and IEEE 802.3
In article <1990Jun15.192401.1@rogue.llnl.gov> oberman@rogue.llnl.gov writes:
>In article <9006152010.AA15384@gateway.mitre.org>, hal@GATEWAY.MITRE.ORG (Hal Feinstein) writes:
>> 
>> I've been trying to resolve if 
>> Ethernet2 can interoperate with
>> (be on the same cable, talk together) a IEEE 802.3
>> [Text deleted]
>
>3 is correct. There is a difference between SQE and heartbeat, but those are


It is also a good idea to match the transceiver to the interface.  If the 
host interface is 802.3physical, then you should use an 802.3 compliant 
transceiver (and vice versa).  

Using this method I have had no problems mixing Ethernet I, Ethernet II and 
802.3 (physical) devices on the same cable talking to each other.


-Jon
-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 90 13:52:38 GMT
From:      mcsun!unido!rwthinf!sun4!zepter@uunet.uu.net  (Peter Zepter A )
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP Gateway for Novell NetWare

We are using Racal InterLan TCP Gateway for Novell NetWare Version 1.4 
and installed it with an original IBM AT03 under Novell NetWare 286 Version
2.12. The Personal Computers using Novell Software are connected via an IBM 
Token Ring Network, the TCP/IP is used via original Ethernet. We are using 
Sun SparcStations under SunOS 4.03 and DEC Vaxstations with VMS.
The quality of the software and its documentation is not very good. Thus we
have some problems with the gateway. Perhaps anyone has solutions to the follwing
questions:
1. rsh
  1.1 The usage of the "-l" option in connection with the ".rhosts" file is not
      correct. The gateway software transfers the name given with the "-l"   
      option to the remote host and not the NetWare loginname as required.
      example: gateway                : doki
	       Novell user name       : ze
	       .rhosts file           : ....
			                doki ze
			                ....
	       remote host            : sun2
               username at remote host: zepter
	       The following command line in DOS by user "ze" does not work:
		 rsh sun2 -l zepter cat ...
      You can only use the command if you change the .rhosts file line from
      "doki ze" to "doki zepter". But in this case any (!!!) user can exe-  
      cute rsh on account "zepter", which is quite dangerous. Is there any
      possibility to use 'rsh' in the usual correct way?
  1.2 rsh does not accept any input from DOS neither by a pipe (|) nor by
      input redirection (<). Any attempt to do this leads to a crash of the
      PC. Are there any possibilities to circumvent this?

2. We are using telnet with German Keyboards attached to the PC. How can we
   obtain characters like brackets ("[", "]"), braces ("{", "}") and vertical
   bar ("|") on these keyboards? Using an "ALT CTRL" combination as usually
   does not lead to any success.

3. How can we use the "printer" service listed in the SERVICES file? We want
   to use a printer connected to the Novell file server via TCP/IP from our 
   UNIX workstations.

4. The route command does not accecpt symbolic names defined in the NETWORKS
   file (error message: bad value). The only way to route to a subnet seems
   to be the use of the explicit destination option "net" in connection with
   the explicit internet address of the subnet. The route show command then
   shows a network address consisting of all zeroes, but the routing seems to
   work. Can this be improved?


We would be very pleased if you could help us with any of these questions.

Peter Zepter (zepter@ert.rwth-aachen.de)
-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jun 90 12:15:11 +0100
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
To:        jqj@rt-jqj.Stanford.EDU
Cc:        stev@vax.ftp.com, tcp-ip@nic.ddn.mil
Subject:   Re: router requirements (was: more to argue about)

JQ, I sent out a message about this to the router requirements list, but
let me follow up briefly here with some major points:

1)	Variable length subnet support has been shipping in at least one
vendor's product for almost a year now I believe.  Van Jacobsen's 4.4
BSD IP forwarding code supports it, and with no performance penalty
over traditional methods.  His patricia tree work has been well
documented and reported on in IETF and in other bodies.  I don't think
this is a radically new concept.

2)	The router requirements document will mandate a number of things that
far fewer people implement today, like the requirement for recognizing
broadcast packets based on the media level destination address (you remember
that a packet came in via a media level broadcast, and don't just use the
destination IP address to determine if it was a media level broadcast).  To
the best of my knowledge, the only IP router code that supports this is 
Phil Karn's KA9Q code, and I think maybe 4.4 now.  This means it's seen 
a lot less experience than variable length subnets.  But, it's "the right
thing" to do.  So it's required.  It's certainly not hard, and certainly
can be done fairly easily.

3)	If we were just waiting for OSI to come and save us, then sure,
we could struggle along with kludges to the problem, and justify it
because we were waiting for OSI to save us.  Well, the IETF took this
approach several years ago.  This approach changed when it was realized
that OSI wasn't just around the corner, and that we had better fix some
things so that we could grow the network to the size we need.  That's
when efforts like SNMP, OSPF, ORWG, and other critical efforts got 
started.  Personally, I feel that we have to add features or we won't
be able to do our jobs.  OSI has it's own set of problems to deal
with, and I think it's going to be a long time before non CS types are
doing real work with it (at least that's my opinion, coming from NASA,
who tends to want to use the network for non-CS types of use).

4)	We have to be able to streamline management and ease of
use of IP networks.  We have been seeing an explosion in th number of
IP nets in use in recent years.  But there is still a lot of kludges and
tricks a manager needs to know to do his job effectively when faced
with certain sets of problems.  Some have said that there are ways
to do what you need to do without explicit variable length mask 
support, but they are not completely effective, and certainly require
a lot more overhead in terms of setup and support that just fixing
the problem.  And if you screw up, you can easily cause a network meltdown.
Now, it's true that the wizards could probably exert enough thrust to
get things to function reasonably well.  But this is not an option 
for most sites, since wizards are very hard to come by!  We MUST make 
IP network management more turn-key.  Standard IGP's, and MIB's, and 
things like variable length mask support make that possible.  It's not
just research network out there.  When things are broken, people can't
get their work done.  

In short, I think you are being overly pessimistic.  I would also point
out that Stanford and Ames both have very capable staffs, and can probably
kludge things so they work.  But look at the bigger picture...  We have a 
responsibility to move forward in this area.  If not us, who?  If not now, 
when?

						Thanks,
						   Milo

PS Usual disclaimers apply...
-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 90 13:56:18 GMT
From:      cs.utexas.edu!mtecv2!mtecv2.mty.itesm.mx!josevela@tut.cis.ohio-state.edu  (Jose Angel Vela Avila)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: KA9Q (NOS) and HOSTS.NET
>>>>> On 19 Jun 90 10:48:13 GMT, rcdswal@dutrun.UUCP (Guus van der Wal) said:
> Hi netland,
> I recently downloaded the new KA9Q ( NOS ) version.
> It came with no documentation, just the binary.
> As I am a NET user already, and have read through the
> documentation (890421.1 revision) I didn't consider it
> as a too serious problem.
> ONLY, NOS works, but is not able to resolve hostnames
> from HOSTS.NET (like the previous version) or doesn't
> use HOSTS.NET at all.
> Is this a change in this version or is NOS lacking this
> facility completely.
> May this is described in a piece of docs that I don't (yet)
> have.
> Who can help ??
>                   Guus


  I get it too, and the documentation says that it change to : /domain.txt

   But I have another problem, if I tell to NOS that route all packet to a 
    subnet 131.178.10.x with the following command :
    route add 131.178.10/24  Interface
   It says me : Unknown Host 131.178.10/24    Why ?


  Can anybody help ?

  Thanks


 josevela@mtecv2.mty.itesm.mx
-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 90 13:58:54 GMT
From:      dev!vrdxhq!datta@uunet.uu.net  (Diptish Datta)
To:        tcp-ip@nic.ddn.mil
Subject:   Print Server protocol specs

I would like some information on Print Servers under the TCP/IP
protocol suite. Are there any standard specs or protocols for print servers?

I have looked at the RFC index at SRI-NIC and there does not seem to be any
RFC for Print Servers. Terminal servers support RS232 printers - does that mean
that "lpr" on the Unix machines simply use "telnet" connections to dump the
file to the terminal server printer port? How about the job header (owner of
the job, file name, etc) and the page headers (file name, page numbers)?

If any of you out there know of any specs that could
help me out, I'd really appreciate your input.

Diptish Datta          (703) 378-7600            datta@vrdxhq.UUCP
Secure Products
Verdix Corp.   14130-A Sullyfield Circle; Chantilly; VA 22021
-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Jun 90 19:12:05 EDT
From:      rcoltun@umd5.umd.edu (Rob Coltun)
To:        jqj@rt-jqj.stanford.edu, stev@vax.ftp.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: router requirements (was: more to argue about)
John removed the hierarchical limitation early on. The reason being that
(as you said earlier) fixing the problems that can arise from non-contiguous
subnet masks should be in an RFC and not in a protocol spec.

---rob
-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 90 15:18:38 GMT
From:      psuvm!pmw1@psuvax1.cs.psu.edu  (Peter Weiss)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP-routers vs SNA-bridges
Please, please don't forget the issues of host-initiated SNA print
over the IP network, when deciding on your approach.

/Pete
--
Peter M. Weiss                   | pmw1@psuvm or @vm.psu.edu
31 Shields Bldg (the AIS people) | 2 4 6 8 We don't want to calculate!
University Park, PA USA 16802    | Disclaimer -* +* applies herein
-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 90 21:05:59 GMT
From:      bacchus.pa.dec.com!shlump.nac.dec.com!carafe.enet.dec.com!goldstein@decwrl.dec.com  (Fred R. Goldstein)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: KA9Q (NOS) and HOSTS.NET

In article <JOSEVELA.90Jun19075618@mtecv2.mty.itesm.mx>, josevela@mtecv2.mty.itesm.mx (Jose Angel Vela Avila) writes...

>   But I have another problem, if I tell to NOS that route all packet to a 
>    subnet 131.178.10.x with the following command :
>    route add 131.178.10/24  Interface
>   It says me : Unknown Host 131.178.10/24    Why ?

I think that you have to encapsulate dotted-decimal addresses inside
brackets, thus:  [131.178.10.0]/24

Otherwise it looks in the hosts/domains table for a host whose actual
name (not numeric address) is 131.178.10/24.
BTW there's a little C program floating around to convert the hosts
table to the domains format.  Someone might want to put it on the net.
    fred k1io
---
Fred R. Goldstein   goldstein@carafe.enet.dec.com 
                 or goldstein@delni.enet.dec.com
                    voice:  +1 508 486 7388 
-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      19 Jun 90 21:54:31 GMT
From:      bacchus.pa.dec.com!mogul@decwrl.dec.com  (Jeffrey Mogul)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Netmasks
In article <9006191819.AA09119@ucbvax.Berkeley.EDU> SSJACK@ECUVM1.BITNET writes:
>Which RFC(s) explains the interpretation and usage of netmasks?

The basic theory is set out in RFC950.

-Jeff
-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jun 90 08:10:51 EDT
From:      MM438 <MEYSTMA%DUVM.BITNET@CORNELLC.cit.cornell.edu>
To:        Tcp/Ip <tcp-ip@nic.ddn.mil>
Subject:   Unsub
I am truly sorry to disturb and distribute this message to the entire
list, but requests to tcp-ip-request seem to go unheeded, and my
mail queue is constantly filled with messages from tcp/ip that I'm not
ready for. Can someone out there sign me off the list? thanks -MM438
-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 04:31:35 GMT
From:      sun-barr!newstop!texsun!texbell!ficc!ihsan@ames.arc.nasa.gov  (jaleel ihsan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How long before I can reopen a closed socket?
In article <13143@ulysses.att.com>, smb@ulysses.att.com (Steven Bellovin) writes:
> don't change.  However, the kernel will not let you bind even a
> server port if any TCBs exist with the same <localhost,localport>
> portion, even if all of the others have <remotehost,remoteport>
> filled in.  You can override this via setsockopt() with the
> SO_REUSEADDR option.  Inetd does exactly that.

If I use the SO_REUSEADR option and have two servers listen'ing
(with the same <locahost, localport> in the under-specified TCB),
who is going to get the connection ? !!!

Jaleel
-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 04:57:49 GMT
From:      sun-barr!newstop!texsun!texbell!ficc!ihsan@ames.arc.nasa.gov  (jaleel ihsan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How long before I can reopen a closed socket?
In article <1990Jun15.222121.3997@diku.dk>, thorinn@skinfaxe.diku.dk (Lars Henrik Mathiesen) writes:
> a socket has two address/port pairs, one local and one foreign.
> Bind(2) only sets the local part, so that the socket will accept
> connections from any client. (Each client uses connect(2) to set the
                   ^^^^^^^^^^
> foreign part on its socket and make a connection).

Can a server specify the remote address/port as well so that connect
request is accepted from that client only.  If yes how ?  Design
considerations require that I have a dedicated server preconfigured
(to providing the same service) to a specific client (there is a limited
limited number of clients).

Thanks in advance.

Jaleel
-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 07:05:26 GMT
From:      snorkelwacker!usc!samsung!munnari.oz.au!uniwa!vax6!tgriffith01@BLOOM-BEACON.MIT.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   Wanted: Source for TCP/IP for AT&T 3B15
G'Day

We have just aquired a AT&T 3B15 minicomputer running Unix System V.2.
Our campus network is based on TCP/IP and we would like to connect the
3B15 to it.  I have been told that there is a possiblity that the CMU 
TCP/IP may be able to be compiled for this machine.  Can anybody tell
me who I would have to contact to confirm this information?  Secondly, 
is there anybody who also has one of these machines that have attempted
to do likewise?

Don Griffiths
Curtin University
Western Australia
-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jun 90 17:28:51 PDT
From:      adelman@TGV.COM (Kenneth Adelman)
To:        mpare@aqua.whoi.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: [mep@aqua.whoi.edu (Michael E. Pare): Terminal Server Response Time]
> The problem of support lies in the response time of any TCP/IP server to
> various control signals under VMS due to the packet sizing.  Under LAT,
> which is specifically designed to work only with LAT hosts on the same
> local network, you get immediate response to such control characters as
> ^C or ^Y, etc.  With TCP/IP, when you issue a ^C or ^Y you must wait
> until the packet(s) already sent by the host roll through your screen
> before you see the break or interrupt take effect (say for example you
> are typing a file to your screen).  I can control the situation with ^C
> because I can set it as a break character on the server and the server will
> react to it by issuing an inband or out-of-band break and flush the packets.
> However, with ^Y, which in this example would stop the output until you
> issue a continue command on the host, you must wait for an additional few
> screens of output to go by before it stops.  If you set this as the break
> character to flush packets, the output will stop immediately but when you
> do a continue you will have lost a lot of data.

> The hosts in my situation are various DEC machines running under VMS and
> using DEC's UCX TCP/IP software.  DEC has not shown us a way to change the
> TCP packet size.  Ideally I think we need to reduce the Telnet packet size
> to provide better response time for terminals without affecting the FTP
> transfer rate.  I also have this problem on one host running Wollongong
> TCP/IP software.

> Has anybody out there run across this situation and been able to resolve it?
> I even asked 3COM about it since they have VAXes at their site but they
> could not provide me with a solution.  I would appreciate any help with this
> so I can decide whether to go ahead with installing additional TCP/IP
> servers or have to go with LAT servers to provide the proper response time.

    Yes, a number of MultiNet customers have made the same complaint.
In our next release we provide a way of reducing the buffer size.  The
real problem lies in the VMS terminal driver which doesn't always
notify the VMS terminal port driver (i.e., the TELNET server) that an
'abort' should occur.  The best workaround would be to configure your
TELNET server to send an IAC AO after ^C or ^Y, or to use timing-mark
flushing when the user types these characters.

						    Ken
-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 12:10:51 GMT
From:      MEYSTMA@DUVM.BITNET (MM438)
To:        comp.protocols.tcp-ip
Subject:   Unsub

I am truly sorry to disturb and distribute this message to the entire
list, but requests to tcp-ip-request seem to go unheeded, and my
mail queue is constantly filled with messages from tcp/ip that I'm not
ready for. Can someone out there sign me off the list? thanks -MM438

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 12:42:17 GMT
From:      usc!samsung!interlan.InterLan.COM!backman@ucsd.edu  (Larry Backman)
To:        tcp-ip@nic.ddn.mil
Subject:   Is there a License server RFC?


Is there an RFC written for a License Server application.  I am looking
for something that would monitor and control the concurrent execution of
a single networked copy of any executable program.  I want to be able to
put an executable on a network drive, and control the number of people
using it at a single time.



					Larry Backman
					backman@interlan.com
					uunet!interlan!backman
-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Jun 90 16:52:37 EDT
From:      Bill Streilein <bstreile@wellfleet.com>
To:        tcp-ip@nic.ddn.mil

Hello,

I'm interested in finding out about various IP implementations.
Specifically, I'd like to find out how different implementations 
chose to organize the IP route information (i.e.  hash tables, 
balanced trees, etc.) and why.

If there's enough response, I'll post the results of the search.

Then again, maybe someone's already done this and all I need is a pointer
to the right doc.  :-).


Thanx in advance,
Bill Streilein
bstreile@wellfleet.com
Wellfleet Communications, Inc.

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jun 90 00:52:24 -0700
From:      sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz)
To:        amazon.llnl.gov!oberman@lll-winken.llnl.gov, tcp-ip@nic.ddn.mil
Subject:   Re: Knowledge-is-Power Department
> From: amazon.llnl.gov!oberman@lll-winken.llnl.gov
> 
> The problem stemmed from a bug in their mail software that caused all mail to
> start bouncing when a partition filled up. However the bounced mail was not
> bounced correctly....
> Since the problem began on Friday and there is noone in the office at Portal
> over the weekend, it took a while for the problem to be corrected.

	there's no one there on weekends?  or no one monitors the system
	after 1700 Friday?  at a "major relay station" no less? gads zooks.
	one would think a partition filling up would be noticed well in
	advance of "der woche ende", or that the real "hackers" would 
	keep an eye peeled for system misbehaviour in general.

	Steven
-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 13:27:32 GMT
From:      mcsun!hp4nl!dutrun!dutetvg.tudelft.nl!pieter@uunet.uu.net  (Pieter Venemans)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP and T2000 modems
I am trying to use two Telebit T2000 modems for a SLIP link between my
SUN at home and a SUN at the university. It works, but the performance
is quite disappointing. With plain 2400 baud modems, I get a transfer
rate of 0.21 kbyte/sec with ftp (quite good), but with the T2000s it is
only 0.65 kbyte/sec. I know, PEP is not ideal for this application and
it would be better to use V32 full-duplex modems, but these T2000s are
the only ones we have.

Does anyone have an explanation for this bad performance? Is there
any way to tune TCP, SLIP or the T2000s (secret registers, maybe?)
for a better throughput?

Here are the details: SUN-3/60 with SunOS 4.0.3, SUN-2/50 with SunOS
3.5 and 4.3-tahoe BSD TCP, Compressed header SLIP, very clean (local)
telephone connection. 

Thanks!
--
Pieter H.A. Venemans, Delft University of Technology, the Netherlands
DOMAIN: venemans@et.tudelft.nl         BITNET/EARN: venemans@hdetud53
UUCP:   ...!mcsun!hp4nl!dutrun!dutetvg!pieter     VOICE:  +3115786272
-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 15:06:25 GMT
From:      mcsun!ukc!axion!vision!ukpoit!ukpoit.co.uk!ian@uunet.uu.net  (Ian J Spare)
To:        tcp-ip@nic.ddn.mil
Subject:   UUCP over TCP Problems
Our organisation is currently evaluating local area networks. We have the 
following equipment :

      2 x NCR Tower 32/400 running SysV R3 Unix and Win-TCP
      1 x NCR Tower 32/400 running SysV R2 Unix and Excelan TCP/IP
      Several PC'c Running PC/FTP and interdrive
      Various Terminal servers etc.

We have some problems with the boxes and wondered if anyone else had seen
similar or knew a solution.

Firstly, we have configured the two Rel 3 machines to talk to each other using
UUCP over TCP  , the normal file transfers work OK but a 'cu' to a machine will 
connect and instantly lose carrier and disconnect.

Secondly, we tried to get the Rel 2 machine using Excelan to talk to the WIN 
machines using UUCP over TCP , this was spectactularly unsuccessful !! The
best we got was the machine calling itself , handy :-) ??? The files were
setup as suggested in the Excelan manual , this seems to document an earlier
release of UUCP than Rel 2 NCR's actually have.

Finally , I am very interested in any info. that people have about SNA gateways
on TCP LANS.  We have been unsuccessful in locating a suitable gateway with the kind of functionality we require. We have been offered gateways with LU1 and 
3270 capablility but none ( so far :-) ! ) with LU6.2 . The situation I envisage
is being able , from a Unix host, talk LU6.2 through a gateway to an IBM host.
I am quite happy for any ( potential ) suppliers of this sort of kit to
contact me directly.

Thanks In Advance ,
Ian Spare

--
  Ian Spare                         |
  iT                                |        E-mail : ian@ukpoit.uucp
  Barker Lane                       |        BANG-STYLE : ......!ukc!ukpoit!ian
  CHESTERFIELD S40 1DY              |        VOICE : +44 246 214296
  Derbys, England                   |        FAX   : +44 246 214353
--------------------------------------------------------------------------------
      iT - The Information Technology Business Of The Post Office
-----------------------  In Tune With Technology -------------------------------
-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 15:06:57 GMT
From:      usc!samsung!umich!umeecs!msi-s0.msi.umn.edu!cs.umn.edu!wagner@ucsd.edu  (Paul J. Wagner)
To:        tcp-ip@nic.ddn.mil
Subject:   Backups over tcp-ip connection
A friend of mine has a Vaxstation running Ultrix on a tcp-ip network
with a Vax running VMS.  He's interested in the possibility of backing
up the Ultrix station on the Vax over the network.

Is anyone doing this sort of thing?  Any pointers on what software would
be necessary or on what other requirements exist?  Is this even possible?

Any and all information would be much appreciated - please respond by
email and I'll summarize to the net.

Thanks much,

Paul
-- 
* Paul J. Wagner                Internet - wagner@cs.umn.edu              *
* Computer Science Department   UUCP	 - ...!rutgers!umn-cs!wagner      *
* University of Minnesota       or, 120 S. Michigan, Eau Claire, WI 54703 *
*     "think globally, act lexically"                                     *
-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 15:14:26 GMT
From:      amazon.llnl.gov!oberman@lll-winken.llnl.gov
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Knowledge-is-Power Department
In article <9006190805.AA23855@la.tis.com>, ho@LA.TIS.COM (Hilarie K. Orman) writes:
> My sense of frustration at the portal fiasco was alleviated this
> evening when I glanced at a recently obtained copy of "!%@:: A
> Directory of Electronic Mail Addressing and Networks", by Donnalyn
> Frey and Rick Adams, and learned that Portal is a General Subscription
> Service based in Cupertino, offering UUCP and USENET feeds.  Its voice
> number is 408-973-9111, and it takes email at CS@cup.portal.com.  This
> sort of information suggests more constructive activities to take
> against email blizzards than sending mail into the fray and becoming
> part of the problem.  Like this note.  I hope no one has to see it
> more than once.
 
I spoke with the management of portal Monday morning. I was told that I was
about the hundredth caller.

The problem stemmed from a bug in their mail software that caused all mail to
start bouncing when a partition filled up. However the bounced mail was not
bounced correctly. It appears that it was resent like a new message with a new
ID.

Since there was a subscription to info-tcp-ip involved, all of the mail was
re-posted to comp.protocols.tcp-ip...over and over again.

The folks at portal were most apologetic and by the time I called the problem
was already fixed. Hopefully they will find the problem in the mailer and get
it fixed so that the problem will not recur next time a disk gets full.

Since the problem began on Friday and there is noone in the office at Portal
over the weekend, it took a while for the problem to be corrected.

While !%@:: was outdated before it every hit the streets, it is still a
valuable reference for most any mail system operator. But I found Portal by the
use of the whois server at the NIC. It's another very useful tool for those
with Internet connectivity.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 17:55:04 GMT
From:      usc!cs.utexas.edu!mtecv2!alfonso@ucsd.edu  (Alfonso Jesus Trevino Cantu)
To:        tcp-ip@nic.ddn.mil
Subject:   RPC's for Macintosh
Does anybnody know of a product that lets a C programmer in Mac make Remote
Procedure Calls? By the way, I'm also interested in products that implements
NFS in Macs.

Thank you
Alfonso
-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 18:02:41 GMT
From:      dhc@lanl.gov  (Dave Carter)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Networking RT11
thanks to all of you who responded.  it appears that Process Software
has tcp/ip for rt11.  i will contact them.

						- dave
dhc@lanl.gov
-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 19:04:51 GMT
From:      zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!mailrus!usenet.ins.cwru.edu!george.ces.cwru.edu!rck@tut.cis.ohio-state.edu  (Rob Knauerhase)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP for Ungermann-Bass cards?

After repeated assurances that the only TCP/IP protocol package for the
Ungermann-Bass NIUPC card was from Ungermann-Bass, and that it was, well,
kind of a minimalist statement in networking, I recently heard that
_someone_ else (possibly FTP Software) were now supporting the card.

    I looked several weeks ago for a packet driver from a couple
distribution sites and was disappointed.  Does anyone know of a TCP/IP
package for this card, or better yet a packet driver for it?

Thanks 10^6.
Rob Knauerhase
+-------------------------------------------------------------------------+
|Robert C. Knauerhase                          [new alumnus]              |
|   rck@ces.cwru.edu,knauer@cwru.bitnet | Case Western Reserve University |
|   knauer@earth.lerc.nasa.gov          | NASA Lewis Research Center      |
+---------------------------------------+---------------------------------+
|   "Computers are different from telephones.  Computers do not ring."    |
|                    -- A. Tanenbaum, "Computer Networks", p. 32          |
+-------------------------------------------------------------------------+
-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 20:34:46 GMT
From:      ubvax!mcs@uunet.uu.net  (Mick Scully)
To:        tcp-ip@nic.ddn.mil
Subject:   OSI/NM - Information Anyone?
The trade rags have indicated that the OSI/NM group has released their
first draft of a network management spec (with MIB).

Does anyone know if the spec and MIB is online anywhere?

Thanx in advance!

Mick
-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      20 Jun 90 21:35:27 GMT
From:      black@beno.css.gov  (Mike Black)
To:        tcp-ip@nic.ddn.mil
Subject:   MNP to Telebit locks up
Can anyone tell me why my MNP Class 9 modem locks up a Telebit Trailblazer?
When they connect the immediately hang-up and then the Telebit won't generate
and answer carrier until reset.  What gives?  This has happened on two 
different MNP modems with the same Trailblazer.  Any switches that can be
set to prevent this from happening?
Please e-mail replies and I will summarize.
Mike...
--
-------------------------------------------------------------------------------
: usenet: black@beno.CSS.GOV   :  land line: 407-494-5853  : I want a computer:
: real home: Melbourne, FL     :  home line: 407-242-8619  : that does it all!:
-------------------------------------------------------------------------------
-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 90 04:07:28 GMT
From:      munnari.oz.au!murtoa.cs.mu.oz.au!viccol!timcc@uunet.uu.net  (Tim Cook)
To:        tcp-ip@nic.ddn.mil
Subject:   Need help configuring SLIP interface under DYNIX
I have a problem using a Sequent as a gateway to other networks via SLIP.

I have the following:

1.  One class B network, which is our local network.

2.  One class C network, which is the SLIP network.

3.  One Sequent, running DYNIX 3.0.12, on both networks.

The SLIP network is a sub-net of the class B network that connects to its
remote end.  I used the following commands to configure the SLIP interface,
`sl0':

	% ifconfig sl0 x.y.z.2 x.y.z.1 netmask 0xffffff00
	% route add default x.y.z.1 1

The route command sets up a default route, so that all non-local traffic is
directed through the SLIP link.  I'm sure this is something that has been
done many times before.

The problem is, some routing works, some doesn't.  From our local host that
has the SLIP interface, I can communicate with the host on the other end of
the SLIP network, and one other host on the class B net that the SLIP net
is a sub-net of.  However, people at sites on the remote class B net, and
another net connected to that net tell me they can communicate with hosts
at our site, and local hosts that are not the host with the SLIP interface
can communicate with remote hosts.

Being nothing much of an expert at IP, I have reached a state of
bewilderment.  If anyone out there can offer any clues as to
what/why/how-to-fix, I would be grateful.
-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Thu 21 Jun 90 11:44:18-PDT
From:      VANCE@TGV.COM (L. Stuart Vance)
To:        wagner@cs.umn.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Backups over tcp-ip connection
>Date: 20 Jun 90 15:06:57 GMT
>From: usc!samsung!umich!umeecs!msi-s0.msi.umn.edu!cs.umn.edu!wagner@ucsd.edu  (Paul J. Wagner)
>Organization: University of Minnesota, Minneapolis - CSCI Dept.
>Subject: Backups over tcp-ip connection
>
>A friend of mine has a Vaxstation running Ultrix on a tcp-ip network
>with a Vax running VMS.  He's interested in the possibility of backing
>up the Ultrix station on the Vax over the network.
>
>Is anyone doing this sort of thing?  Any pointers on what software would
>be necessary or on what other requirements exist?  Is this even possible?

Our MultiNet TCP/IP for VMS package supports an RMT (Remote MagTape) server,
allowing you to use the UNIX rdump and rrestore utilites to backup/restore
files from your ULTRIX box to your VMS system.  Please drop me a note if you
would like any additional information/details.

Regards,

L. Stuart Vance
TGV, Inc.
-------
-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jun 90 10:20:44 EDT
From:      Charles Lynn <clynn@BBN.COM>
To:        Kenneth Adelman <Adelman@tgv.com>
Cc:        mpare@aqua.whoi.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  [mep@aqua.whoi.edu (Michael E. Pare): Terminal Server Response Time]
FYI, another thing that the old TOPS20 code did was to inform TCP
of the terminal's baud rate. TCP then timed the generation and
transmission of packets to match that rate; the result was a
"much more responsive" system.
-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jun 90 10:20:57 EDT
From:      "Mr. Donald W. Garner (CADIG  STAFF) " <don@usna.navy.mil>
To:        tcp-ip@NIC.DDN.MIL
Subject:   UUCP and USENET Feeds
Are there any organizations, other than UUNET Communications and PSI,
that provide UUCP and USENET feeds to the VA/DC/MD area?

Thanks - Don Garner (don@usna.navy.mil)
-----------[000398][next][prev][last][first]----------------------------------------------------
From:      ljm@obelix.twg.com
To:        tcp-ip@nic.ddn.mil
Cc:        
Subject:   Re: Print Server protocol specs

>I would like some information on Print Servers under the TCP/IP
>protocol suite. Are there any standard specs or protocols for print servers?
>
>I have looked at the RFC index at SRI-NIC and there does not seem to be any
>RFC for Print Servers...

The finalized draft version of the LPR RFC will be appearing on
print-wg@pluto.dss.com around July 1st.  It should then
be available as an RFC shortly after the July/August IETF.

enjoy,
leo j mclaughlin iii
Chair, Network printing WG
ljm@twg.com

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 90 12:13:41 GMT
From:      zaphod.mps.ohio-state.edu!samsung!interlan.InterLan.COM!backman@tut.cis.ohio-state.edu  (Larry Backman)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Motrning of the parsinf of the ARP@NET
In article <9006161407.1.12619@cup.portal.bom> news@intercon.UUCP writes:
>In article <2339@rpeedy.mbnc.org>, jrr@scamp.boncert.ndt (Joe Ragland( writes:
>> Yea, maybe in good h`m radio DXpedithnn rtyle,  Dan Lynch could hssud a
>> certifhcatd for exbhanfing mail with a net 10 host at Interop?
>
>I'm befinnhng to like this ide` more and more...
>
>It could also be fun to five the shov backbond routers "historically
>significant" IMP nales, so that you could do tracernutes and so on...
>
>--
>Amanda Walker, InterCnn Systems Corporatinn
>--
>"Y'knov, you can't have, lhke, a light, without a dark to stick it in...
> Ynu know what I'm sayin'>"     -,@rln Guthrid

I think Portal ought to turn on checksums in addition to their other
problems......
-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      Thu, 21 Jun 90 16:17:18 EDT
From:      jbvb@vax.ftp.com  (James B. Van Bokkelen)
To:        zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!mailrus!usenet.ins.cwru.edu!george.ces.cwru.edu!rck@tut.cis.ohio-state.edu  (Rob Knauerhase)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP for Ungermann-Bass cards?
We support the two U-B 'dumb' cards, sometimes known as the NIC/PC
(supported for about two years) and the NIC/PS2 (in beta last week).
We don't support the NIU (smart) cards, unless U-B or someone else
has recently developed either a Packet Driver or an NDIS driver for
them.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 90 14:26:26 GMT
From:      sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!xylogics!transfer!lectroid!jjmhome!junkyard!junkyard.uucp@ucsd.edu  (Evan Ross)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for SNMP parser

	Can anyone point me towards a publicly available SNMP parser?
	The RFC's are quite thorough in terms of abstract definitions,
	but lacking in terms of practical information.


	Evan Ross,	{think,xylogics}!signet!evan, or junkyard!evan
-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 90 14:53:05 GMT
From:      usc!ucselx!petunia!news@ucsd.edu  (Ralph Nicovich)
To:        tcp-ip@nic.ddn.mil
Subject:   MX records


I have a problem with SMTP on campus. It has to do with MX records.
If a user sends mail to a place that uses MX records, so that the
mail address is not a real host name, the mail bounces.

This occurs with AIX machines as well as SUNs. I located a fix for
68000 based SUNs, and am told that the next release of AIX will
fix this.

Does anyone have a fix for SUN 386i's ?
Are there any public machines that mail can be sent thru, that
will deliver the mail for my machines ?
Are there any "tricks" that work for the general case of a machine
that does not support MX records ?

Thanks for any help.
Ralph Nicovich
Network engineering
Cal Poly State University.
rnicovic@polyslo.calpoly.edu
-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Thu 21 Jun 90 18:53:28-EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        tcp-ip@nic.ddn.mil
Cc:        lynch@A.ISI.EDU
Subject:   re: How long before I can reopen a closed socket?
Well, I tried to send this reply to the originator and not the whole list,
but the address was just too much to swallow!
Dan
                ---------------

Mail-From: OPERATOR created at 21-Jun-90 17:50:36
Date: Thu 21 Jun 90 17:50:36-EDT
From: The Mailer Daemon <Mailer@A.ISI.EDU.#Internet>
To: LYNCH@A.ISI.EDU.#Internet
Subject: Message of 21-Jun-90 00:28:02

Message failed for the following:
sun-barr!newstop!texsun!texbell!ficc!ihsan@ames.arc.nasa.gov.#Internet: 554 <sun-barr!newstop!texsun!texbell!ficc!ihsan@ames.arc.nasa.gov>... Unknown uucp host sun-barr
	    ------------
Date: Wed 20 Jun 90 21:28:01-PDT
From: Dan Lynch <LYNCH@A.ISI.EDU>
Subject: Re: How long before I can reopen a closed socket?
To: sun-barr!newstop!texsun!texbell!ficc!ihsan@ames.arc.nasa.gov
In-Reply-To: <DY34WR8@ccs.ferranti.com>
Message-ID: <12599475864.32.LYNCH@A.ISI.EDU>

Jaleel,  You can certainly build a server to do exactly as you
described.  It would only listen for specific ports from specific
addresses.  The algorithm for selecting port numbers for TCP and
UDP that are not the "well known port numbers" is entirely up
to the hosts in question.  You are looking for a way to restrict
service and this is one (weak) way to do so.  "Weak" in the security
sense.  

Dan
-------
-------
-------
-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 90 15:10:48 GMT
From:      swrinde!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!IDA.ORG!zweig@ucsd.edu  (Johnny zweig)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP for Ungermann-Bass cards?

I could have sworn that NCSA Telnet supports the Ungermann-Bass card, but
that is based on some driver code I looked at three years ago that said
"change this to a 0x06 for Ungermann-Bass" or something like that.

It's worth looking into, however.  Anonynmous ftp to zaphod.ncsa.uiuc.edu
and a few minutes' poking around should tell you.

-Johnny Possibly
-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 90 18:45:11 GMT
From:      mcsun!ukc!stc!bruce@uunet.uu.net  (Bruce Munro)
To:        tcp-ip@nic.ddn.mil
Subject:   Vendor numbers et al.
Not strictly IP oriented, but I know people round here are pretty
knowledgeable.

What I'm looking for are the latest copies of a group of documents
that list which ethernet numbers have been allocated to which vendors,
packet type numbers, and so on. I've got a rather ancient copy, but it
doesn't have the info I need.

Any help/pointers appreciated.

Thanks,
-- 
Bruce Munro.  <bruce@tcom.stc.co.uk> || ...!mcsun!ukc!stc!bruce
STC Telecommunications, Oakleigh Rd South, London N11 1HB. 
Phone : +44 81 945 2174 or +44 81 945 4000 x2174
"There are no strangers, only friends we don't recognise" - Hank Wangford
-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jun 90 08:45:04 -0700
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        evan@signet.UUCP
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for SNMP parser
Get a copy of RFC1147 to find out about 2 of the 3 public domain SNMP
implementations.

/mtr
-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      21 Jun 90 21:49:45 GMT
From:      amelia!pioneer.arc.nasa.gov!welch@ames.arc.nasa.gov  (Todd Welch)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Motrning of the parsinf of the ARP@NET

        Folks -

        oh usre, go ahd `nd lauph, i membre when thissss response <ACK>
        was semt to a query about runnig XNS adn TCP over <ACK>!@<ACK> teh
        s`me cococoax. i laupheb then too, net-10 real foonly humour.

        BTW, wehres the crucible feed @?

        -todd

        welch@ames.arc.nasa.gov
        Sterling Software

        -       its only that the past has lighted our way              -
        -=      no one survived the imp route jabber of late '70s       +-)
-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jun 90 09:28:34 PDT
From:      postel@venera.isi.edu
To:        bruce@tcom.stc.co.uk, mcsun!ukc!stc!bruce@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Vendor numbers et al.

Bruce Munro:

A reasonably complete set of Ethernet nembers is included in the "Assigned
Numbers" memo, RFC-1060.

--jon.
-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 90 02:58:08 GMT
From:      usc!samsung!munnari.oz.au!metro!news@ucsd.edu  (Patrick Herlihy)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP for Ungermann-Bass cards?

In article <1990Jun21.151048.22560@IDA.ORG>, zweig@IDA.ORG (Johnny
zweig) writes:
> Path:
metro!munnari.oz.au!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!sol.ctr
.columbia.edu!IDA.ORG!zweig
> From: zweig@IDA.ORG (Johnny zweig)
> Newsgroups: comp.protocols.tcp-ip
> Subject: Re: TCP/IP for Ungermann-Bass cards?
> Message-ID: <1990Jun21.151048.22560@IDA.ORG>
> Date: 21 Jun 90 15:10:48 GMT
> References: Available upon request. :)
<1990Jun20.190451.4153@usenet.ins.cwru.edu>
> Organization: IDA, Alexandria, VA
> Lines: 9
> 
> 
> I could have sworn that NCSA Telnet supports the Ungermann-Bass card, but
> that is based on some driver code I looked at three years ago that said
> "change this to a 0x06 for Ungermann-Bass" or something like that.
> 
> It's worth looking into, however.  Anonynmous ftp to zaphod.ncsa.uiuc.edu
> and a few minutes' poking around should tell you.
> 
> -Johnny Possibly

NCSA Telnet 2.3 supports U-B PCNIC card, but not PCNIU (we have a mixture of
both.

Patrick Herlihy
-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      Friday, 22 June 1990 8:57am ET
From:      "Bill.Simpson" <09998WAS%MSU.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   subnets & router requirements
Interesting to three different streams come together at nearly the
same time....

I come down firmly on the side of variable length subnets, and a specific
recommendation that non-contiguous subnet masks be removed.

We have seen how a relatively simple subnet question (Bob Hott) can come
up with different answers from persons who clearly have a lot of experience
with the problem (Kastenholtz, Nelson, Woundy).  We need a firm, clear,
standard method of assigning subnets and addresses.

The variable length subnet mask allows very flexible grouping of hosts,
and is clearly the "right thing to do".  When explained as method of
assignment to "areas" in OSPF, I think that the "average" network
manager will understand enough to be able to come up with a workable
solution (not necessarily optimal, just workable).

The non-contiguous subnet mask, on the other hand, becomes so esoteric
that the trade-off with practicality is untenable.  This is the
"wrong thing to do", even when there are good "computer science"
algorithms for resolving the difficulties.

Some sites might have to change their old addresses.  Big deal!
Here in Michigan, the various component institutions are
discussing the breakup of the class A Merit network into
a number of class B "Autonomous Systems" to take advantage
of improvements in routing that would provide.  Once upon a time,
there was only the Merit network here.  Now we have access to
several network connections.  Things change!  If we can change
*thousands* (indeed, tens of thousands) of addresses here,
surely a few of the early sites can manage to change to meet new,
more stringent requirements to help make this a better, more reliable
network!

-- Bill Simpson
   09998was@ibm.cl.msu.edu.
   09998was@msu.bitnet
-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jun 90 11:32:01 EDT
From:      Bob Stewart <stewart@xyplex.com>
To:        sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!xylogics!transfer!lectroid!jjmhome!junkyard!junkyard.uucp@ucsd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Looking for SNMP parser
If the mailer can sort out the return address, it's smarter than I am...

I had a good experience with the SNMP code from MIT.  I believe it's available
for anonymous FTP from allspice.lcs.mit.edu.  The person who knows all about
it (the author) is Chuck Davin, jrd@allspice.lcs.mit.edu.

Enjoy.

	Bob

-----------
Bob Stewart (rlstewart@eng.xyplex.com)
Xyplex, Boxborough, Massachusetts
(508) 264-9900

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 90 11:18:49 GMT
From:      eru!luth!sunic!mcsun!hp4nl!phcoms!roes@bloom-beacon.mit.edu  (Aloys Roes)
To:        tcp-ip@nic.ddn.mil
Subject:   Serial line errors (summary)
A few weeks back I posted a request for help to get problems with serial
lines sorted out. I promised to post a summary. Here is:


From hp4nl.nluug.nl!umd5.UMD.EDU!schulman  Wed Jun  6 13:19:44 1990
Marty Schulman

If analog circuits, did the phone company run BERT tests from the DTE side of
each modem through the other end?  That is, was the complete digital
link tested including modems, or just the analog portion?

--> The circuit is digital and the BERT test was end-to-end.

Out of curiosity, what PC test package are you using?

--> It's a normal MS-DOS PC with our own-written software. It uses a
special 64K serial interface board.

Here's the strangest question: What revision Cisco firmware are you
running at each end?  This may not be a phone-related problem, but a
router-related one.  Telecom-digest readers may doubt that line errors
are in any way related to firmware, but I saw line errors on one side
of a T1 link between Ciscos jump dramatically with a firmware upgrade -
and disappear with installation of a subsequent release.

We are running software version 7.1(10) on one end and 8.0(9) at the other
end. MCI versions are 1.3 and 1.4. But we have swapped boards and have the
same software running on various other routers without problems.



From hp4nl.nluug.nl!Sun.COM!ckollars  Wed Jun  6 16:25:30 1990
Organization: Sun Microsystems, Billerica MA
chuck kollars

I'll bet they tested only the portion they're responsible for, which is the
line itself.  If the line is okay, but the device sees errors, you can conclude
that the problem is somewhere in between.  In other words, the problem is
either the modem, or the cable between the modem and the router.  The modem
can probably give you self-diagnostic information.  For the cable, insert your
PC monitor first next to the modem, then enxt to the router, and see if there
are differences.  Likely problems include: a) modem and router are plugged into
different line supply circuits that have slightly different ground levels;
b) the shield in the cable is not connected to ground [look for jumpers
inside the modem and the router]; or c) the cable is too long or is wrapped
around some interfering device like an elevator motor or a flourescent light.  

I'm not sure what the difference is between Frame errors and CRC (FCS) errors
in the serial world.  I do know that in the Ethernet world, there's no real
difference--it's all just different terminology and different conventions.  
If a packet got garbled, _two_ things are probably true: 1) the CRC doesn't
compute, and 2) the packet doesn't appear to be a multiple of 8 bits long.
So how do you count the error?  Well, not everybody answers that question
the same way.  What I do on the Ethernet world is to add up Frame errors and
CRC errors from each device, and compare only the _totals_.


From hp4nl.nluug.nl!relay.EU.net!SNYCENVM.bitnet!RTRN  Wed Jun  6 20:17:09 1990
Organization: State University of New York - Central Administration
Tom Neiss

We, SUNY Central, experienced a similar problem with another vendor.  It
boiled down to RS232 levels at the interface.  They supported rs232 with a
gender mender cable from v.35(rs423).  Having had experience in this area I
suspected it to be the problem.  The levels of 423 (-5 to+5v was not quite
good enough for our rs232 interface, consequently errors showed up.
Ask cisco what their interface is and if it has  REAL RS232(levels included)
support on that interface.  A v.35 interface showed no problems on our equip-
ment.
The vendor did fix the problem, pronto.

From hp4nl.nluug.nl!cs.arizona.edu!ric  Wed Jun  6 21:07:31 1990
University of Arizona
Ric Anderson

Find out what baudrate the telecom people tested the line at.  
were having MAJOR problems of the type you described on a
line here (about 100 miles of AT&T leased line), and yet the
phone folks said the line was error free.  When I pushed,
one tester asked "what rate do you use the line at?".  When
I replied "9600 baud", he said "Oh, we test at 1200, unless
otherwise requested!".  When the phone folks re-tested the
line at 9600, they found a defective widget and replaced it.

Moral of the story:  Baud rate matters a lot, especially in Bit
Error Rate tests...

--> We have a 64K digital circuit and I have seen the BERT tests running at
that speed.


From hp4nl.nluug.nl!RELAY.PRIME.COM!ARIEL  Wed Jun  6 22:57:58 1990
Prime Computer, Inc.
Robert Ullmann

The cisco has a known (to them :-) problem with framing on
sync lines. It is supposed to be less critical at higher
speeds. (which is the opposite of what I would expect; I
would expect low speeds to run fine, and high (> 19.2) to
have trouble...)

The work-around is to increase the "transmitter delay".
Try setting it to 20,000 usec, the problem should go
away, but performance will be affected. Then try decreasing
it (to 15,000, then 10,000 and so on) to find the smallest
value that works well.

Yes, this happens on lines that BERT error-free! It seems
to be triggered by large IP datagrams, which become more-data
("M" bit) sequences transmitted rapidly (on X.25; not sure
about what triggers HDLC only problems).

And complain to cisco; this is their problem (;-)

--> Tried this. Too bad it does not seem to be our problem.


From hp4nl.nluug.nl!uunet.UU.NET!bnrgate!bcars53!mussar Thu Jun  7 02:39:25 1990
BNR Ltd.
Gary Mussar

This kind of stuff can be very tricky to track down. The testing that your 
telecom people performed probably only tested to the modem itself. It 
may not have tested your cable to the Cisco. Some 64K modems use V.24 
interfaces even though V.24 is only specified to 20K. This 'usually' works
if the cables are short, but is very suseptible to noise. Some 64K modems
use V.35 signals, but bring them out on a DB25 connector. This looks like a
V.24 interface and if plugged into a V.24 interface, this may even work
a little, but not reliably. Another thing to look at is the clocking signals
from the modem and options the modem has for clocking. Some modems have 
master/slave settings to determine which end provides a stable clock and 
which end should sink to the clock. Incapatable settings do no always show
up in loopback testing but to in the data stream. (If possible, I like to
set my modems to each provide a stable transmit clock and extract the receive
clock from the remote data stream).

--> The BERT tests were done end to end. We swapped modems and cables at
both end. Nothing seems to help here. The clocking should not be a problem
because the the BERT does not give any clock-slips. Maybe we need to
investigate this a bit further since it is an international link
(UK-Netherlands) with 2 PTT's involved.


From hp4nl.nluug.nl!concert.net!sung  Thu Jun  7 13:16:21 1990
Organization: Center for Communications, MCNC; RTP, NC

We have abandoned bit error measurements in favor of cisco measurements.
In several cases we had lines that measured very nicely with BERT but the
ciscos absolutely refused to even get started, let alone run with errors.
I presently have a T1 line running sub speed for the same reason - at full
speed the errors in one direction (only one, same as your case) are so
severe that you can forget TCP connections.

One factor that seemed to be common was that we could not derive 64k
multiple channels off T1 multiplexers but 56k multiples would work. We tried
several brands of multiplexers and only one would allow the 64k multiples
to work. Even then there are some limitations. I don't exactly know what
the ciscos are sensitive to, as the same lines that it would not operate
over are perfectly adequate for other brands of equipment. This particular
brand of multiplexer we are using happens to have serrated clock (you get
the exact bits/per second requirement by omitting a certain number of clock
pulses per second) so I don't believe it's bit spacing sensitive.

In several cases where we had either bad performance or worse (one case was
that you could not send large blocks of zeroes) it was purely an
installation problem, i.e. badly terminated connectors, open or crossed
pairs, etc. We have the cisco mci cards for serial ports, and I have run
them at 6 Mb/s so it's definitely not a hardware limit.

--> We don't know what brand of multiplexer the PTT's are using. They won't
how the physical link is established. 64K is the European standard and we
have many of those.


From hp4nl.nluug.nl!cmc.com!lars  Wed Jun 13 04:02:10 1990
Organization: Rockwell CMC
Lars Poulsen, SMTS Software Engineer

A "frame" is HDLC talk for a "Physical Data Unit" (PDU). Each "frame"
carries an IP "datagram" if you use straight HDLC encapsulation.

At the end of the frame is a checksum. The HDLC spec describes this as
Frame Check Sequence (FCS). Most people use the phrase "Cyclical Redundancy
Check" (CRC) about this 16-bit checksum.


From hp4nl.nluug.nl!p1.f22.n491.z5.fidonet.org!Ernie.Bokkelkamp 
EWSD System Design Authority
Ernie Bokkelkamp

writes he has had similar problems on a 19.2 line from Johannesburg via
London to Munich. It appeared to be caused by large delays in a
statistical multiplexer. Only after connecting test-equipment he could
prove that HDLC was retransmitting packets because of these large delays.

--> what was the test-equipment that you used ?


From hp4nl.nluug.nl!ucsd.edu!foxtail!kravitz  Tue Jun 19 17:12:19 1990
Jody

I have seen problems similar to what you are describing that were caused by
the clock leads being wrong.  The test equipment usually has its own cables
and works perfectly.

--> We have to check this.

Thanks to all who responded,


-- 
     regards,

Aloys Roes, Philips Components, Building BC-136, |  Tel. : + 31 40 72 30 62
P.O.Box 218, 5600 MD Eindhoven, The Netherlands  |  Email: roes@seri.philips.nl
-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 90 14:54:16 GMT
From:      gamiddle@maytag.waterloo.edu (Guy Middleton)
To:        comp.protocols.tcp-ip,comp.sys.proteon
Subject:   Proteon router losing ICMP packet

We have a Proteon p4200 as a gateway between two subnets.  If I try to send
a ping through it, the first packet seems to be lost.  Subsequent attempts
succeed, but if I wait long enough, or reboot the gateway, it happens again.

Has anybody seen this?  Can I fix it somehow?

 -Guy Middleton, University of Waterloo		gamiddleton@watmath.waterloo.edu
		(+1 519 885 1211 x3472)		gamiddleton@watmath.uwaterloo.ca

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 90 17:17:19 GMT
From:      ddk@lanl.gov  (David D Kaas)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP terminal servers


	We have an XMP18 with UNICOS 5.0 , VAX/VMS frontends running CRAY
	station software and TCP/IP over NSC Hyperchannel and a few SUNs
	running TCP/IP through an NSC router.  Terminals currently use the
	VAX for access to the CRAY but we are going to remove the VAX and
	replace it with a UNIX frontend.  The new UNIX frontend will not have
	terminal ports.
	What do other sites use for TCP/IP terminal server access to a CRAY ?
	We have tried an Ungermann-Bass terminal server but it does not support
	line mode properly.  Are there any TCP/IP terminal servers that support
	line mode? Something that will work with a CRAY, SUN and a VAX/VMS with
	Wollongong TCP/IP software.

	Dave Kaas
	Boeing Computer Services Richland
	D. O. E. Richland
	Richland, WA 99352
	(509) 376-6386
	e41126%rlvax1.lanl.gov
	ddk@beta.lanl.gov

-- 
Dave Kaas - D.O.E. Richland, Wa.
	e41126%rlvax3.xnet@lanl.gov
-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Jun 90 18:05:58 GMT
From:      "Douglas P. Ambort" <douglas@TWG.COM>
To:        tcp-ip@nic.ddn.mil
Subject:   Re. WIN/OSI phases
Re. Edward Levinson's email of 13 June and the UNIX Today! article of 
June 11 about The Wollongong Group's WIN/OSI product family:

Mr. Levinson is right to suggest that the article is confused about
WIN/OSI's technical foundation.  The article did misinterpret 
our press release.  

For example, the Phase I part of the TCP/IP-to-OSI transition strategy 
that UNIX Today! refers to isn't really a new phase or step towards OSI
at all.  WHen you transition from one state to another, you gotta start 
somewhere, and the starting point for most of us is TCP/IP. That's all.
UNIX Today! probably got the idea that we had modified TCP/IP "lower 
layers" when we talked about how our OSI upper layer services product 
provides OSI applications' with access to TCP/IP, by implementing RFC 
1006. 

So, Mr. Levisnon is right to suggest that a description of WIN/OSI 
"sounds likes the ISODE". Most of WIN/OSI _is_ derived from the ISODE.  
Except our lower layers.  Also, our Directory Services and X.400 are
derived directly from UCL, in advance of their getting folded 
into ISODE.

As for the network managment portion of the UNIX Today! article:
we _do_ include in our OSI Upper and Lower Layer Services an SNMP
based network management agent... we do that for our TCP/IP, too.
Not "too good to be true", just true.

If there are more questions, please call me directly, so that we 
don't use Internet resources for commercial interests.
Thanks.

.--------------------------------------------------------------------.
| Douglas Ambort                          The Wollongong Group, Inc. |
| Product Manager                              1129 San Antonio Road |
| INTERNET: douglas@twg.com                      Palo Alto, CA 94303 |
| 						      (415) 962-7213 |
| 					         FAX: (415) 969-5547 |
`--------------------------------------------------------------------'




-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 90 18:17:29 GMT
From:      09998WAS@MSU.BITNET ("Bill.Simpson")
To:        comp.protocols.tcp-ip
Subject:   subnets & router requirements

Interesting to three different streams come together at nearly the
same time....

I come down firmly on the side of variable length subnets, and a specific
recommendation that non-contiguous subnet masks be removed.

We have seen how a relatively simple subnet question (Bob Hott) can come
up with different answers from persons who clearly have a lot of experience
with the problem (Kastenholtz, Nelson, Woundy).  We need a firm, clear,
standard method of assigning subnets and addresses.

The variable length subnet mask allows very flexible grouping of hosts,
and is clearly the "right thing to do".  When explained as method of
assignment to "areas" in OSPF, I think that the "average" network
manager will understand enough to be able to come up with a workable
solution (not necessarily optimal, just workable).

The non-contiguous subnet mask, on the other hand, becomes so esoteric
that the trade-off with practicality is untenable.  This is the
"wrong thing to do", even when there are good "computer science"
algorithms for resolving the difficulties.

Some sites might have to change their old addresses.  Big deal!
Here in Michigan, the various component institutions are
discussing the breakup of the class A Merit network into
a number of class B "Autonomous Systems" to take advantage
of improvements in routing that would provide.  Once upon a time,
there was only the Merit network here.  Now we have access to
several network connections.  Things change!  If we can change
*thousands* (indeed, tens of thousands) of addresses here,
surely a few of the early sites can manage to change to meet new,
more stringent requirements to help make this a better, more reliable
network!

-- Bill Simpson
   09998was@ibm.cl.msu.edu.
   09998was@msu.bitnet

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      22 Jun 90 19:59:57 GMT
From:      noose.ecn.purdue.edu!mentor.cc.purdue.edu!mace.cc.purdue.edu!abe@iuvax.cs.indiana.edu  (Vic Abell)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Vendor numbers et al.

Get pub/rfc/ethernet_vendor_addrs from pprg.unm.edu via anonymous ftp.
It was last updated in March, 1990.
-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      23 Jun 90 01:58:09 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!metro!ipso!appleoz!ksand@ucsd.edu  (Kent Sandvik)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Vote for/against "comp.protocols.iso.migration"
towfiq@interlan.Interlan.COM (Mark Towfigh) writes in article <TOWFIQ.90Jun15132559@interlan.Interlan.COM>:
:    In article <4488@infmx.UUCP> kwang@infmx.UUCP (Kwang Sung) writes:    
:    	   Now I would like to finalize my proposal on creation of a new
:       newsgroup "comp.protocols.iso.migration".
    
:    This is ridiculous.  Comp.protocols.iso *maybe* had about two articles
:    a day in it before this "proposal" came up, and it jumped to a
:    whopping five after that.  I see *no reason* for the creation of a new
:    newsgroup, especially since the normal procedures for group creation
:    have been disregarded, or garbled at best.

Same comment, there's no need to create a new newsgroup just for the
sake of it.  comp.protocols.iso is not exactly a huge newsgroup, so the
transition group would have even less traffic. 

Post entries about migration here and in c.p.tcp-ip, and when the volume
justifies that there should be a new group, then create if after proper
voting. 

Another note is that if you separate transition issues to a single
group, you will miss a lot of people that would never read OSI related
issues, but read for instance tcp-ip newgroups. 

Regards,
Kent
-- 
Kent Sandvik            --  Apple Australia Developer Tech Support
{uunet,mcvax}!munnari!appleoz.oz!ksand, ksand@appleoz.oz.au (OR ksand@apple.com)
AppleLink: AUSTAUX             Disclaimer: "Apple does not sell my opinions"
"As carbonbased entities our purpose in life is to find problems for computers to solve" 
-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      Sat, 23 Jun 90 11:34:31 EDT
From:      perry@MCL.Unisys.COM (Dennis Perry)
To:        tcp-ip@nic.ddn.mil, weintrau%mpx0.lampf.lanl.gov@lanl.gov
Cc:        perry@mcl.unisys.com
Subject:   Re:  Help with Non-Homogeneous LAN?
Barbara, have you talked to the C-5 networking people over in C-Division?

There are some knowledgeable people there or in C-8 who could help you.

dennis
-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 90 10:55:52 GMT
From:      Ben@blx-s.Prime.COM (Ben Kemp; Technical support - Prime Netherlands)
To:        comp.protocols.tcp-ip
Subject:   Request info on PC tool.


    To :         TCP-IP@NIC.DDN.MIL
    From :       Ben Kemp  (PDN: Ben@BLX-S)
    Subject :    Request for information on a Lan monitor.
    Date :       SUN, 24 JUN 1990

    ****************************************************************

    Since I am looking for a PC-tool to monitor TCP activity I
    like to ask you out there to give me some advise which tool
    is the best tool to monitor the Lan.

    Some minimum requirements :

    * The tools has to run on a AT IBM compatible PC.

    * If it is anyway possible to run on a Western Digital 8003
      inferface card.

    Thanx in advance.



    Kindest regards,

    Ben Kemp
    Prime Computer B.V.
    Netherlands

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 90 14:23:58 GMT
From:      cs.utexas.edu!uwm.edu!rpi!image.soe.clarkson.edu!news@tut.cis.ohio-state.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Request info on PC tool.
In article <9006241144.AA07690@ucbvax.Berkeley.EDU> Ben@blx-s.Prime.COM (Ben Kemp; Technical support - Prime Netherlands) writes:

       Since I am looking for a PC-tool to monitor TCP activity I
       like to ask you out there to give me some advise which tool
       is the best tool to monitor the Lan.

       Some minimum requirements :
       * The tools has to run on a AT IBM compatible PC.
       * If it is anyway possible to run on a Western Digital 8003
         inferface card.

The combination of netwatch and the packet drivers can do what you want to do.
Netwatch is in pcippkt.arc, available everywhere the packet drivers are:

		The Clarkson packet driver collection

Availability

The Clarkson collection of packet drivers is available by FTP, by
archive-server, Fido file request, and by modem.  They come in two flavors
-- executables only (drivers.arc), and source+executables (driverss.arc).
All of the following instructions apply to both drivers.arc and
driverss.arc.

FTP:

sun.soe.clarkson.edu:/pub/ka9q/drivers.arc
grape.ecs.clarkson.edu:/e/tcpip/drivers.arc

Archive-server:

Send mail to archive-server@sun.soe.clarkson.edu and put the following
command as the body of your message:
	help

This will send you a help message.  Reading this help message will tell
you how to fetch the packet drivers.

Modem:

Call the Clarkson Heath User's Group's BBS: (315)268-6667, 8N1,
1200/2400 Baud, 24 hours.  Change to file area 24 and download drivers.arc.

Opus:

260/360 in the Nodelist.  Drivers.arc is file requestable.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
In Communism's central planning, citizens are told "you will make widgets".
In Capitalism's advertising, citizens are told "you will buy widgets".
-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 90 12:55:52 +0200
From:      Ben Kemp; Technical support - Prime Netherlands         <Ben@blx-s.Prime.COM>
To:        tcp-ip@nic.ddn.mil
Subject:   Request info on PC tool.




    To :         TCP-IP@NIC.DDN.MIL
    From :       Ben Kemp  (PDN: Ben@BLX-S)
    Subject :    Request for information on a Lan monitor.
    Date :       SUN, 24 JUN 1990

    ****************************************************************

    Since I am looking for a PC-tool to monitor TCP activity I
    like to ask you out there to give me some advise which tool
    is the best tool to monitor the Lan.

    Some minimum requirements :

    * The tools has to run on a AT IBM compatible PC.

    * If it is anyway possible to run on a Western Digital 8003
      inferface card.

    Thanx in advance.



    Kindest regards,

    Ben Kemp
    Prime Computer B.V.
    Netherlands
-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 90 16:30:06 GMT
From:      sun-barr!ccut!komaba!cotton!shin@apple.com  (Shin Yoshimura)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP and T2000 modems
In article <1565@dutrun.UUCP> pieter@dutetvg.tudelft.nl (Pieter Venemans) writes:

 >I am trying to use two Telebit T2000 modems for a SLIP link between my
 >SUN at home and a SUN at the university. It works, but the performance
 >is quite disappointing. With plain 2400 baud modems, I get a transfer
 >rate of 0.21 kbyte/sec with ftp (quite good), but with the T2000s it is
 >only 0.65 kbyte/sec. I know, PEP is not ideal for this application and
 >it would be better to use V32 full-duplex modems, but these T2000s are
 >the only ones we have.

I'm now working to use two T2000 for a dial-up SLIP link between Sun-3
and micro VAX II. Slip driver of micro VAX is unsupported software of
Ultrix 3.1. One of Sun-3(SunOS4.0.3) is Rayan Zachariassen's which
distributed with slipware. 

 >Does anyone have an explanation for this bad performance? Is there
 >any way to tune TCP, SLIP or the T2000s (secret registers, maybe?)
 >for a better throughput?

I got the rate of about 1 kbyte/sec with ftp.  Setups of T2000 are no async
protocol support and data compression with PEP mode. Both side of serial
interface speed are 19.2Kbps.

 >Here are the details: SUN-3/60 with SunOS 4.0.3, SUN-2/50 with SunOS
 >3.5 and 4.3-tahoe BSD TCP, Compressed header SLIP, very clean (local)
 >telephone connection. 

It seems that for compressed SLIP (Jacobson's ?), transmission method
of T2000 (data compression, packet delay ?) is bad.
--
Shin Yoshimura
Dept. of Chem., Coll. of Arts & Sci., The Univ. of Tokyo., JAPAN
-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      24 Jun 90 17:16:36 GMT
From:      sdd.hp.com!elroy.jpl.nasa.gov!suned1!efb@ucsd.edu  (Everett Batey)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Packets stuck on MILNET
Apologize if you have read this before, the problem wont go away.  We
just moved our interior net from 192.31.106 to 137.24.  We have been 
successful for many months at getting across 26.17.0.46, our only 
gateway.  NO IT DOESNT, NO IT CANT do EGP.  Non Solution !  In the past
we have gotten others to announce our route.  Since our migration to 
this new net, THAT DOESN'T WORK.  The new route is in our friends gated
config file, correctly, appears to us.

I can exchange email, packets with anyone on milnet.  Our packet gate,
26.17.0.46 ( aka 137.24.10.1 ) is static routed to 26.6.0.103.  NO WAY 
will the static routing change without a major congressional appropriation.

That mail-bridge 26.6.0.103 is up, on line and isnt about to identify 
our route to the interior gateways. 

We have been in touch with the NIC.  "Routing is NOT our concern, call
the Milnet Trouble Desk."   We have been all thru that route and 
been informed we "dont have a problem".

Would really appreciate if someone could announce our route for us for
a while.  I can telnet all over Milnet, one of our time chimers in 
nasa.gov can even exchange time with us.  No where else, east or west
coast, off the milnet .. UNLESS we go to the host between us and the
milnet.  NO they dont have forwarding turned off .. 

Thank you in advance, /Ev/
-- 
 +  efb@suned1.nswses.Navy.MIL efb@elroy.JPL.Nasa.Gov  efb@voodoo.bitnet  +
 +  efb@suned1.UUCP | Gold Coast Sun Users | Vta-SB-SLO DECUS |  WA6CRE   +
 +  Statements, Opinions, MINE, NOT Uncle Sam_s | News Postmaster DNS guy +
-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Jun 90 08:28:28 -0400
From:      John.Curran@VEC.IMS.ABB.COM
To:        tcp-ip@nic.ddn.mil
Subject:   Re: info on PC tool & TCP/IP terminal servers
Ben Kemp (Ben@blx-s.Prime.Com) writes:
>   Since I am looking for a PC-tool to monitor TCP activity I
>   like to ask you out there to give me some advise which tool
>   is the best tool to monitor the Lan.
>   ...

You may want to look over RFC1147 (Network Management Tool Catalog) as a good
first step. It will not tell you the exact hardware supported, but will give
you a basic description and the number to call for details.

On other topic that Dave Kaas (ddk@vbeta.lanl.gov) brought up:
>  ...
>  What do other sites use for TCP/IP terminal server access to a CRAY ?
>  We have tried an Ungermann-Bass terminal server but it does not support
>  line mode properly.  Are there any TCP/IP terminal servers that support
>  line mode? Something that will work with a CRAY, SUN and a VAX/VMS with
>  Wollongong TCP/IP software.

I know of a few esoteric terminal servers that support line mode, but it's a
long story..   In general I've seen most sites use a workstation as a front-end
to their line mode systems, and define define a captive account for telnet.
The w/s will correcly negotiate a line-mode to character-based translation.
---
John Curran
Asea Brown Boveri
Information Management Services
(203) 285-6520
jcurran@vec.ims.abb.com
-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Jun 90 07:00:32 EDT
From:      David Rankin <drankin%westford.ccur.com@RELAY.CS.NET>
To:        Tcp/Ip <tcp-ip@NIC.DDN.MIL>
Subject:   Unsubscribe me

Please remove me from this list.

Thank you
-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Jun 90 09:27:14 MDT
From:      cpw%snow-white@LANL.GOV (C. Philip Wood)
To:        tcp-ip@nic.ddn.mil
Cc:        efb@suned1.nswses.Navy.MIL
Subject:   Re: Packets stuck on MILNET
/Ev/

(Note, usually we take ESnet to MILNET networks, however, we can force a
 route through our IMP connection to MILNET)
 
Attached is a view from New Mexico:

1. If I traceroute to your old network address:

traceroute to 192.31.106.1 (192.31.106.1), 30 hops max, 40 byte packets
 1  cisco-ccf-open (128.165.4.245)  7 ms  6 ms  11 ms
 2  cisco-esnet (128.165.4.246)  167 ms  25 ms  14 ms
 3  gac-lanl.es.net (134.55.2.225)  114 ms  34 ms  34 ms
 4  llnl-gac.es.net (134.55.2.193)  79 ms  550 ms  185 ms
 5  ames-rt1.es.net (134.55.4.161)  218 ms  50 ms  50 ms
 6  Palo_Alto.CA.NSS.NSF.NET (192.52.195.254)  96 ms  50 ms  50 ms
 7  MOFFETT-FLD-MB.DDN.MIL (192.52.195.1)  201 ms  235 ms  297 ms
 8  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  906 ms  828 ms  1371 ms
 9  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  2350 ms  793 ms  789 ms
10  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  1119 ms  965 ms  1268 ms
11  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  1312 ms  2356 ms  2825 ms
12  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  2267 ms  1670 ms  1432 ms
13  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  1088 ms  1008 ms  1029 ms
14  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  1207 ms  1904 ms  1223 ms
15  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  1519 ms  1534 ms  1514 ms
16  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  1613 ms  1503 ms  1543 ms
17  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  1565 ms  1309 ms  1368 ms
18  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  1814 ms  1940 ms  2235 ms
19  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  1994 ms  1539 ms  1554 ms
20  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  2316 ms  1978 ms  3640 ms
21  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  2159 ms  1949 ms  1874 ms
22  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  2100 ms  2814 ms  2482 ms
23  MARINA-DEL-REY-MB.DDN.MIL (26.6.0.103)  1791 ms  1834 ms  1742 ms

Hmmm.

2. If I traceroute to your new address:

traceroute to 137.24.30.1 (137.24.30.1), 30 hops max, 40 byte packets
 1  cisco-ccf-open (128.165.4.245)  7 ms  6 ms  14 ms
 2  cisco-esnet (128.165.4.246)  14 ms  11 ms  11 ms
 3  gac-lanl.es.net (134.55.2.225)  81 ms  51 ms  54 ms
 4  llnl-gac.es.net (134.55.2.193)  137 ms  48 ms  52 ms
 5  ames-rt1.es.net (134.55.4.161)  100 ms  53 ms  53 ms
 6  Palo_Alto.CA.NSS.NSF.NET (192.52.195.254)  78 ms  56 ms  49 ms
 7  Palo_Alto.CA.NSS.NSF.NET (192.52.195.254)  51 ms !N  51 ms !N  53 ms !N
 
As you say, your network is not known outside of a few close friends.

3. If I hard code a route to your new address via your MILNET gateway:

traceroute to 137.24.10.1 (137.24.10.1), 30 hops max, 40 byte packets
 1  VAXB.NSWSES.NAVY.MIL (137.24.10.1)  1763 ms !  857 ms !  866 ms !

Your MILNET gateway knows about your network.

4. Finally, here is a traceroute to your host using the static routing
entry on our MILNET connection.

traceroute to 137.24.30.40 (137.24.30.40), 30 hops max, 40 byte packets
 1  * * *
 2  SUNED1.NSWSES.NAVY.MIL (137.24.30.40)  343 ms !  295 ms !  329 ms !
 
and for sure you are reachable off the MILNET, if only the core EGP speakers
knew where you were.

Contact BBN at 800-492-4992 and ask them for some help.  Point out the
MARINA-DEL-REY-MB problem.  Good luck.

Phil
 


-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 90 03:34:14 GMT
From:      ficc!ihsan@uunet.uu.net  (jaleel ihsan)
To:        tcp-ip@nic.ddn.mil
Subject:   timimg-out a socket read

tcp-ip gurus,

I am trying to use tcp-ip for real-time application.  The application
consists of a client in the field that collects real-time data every
two seconds and sends it to the server which stores it in the database.
(A host of application programs use this data for different purpose.)

The specification requires that if no data is received within 15 seconds,
I declare the real-time data channel dead.

I do not know of any other means of timing-out the read except to use the
keep socket "warm" option, but the vendor says (and quotes form the few
last pages of internetworking by Comer) that the standard does not require
him to implement it and even if he implements it the standard does not
require to make the timers in the option to be user selectable.  What does
the standard has to say about this ?

Did I choose the wrong vendor, or did I made a mistake in choosing tcp-ip
for real-time application ? (8=:|)

Jaleel
-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Jun 90 17:12:44 -0700
From:      wrs!daahoud!hwajin@uunet.UU.NET
To:        uunet!ficc!ihsan@uunet.UU.NET (jaleel ihsan)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: timimg-out a socket read
> I am trying to use tcp-ip for real-time application.  The application
> consists of a client in the field that collects real-time data every
> two seconds and sends it to the server which stores it in the database.
> (A host of application programs use this data for different purpose.)
> The specification requires that if no data is received within 15 seconds,
> I declare the real-time data channel dead.

actually, if this is the only requirement, more precise way of
handling this situation would be to have your application perform
non-blocking (or asynchronous) i/o on connected data channel and keep
your own application level timer.  when your timer expires (say,
SIGALARM goes off and your signal handler is called) you can close and
shutdown the connection, or just mark it dead and move onto something
else.  in certain implementations (like bsd 4.3 unix) of tcp, users can
specify a keep_alive option on the connected socket which is used to
detect a dead connection, which works for most applications.  the time
it takes to detect a dead connection is not easily settable by the users,
and certainly not settable per connection basis (e.g. you need to modify 
the values of global variables in your unix kernel -- tcp_keepidle,
tcp_keepintvl, and tcp_maxidle in 4.3 bsd tahoe release of tcp/ip, which
will affect all of the tcp based applications running on that version
of the kernel).  this keep_alive is *not* a standard specified in the
rfc; it's just an implementation specific feature.









-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Jun 90 13:53:54 EDT
From:      lazear@gateway.mitre.org
To:        info-unix@brl.mil, tcp-ip@nic.ddn.mil
Subject:   X.25 for VaxStation 3100
Does anyone know of an X.25  package for a VaxStation 3100 running Ultrix, 
so it can hook to an AF Concentrator?  They will be  using TCP/IP over
this serial link. 

	Walt Lazear
	lazear@gateway.mitre.org
-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 90 11:30:36 GMT
From:      mcsun!hp4nl!dutrun!dutetvg.tudelft.nl!pieter@uunet.uu.net  (Pieter Venemans)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP and T2000 modem problems solved (LONG)
Thanks to all of you who responded to my question about a bad
performance with SLIP and Telebit T2000 modems. The problem is solved:
with ftp the transfer rate is now somewhere between 1.2 and 1.4
kbyte/sec, which seems very reasonable for 19.2 kbaud modems.

Since there were a couple of reactions asking for my general experience
with (C)SLIP, I compiled a summary on that. Here it is.

My configuration:
* SUN-3/60 (12 Mbyte) with SunOS 4.0.3
* SUN-2/50 (2 Mbyte) with SunOS 3.5 and bsd 4.3-tahoe TCP code from
  ucbarpa.berkeley.edu
* 2 Telebit T2000 modems, 19.2 kbaud interface, very clean (local)
  telephone connection
* cslipbeta (jan 1990) from rtsg.ee.lbl.gov, version 1.2 for SunOS 4.0,
  version 1.11 for SunOS 3.5. This version is available from many
  anon.ftp sites.

Installation of the SLIP drivers is quite easy. The only problem with
the SunOS 4.0 version was that the "Type Of Service queueing" (giving
priority to rlogin/telnet over ftp) was not working properly. Packets
were transmitted in the wrong order, and some of them got lost. I had
no time to investigate the exact reasons for that, so I removed the
queue magic in slip_output():

	if (sdp->q) {   /* inside splstr() in case sdp->q = 0 */
#ifdef doesnotwork
		if (hiprio) {   /* macchiavelli mode */
			<...stuff deleted...>
			sdp->lastpriopkt = mp;
		} else
#endif
			putq(sdp->q, mp);

The number of stream buffers in param.c should be increased,
otherwise you get a lot of 'slip_output can't allocb' messages on
the console (and a very bad performance).

On the SunOS 3.5 version, the definition of the macro MCLFREE was
incomplete. I changed it to:

#define MCLFREE(p) { \
        extern char *mclrefcnt; \
	struct mbuf mxxx; \
	mxxx.m_len = MCLBYTES; \
	mxxx.m_off = (int)p - (int)xm; \
	mxxx.m_cltype = 1; \
	mclput(&mxxx); \
	}

I don't know whether this is correct, but it seems to work. Installation
of the bsd 4.3-tahoe code only required changing some pathnames for
#include files.

The reason for the bad performance in my question was a badly chosen
window size for TCP. In one of the files accompying his Compresses
Header SLIP, Van Jacobson suggested lowering the default tcp_sendspace
and tcp_recvspace from 4*1024 to 4*256. While this gives better
performance with plain 2400 baud modems, it turned out to be a bad idea
for T2000 modems. The round trip time for these modems is so large,
that TCP couldn't keep the modem sending continuously. The default
size 4*1024 gives far more better results.

Increasing the window size to 8192 even improves the throughput
sometimes, but then there turn up a lot of time-outs and
retransmissions, probably because of the fluctuating delay time of such
a large buffer. 4096 seems to be a good compromise.

Making the retransmit timers more conservative, as suggested
by Van Jacobson, is a good idea. Since we have no source code of
SunOS 4.0.3, we had to patch the object code with adb... Look for the
asrl #2,d0 and asrl #1,d0 instructions in tcp_input(): it closely
follows the bsd 4.3-tahoe code.

Enabling PEP compression improves performance only marginally, but
does not harm either.

Interactive response is tolerable. In fact it is not much worse than
using a T2000 with tip, or a real terminal. Personally, I prefer to use
a rather small MTU (104 or 168): screen updates in emacs just look
better (not: 'bang-bang-bang', but 'brrrrrrr..."). Overall througput
does not suffer from this.

Overall conclusion: (C)SLIP with T2000 modems works great. Even with
2400 baud modems, it is a pleasure to work with.

Pieter
--
Pieter H.A. Venemans, Delft University of Technology, the Netherlands
DOMAIN: venemans@et.tudelft.nl         BITNET/EARN: venemans@hdetud53
UUCP:   ...!mcsun!hp4nl!dutrun!dutetvg!pieter     VOICE:  +3115786272
-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 90 12:29:50 GMT
From:      clyde.concordia.ca!news-server.csri.toronto.edu!utgpu!utzoo!censor!avcocan!bounder@uunet.uu.net  (Robert Story)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP AIX ==> AS/400

I would like to hear from anyone using TCP/IP between AIX 1.2 on a PS/2
and the AS/400.  Between a PS/2 Model 80 and an AS/400 Model 50 I am getting
about 18-21K cps under average to high load (on the 400).  Does this
sound correct?  Any ideas for fine tuning the PS/2 end?
-- 
[ Robert Story  ..uunet!{jtsv16!geac!censor, mnetor!lsuc}!avcocan!bounder  ]
[ SnailMail :   AFS 201 Queens Avenue London Ontario Canada N6G 4M5        ]
[ Voice     :   +1 519 672-4220 xtn 642 or Direct Line +1 519 660-2642     ]
-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 90 18:51:32 GMT
From:      mips!ultra!ted@apple.com  (Ted Schroeder)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: timimg-out a socket read
In <VZ74GZC@ccs.ferranti.com> ihsan@ficc.ferranti.com (jaleel ihsan) writes:


>tcp-ip gurus,

>I am trying to use tcp-ip for real-time application.  The application
>consists of a client in the field that collects real-time data every
>two seconds and sends it to the server which stores it in the database.
>(A host of application programs use this data for different purpose.)

>The specification requires that if no data is received within 15 seconds,
>I declare the real-time data channel dead.

You can do this by doing your reads with select().  The select call allows
you to check on an event on any number of sockets simultaneously and allows
you to specify a timeout.

So you'd have something that looks like this:

s = socket();
connect(s,..)
timeval.tv_sec = 15;  /* set timeout to 15 seconds */
timeval.tv_usec = 0;
rmask = 1<<s;
if (select(32, &rmask, (struct fd_set *)0, (struct fd_set *)0, timeval)) == 0 {
    close(s);
}

      Ted Schroeder                   ted@Ultra.com
      Ultra Network Technologies      ...!ames!ultra!ted
      101 Daggett Drive           
      San Jose, CA 95134          
      408-922-0100

Disclaimer:  I don't even believe what I say, why should my company?
-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      25 Jun 90 19:06:23 GMT
From:      cica!phil.indiana.edu!jwd@tut.cis.ohio-state.edu  (Jon Dunn)
To:        tcp-ip@nic.ddn.mil
Subject:   LANtastic and TCP/IP followup

I recently posted a question regarding running LANtastic and NCSA Telnet
on the same network.  

It looks like recent versions of LANtastic can coexist with TCP/IP
traffic on the same Ethernet cable - they shouldn't interfere
with each other.  There may have been some problems with older versions,
but 2.57 and later seem to work okay.

LANtastic and NCSA Telnet cannot run on the same PC using the same Ethernet
board, however, since LANtastic has no packet driver interface.  I've
talked with Artisoft and they don't seem to know what a packet driver is
exactly, so I doubt packet driver support will be included in
LANtastic anytime soon!

Thanks to Stephen Killingsworth (sak0415@usl.edu) for his help!

Jon Dunn
ACCESS MicroCenter
University Computing Services
Indiana University, Bloomington
-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      Tue 26 Jun 90 00:00:34-EDT
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        ficc!ihsan@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil, lynch@A.ISI.EDU
Subject:   Re: timimg-out a socket read
Jaleel,  you give a good escription of your situation.  TCP/IP is not 
a very good choice for "real-time".  For two reasons:
1)  As noted by Comer, the application (meaning vendor) is not obliged
to expose the timer values to the application, but also, the vendor is certainly
not prevented from doing so.  Most implementations are, in fact, not too
good about letting the individual application instance set values such
as timer values.  This is simply a matter of choice.  The protocol supports
the concept, but if an implementaiton had to keep track of this on a
"per instance" basis, it would add to the implementation storage space
requirements.  
2)  TCP/IP was designed to send data "for a long distance in the face of
hostile conditions".  If there is a very short "distance" from sender
to receiver in your situation, then TCP/IP might work well for you.  The 
in not (necessarily) that TCP/IP is slow in sending data, but that it is
designed to be very tolerant in waiting for data to arrive through an
amazing maze of intermediate systems.  Thus the design capability of
setting long timeouts before retransmission.  If you know that things cannot
take long, then you are free to select as short a timeout as you wish.
(Of course, your vendor must expose those timer values to you so you can
alter them to suit your taste.)

Anoterh way to saying it is : deadline scheduling is tough to satisfy.
TCP/IP was not designed for that condition, but it may suffice in 
constrained situations.

Dan
-------
-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jun 90 09:40:06 EDT
From:      stev@vax.ftp.com
To:        ico!ism780c!mchale!johnan@handies.ucar.edu  (John Antypas)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
>>How about officially assigning NET 10 to Interop - then it could be brought out
>>of retirement each year for all of the newcomers to look at - sort of like
>>the IMP last year. Maybe during the "off season" Interop could keep 2 PC's
>>running in a backroom on some Ethernet, pinging each other - on NET 10.
>>
>A nice idea, but with all of the talk about address spacing becoming
>hard to find, the idea of re-using 10 as a Class A, or splitting it into
>256 class B's needs to be considered.  That's a lot of new customers
>for Internet.  Consider that net is over 65535 class C spaces!  Do we
>want to give Interop 16x10^6 addresses!


the reason class A addresses arent given out that often is that few people
need such a large space. it appears merit is cutting back on net 35's use,
and i hear the canadians are cutting back on 46(?). 

i would need to hear a rational plan for cutting 10 into 255 class B
addresses before i would be willing to go for it. and, to be honest, the
Interop Shownet is getting close to needing *alot* of subnets. a quick count
tells me there will be at least 110 subnets in the 90 shownetwork. (yes, i
*do* happen to know that will be a close answer. it is based on the
assumption for 3 subnets per router tower, 30 router towers, with 20 random
subents for things like terminal room, control networks, redundant backbones
and such. i am under the impression that 91 will be much bigger. soon, they
will need this kind of network expansion. while it is true that the
subnetworks are not crowded, it is still true that people want infinite
address space for stuff in their booths, and having 50 machines in some of
the larger booths will not be unheard of.

actually, the class B address they use is not "theirs" as i understand it.
they got a class B address allocated to trade shows in general. i believe
the idea was to allow others to use it also. sort of a transiently connected
network. i am sure dan will correct me if i am incorrect.

possibly we should use net 89 instead of net 10 though . . . . . . 


stev knowles
troublemaker
ftp software
stev@ftp.com

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jun 90 10:03:49 EDT
From:      hung@eniac.seas.upenn.edu (  Han  Hung)
To:        tcp-ip@nic.ddn.mil
Cc:        hung@eniac.seas.upenn.edu
Subject:   Needed: SLIP Specifications
Hi,

Can anyone tell me where I can get detailed specifications of
SLIP.

     Thanks,

     Kman

     Kevin Agatone
     c/o Advanced Computer Applications
     107 Penns Trail
     Newtown, PA  18940
     (215) 860-0700
-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jun 90 17:04:05 PDT
From:      <tep@tots.Logicon.COM>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Internet Connectivity Maps wanted
IAC DO WISH-LIST

I would like to find some "maps" that show the connectivity of (at
least) the class-A and/or major regional Internets.

Networks as nodes and gateways as arcs would be sufficient, although
geographical information would be useful as well.

Ideally, these would be similar to the (Postscript) maps available via
usenet that show the major backbone sites and news flows.

Also, is there a list of the major regional Internets (e.g. CERFnet,
NEARnet) that defines their service areas?

Thanks,
Tom Perrine (tep)                       |Internet: tep@tots.Logicon.COM
Logicon                                 |UUCP: nosc!hamachi!tots!tep
Tactical and Training Systems Division  |-or-  sun!suntan!tots!tep
San Diego CA                            |GENIE: T.PERRINE
"Harried: with preschoolers"            |+1 619 455 1330
Home of the _Tower Operator Training System_ as seen in the SunTech Journal.
-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jun 90 14:40:31 EDT
From:      hung@eniac.seas.upenn.edu (  Han  Hung)
To:        tcp-ip@nic.ddn.mil
Cc:        hung@eniac.seas.upenn.edu
Subject:   TCP FORTH Implementation
Hi,

I'm writing a version tcp/ip in the FORTH language and was
wondering where I can get a source listing (in any language) or
pseudo code listing of tcp.  I already have most of the specs
I need from the DDN Protocol Handbooks.

Any information would be appreciated.

Thanks

Kman


     Kevin Agatone
     c/o Advanced Computer Applications
     107 Penns Trail
     Newtown, PA  18940
     (215) 860-0700
 
-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Jun 90 18:21:17 EDT
From:      James Nelson  <sandwich@wam.umd.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   hosts in Germany
	Hi I'm not subscribed to this list so please any responses
to my message should be sent to: sandwich@wam.umd.edu

	Here goes.  I will be participating in an exchange program next
academic year in the Federal Republic of Germany (West Germany) and
I'd like to know if there is a machine where I'll be that will allow
me either an internet connection to my account or at least a mailing
pathway.  The univeristy is called the Gesamthochschule Kassel.  It's
located in Kassel West Germany.  If anyone can help me, please repsond
via e-mail to me directly.  I appreciate any help.  Thanks,

				James
-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 90 16:09:55 GMT
From:      swrinde!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!bmc.uu.se!kuling!bernt@ucsd.edu  (Bernt 'Bugge' Budde)
To:        tcp-ip@nic.ddn.mil
Subject:   Encryption products?

What hardware/software products exists for encryption of tcp/ip
communication? Ideal would be a (cheap) card that encrypts/decrypts
all telnet information while sitting in a PC/Mac configured as a gateway
ignoring everything else!

/Bug				| Sorry, no interesting signature!
 bernt@kuling.uu.se
-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 90 18:11:47 GMT
From:      idunno!princeton.edu!tengi@louie.udel.edu  (Christopher Tengi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: more to argue about . . . . . .
In article <9006172109.AA20810@vax.ftp.com>, stev@VAX.FTP.COM writes:
|> 
|> he ya go, campers. anyone wish to rise up and define a good reason to keep
|> non-contigious subnet bits, assuming we require the ability to have more
|> than one address on an interface . . . . . .
|> 

Stev,
    For those sites that were forced to "grow" into a non-contiguous
mask (through bad planning, or whatever), renumbering may not be a very
attractive option.  If you eliminate support for non-contiguous bits in
the mask, any sites in this boat will be forced to do the subnet-shuffle
in order to use that fancy new router they just bought.  You (and
others) may argue that these sites should just "bite the bullet" and
renumber, but, having gone through just that last summer, for around
1300 hosts, I would counter that if it ain't otherwise broke, don't try
to fix it.  I was lucky in the fact that most of the system
administrators on campus were agreeable to the idea and actually
available on the day the net shook.  It did, however, take a few days to
get everything back together, and there were a few random machines that
needed to be changed over the following 2 weeks or so.  Like I said, I
was pretty lucky, but I wouldn't want to do it again real soon, nor
would I recommend the process for more than a small number of hosts.


==========----------==========---------+---------==========----------==========

	UUCP:	  ...princeton!tengi		VOICEnet: 609-258-6799
	INTERNET: tengi@princeton.edu		FAX:      609-258-3943
	BITNET:	  TENGI@PUCC
-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 90 19:02:32 GMT
From:      stan!dancer!imp@uunet.uu.net  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
In article <9006261340.AA21128@vax.ftp.com> stev@VAX.FTP.COM writes:
>possibly we should use net 89 instead of net 10 though . . . . . . 

	Why is this?  I've noticed several vendors[*] use net 89 in
their documentation as the "example" net or in examples on how to
setup routers, name servers, etc.  I've also seen a few use net 90,
most mostly net 89.  Is net 89 allocated for this purpose?  Or have I
missed something in the assigned numbers RFC?  Or is all this
documentation come from one source?

	Just out of curiousity, why is MILNET net 10 and ARPA net 26?
Why were those numbers chosen?  The last assigned numbers RFC that I
saw seemed to have lots of holes in it between 1 and 26.

-- 
Warner Losh			imp@Solbourne.COM
[*] although the only people I can think of off the top of my head is TWG.
-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      26 Jun 90 21:25:33 GMT
From:      vax8530!jeh@cu-arpa.cs.cornell.edu
To:        tcp-ip@nic.ddn.mil
Subject:   X.25 terminal/port servers out there?
We have an HP 9000/825 that we are about to connect to a
commercial database vendor via an X.25 link over a leased line.
HP doesn't sell a PAD card for this machine that we can use for
straight X.25 connections. For various reasons, including the
lack of expandability and the sheer ugliness of it, we don't like
the traditional solution of 16 async ports with 16 cables
connecting to an X.25 PAD.  Another one of the solutions that
I've thought of is to buy an inexpensive Unix machine that has an
inexpensive PAD available for it, but this adds up. 

What I'm really looking for is the X.25 equivalent of an Annex 
box that has an Ethernet port on one side and the appropriate 
synchronous serial port on the other, and can be used for dial in 
and dial out over an X.25 network.  Does such a thing exist?

I'll summarize if need be.

  --jh

-- 
John Hood, Mann Library, Cornell University  
jhood@albert.mannlib.cornell.edu
-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 90 01:01:36 GMT
From:      aek@apple.com  (Al Kossow)
To:        tcp-ip@nic.ddn.mil
Subject:   The history of net 89
What is the history of net 89? I have noticed that early Excelan cards
used net 89 with the last two digits of the ethernet address as the IP
number. These were used by Callan and early SGI machines, and by Apple
as the internal network number up until a year ago.

-- 

Al Kossow @ Apple Computer, Inc., Cupertino, CA
Internet: aek@apple.com
Phone: (408) 974-5136
-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jun 90 09:00:01 -0400
From:      barns@gateway.mitre.org
To:        stan!dancer!imp@uunet.uu.net (Warner Losh)
Cc:        tcp-ip@nic.ddn.mil, barns@gateway.mitre.org
Subject:   Re: Mourning of the passing of the ARPANET
I'll let someone else talk about net 89.  However, here is some history
on network numbers.

When IP was first conjured up, there was not a notion of class A/B/C
addresses.  At that time it was not generally thought that there would
be a huge number of networks, but rather a smaller number of possibly
large networks.  The 32 bit IP address was 8 bits Network, 24 bits Host.
"They" thought it would be a good idea to preallocate the network
numbers to all the significant networks (those that some Internet
participant might presumably join).  I seem to remember that there were
on the order of 20-30 networks identified and preassigned.  These
included TELENET, TYMNET, DATAPAC, etc.  There was a list and it can
probably be found in some ancient RFC.

A little while later "they" decided that preallocation was not such a
good idea and instead they would give out network numbers only to networks
that had EGP routing glue to The Internet.  Some of the already assigned
network numbers were deassigned because there was no connectivity and no
specific plan to achieve it.  It was also around this time that
the threat (or promise, depending on your point of view) of campus
nets, building nets, and random Ethernets became clearer, so classes
A, B, and C were invented, and the high order bit coding trick was used
to provide compatibility with the previously assigned network numbers
that were actually in use.  So there were a lot of holes in class A and
most of the new demand was in class C, for the random Ethernets.

Obviously the people who already had working networks didn't want to
change their addresses.  This is the main reason why some nets that don't
seem to be big enough to warrant class A addresses have them anyway.
Less obvious but also an issue - some sites had gateways that could not
conveniently be gotten to cope with the revised addressing plan.  I
think that Stanford was one such, but I don't remember the exact problem.
Bear in mind that gateways weren't off-the-shelf in those days.  (Neither
were hosts, sometimes.  Especially the networking interface hardware and
software.)

Subnets are more recent than all of these things, and multicast (class D)
addresses are yet more recent.  Class B became popular with the advent
of subnetting.

We probably don't have much call for class A network numbers nowadays,
but I can think of at least one possible source of demand.  When a
logical network uses end-to-end encryption devices, there are some
extra demands on the address space, such as wanting to be able to
address some sub-processors in the encryption box, and wanting to carry
the encryption domain identification in a subfield of the address.  To
put all of this (plus the host id) into 16 bits with fixed size subfields
would cramp the fields more than is nice.  Even 24 bits isn't vast, but
it's better.  DOD has net 21 for this purpose already; I don't know
whether others are or will be needed, but it's conceivable that they might.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org
-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jun 90 09:39:41 MDT
From:      "Doug McCallum" <dougm@ico.isc.com>
To:        clyde.concordia.ca!news-server.csri.toronto.edu!utgpu!utzoo!censor!avcocan!bounder@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP AIX ==> AS/400
In reply to your message of 25 Jun 90 12:29:50 GMT
-------

> I would like to hear from anyone using TCP/IP between AIX 1.2 on a PS/2
> and the AS/400.  Between a PS/2 Model 80 and an AS/400 Model 50 I am getting
> about 18-21K cps under average to high load (on the 400).  Does this
> sound correct?  Any ideas for fine tuning the PS/2 end?

I haven't tried with an AS/400, but I've used the PS/2 and found that
performance has a strange asymmetry.  The PS/2 seems to send fast but
receive very slow, like 20-40Kbytes/s with the TCP on either 1.1 or 1.2 AIX.
I never looked at how to resolve it since the project I had to use AIX on
only lasted a few weeks.  My suspicion is that it is a bug in the AIX TCP/IP
ack code.
-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 90 04:06:10 GMT
From:      usc!zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!sugar!ficc!ihsan@ucsd.edu  (jaleel ihsan)
To:        tcp-ip@nic.ddn.mil
Subject:   Listening to a specific IP address (was: How long before I can reopen a closed socket?
> 
> Jaleel,  You can certainly build a server to do exactly as you
> described.  It would only listen for specific ports from specific
> addresses.  The algorithm for selecting port numbers for TCP and
> UDP that are not the "well known port numbers" is entirely up
> to the hosts in question.  You are looking for a way to restrict
> service and this is one (weak) way to do so.  "Weak" in the security
> sense.  
> 
> Dan

Thanks for the information, Dan.

You see, we are working with Intel's RMX real-time executive, which I
do not think supports fork'ing.  But even if it did, our application
design does not support it.  So I was thinking of having a dedicated 
and a specific server for each one of the limited number of clients.

But how to channel a client to the proper server ?

A server could bind the listening socket to a well known local port (all
servers use the same well known local port so that multiple servers are
transparent to the clients), local address, a wild-card remote port, and 
a specific remote IP address.

Theoretically, it should (!!!) work. Can any one shoot some holes in it ?
Would any authority at the IAB care to comment ? Practically, ... well ...
minor details,  minor details !!!

Jaleel
-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 90 08:02:41 GMT
From:      nic.cerf.net!pushp@ucsd.edu  (Pushpendra Mohta)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet Connectivity Maps wanted
In article <9006270004.AA23106@heinlein.tots.uucp> tep@tots.Logicon.COM writes:
>IAC DO WISH-LIST
>
>I would like to find some "maps" that show the connectivity of (at
>least) the class-A and/or major regional Internets.
>Networks as nodes and gateways as arcs would be sufficient, although
>geographical information would be useful as well.
>Ideally, these would be similar to the (Postscript) maps available via
>usenet that show the major backbone sites and news flows.
>Also, is there a list of the major regional Internets (e.g. CERFnet,
>NEARnet) that defines their service areas?
>
>Thanks,
>Tom Perrine (tep)                       |Internet: tep@tots.Logicon.COM


A postscript map of the logical connectivity of 
CERFNet is available by anonymous ftp from
nic.cerf.net in the file ~ftp/cerfnet/cerfnet_info/topology.ps

Look around in the same directory  for other information
If you dont have access to ftp drop a note to help@cerf.net

Maps of many regionals are also available
by anonymous ftp from nic.merit.edu in the ~ftp/maps
directory. 


Pushpendra Mohta
CERFNet
(California Education and Research Federation Network)
P.O.Box 85608, San Diego , CA 92186-9784
(619) 534-5056
-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 90 09:42:33 GMT
From:      IBTJLL@VM.IBT.DK ("Jesper L. Lauritsen")
To:        comp.protocols.tcp-ip
Subject:   ftp client with script facility wanted

I'm looking for a ftp client with some sort of script facility. If no
such beast exists I'll need the source for any telnet client. It is going
to run on HP-UX systems, but if it is written for some unix and uses BSD
sockets I can probably make it run.
While I'm at it. I'm also looking for a telnet client with VT100 emulation -
a X-window version would be nice. Also, what is the home of tn3270? Does a
X-window version exist?
Please reply by e-mail. If anybody want a copy of the replys I may get, they
can request it by e-mail as well. Thanks in advance.

--Jesper

---------------------------------------------------
Jesper L. Lauritsen, systems programmer
Domain addr: ibtjll@vm.ibt.dk;  BITNET/EARN: IBTJLL AT DKIBT
K:benhavns Universitet        /    University of Copenhagen
Center for Anvendt Datalogi   /    Center for Applied Datalogy
Studiestr{de 6 o.g.           /    Studiestraede 6 o.g.
1455 K:benhavn K              /    DK-1455 Copenhagen K, Denmark
33 12 01 15                   /    +45 33 120115

-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jun 90 13:46:55 EDT
From:      jbvb@vax.ftp.com  (James B. Van Bokkelen)
To:        barns@gateway.mitre.org
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
If we could hope to expunge all the Class A nets, we might be able to
redefine 127 class A nets as 32,000 new Class B nets in a future
HRRFC.  Given that we've actually used 2,500 out of the 16,000
possible, this might be worth adding to the enormous thrashing among
developers as the millenium approaches.  It would also legislate
away "net 89", and "127.0.0.1".

Presumably plenty of the 2 million possible class C nets remain
to be allocated...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jun 90 09:51:37 DST
From:      "Jesper L. Lauritsen" <IBTJLL%vm.ibt.dk@CORNELLC.cit.cornell.edu>
To:        TCP-IP@NIC.DDN.MIL
Subject:   ftp client with script facility wanted
I'm looking for a ftp client with some sort of script facility. If no
such beast exists I'll need the source for any telnet client. It is going
to run on HP-UX systems, but if it is written for some unix and uses BSD
sockets I can probably make it run.
While I'm at it. I'm also looking for a telnet client with VT100 emulation -
a X-window version would be nice. Also, what is the home of tn3270? Does a
X-window version exist?
Please reply by e-mail. If anybody want a copy of the replys I may get, they
can request it by e-mail as well. Thanks in advance.

--Jesper

---------------------------------------------------
Jesper L. Lauritsen, systems programmer
Domain addr: ibtjll@vm.ibt.dk;  BITNET/EARN: IBTJLL AT DKIBT
K:benhavns Universitet        /    University of Copenhagen
Center for Anvendt Datalogi   /    Center for Applied Datalogy
Studiestr{de 6 o.g.           /    Studiestraede 6 o.g.
1455 K:benhavn K              /    DK-1455 Copenhagen K, Denmark
33 12 01 15                   /    +45 33 120115
-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 90 09:58:59 GMT
From:      mcsun!ukc!stc!datlog!gjack@uunet.uu.net  ( Graham Jack)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: timimg-out a socket read
ihsan@ficc.ferranti.com (jaleel ihsan) writes:

>I do not know of any other means of timing-out the read except to use the
>keep socket "warm" option, ...

If the supplier's offering doesn't give the facilities you want, you
can provide them in your own 'session-layer', it ain't pretty but its
pragmatic.
The rationale used against an effective 'keepalive' at the transport
layyyer seems to take a rather narrow view of the sort of applications
and environments in which IPS is used these days.

> ... but the vendor says (and quotes form the few
>last pages of internetworking by Comer) that the standard does not require
>him to implement it and even if he implements it the standard does not
>require to make the timers in the option to be user selectable.  What does
>the standard has to say about this ?

All credit to Comer for introducing me and many others to the Internet
protocols but your supplier should be referring to the Host Requirements
RFCs and in particular to Section 4.2.3.6 of RFC-1122.
This says keepalives MAY be implemented (ie are OPTIONAL), if provided
the interval MUST be configurable.
Practically, if the products are based on the 4.3BSD networking code as
many (most?) UNIX implementations are, then keepalive should be
provided and should work, it is unlikely, however, to be configurable.
That's life ...

>Did I choose the wrong vendor, or did I made a mistake in choosing tcp-ip
>for real-time application ? (8=:|)

I'm not sure I can comment on this.
-- 
Regards,
	    Graham Jack, Data Logic.
	    <gjack@datlog.co.uk>
-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 90 11:54:25 GMT
From:      J.Crowcroft@CS.UCL.AC.UK
To:        comp.protocols.tcp-ip
Subject:   Re: Mourning of the passing of the ARPANET



 >>>How about officially assigning NET 10 to Interop - then it could be brought out
 >the idea was to allow others to use it also. sort of a transiently connected
 >network. i am sure dan will correct me if i am incorrect.
 
 >possibly we should use net 89 instead of net 10 though . . . . . .  >

what about recycling net 4 (SATNET) since the bird no longer flies..
maybe RIPE could consider using it for europe...since most net 4 sites
were there...


 jon

-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Jun 90 12:54:25 +0100
From:      J.Crowcroft@cs.ucl.ac.uk
To:        stev@vax.ftp.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET


 >>>How about officially assigning NET 10 to Interop - then it could be brought out
 >the idea was to allow others to use it also. sort of a transiently connected
 >network. i am sure dan will correct me if i am incorrect.

 >possibly we should use net 89 instead of net 10 though . . . . . .  >

what about recycling net 4 (SATNET) since the bird no longer flies..
maybe RIPE could consider using it for europe...since most net 4 sites
were there...


 jon

-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 90 17:10:00 GMT
From:      excelan!keith@ames.arc.nasa.gov  (Keith Brown)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: The history of net 89
In article <42384@apple.Apple.COM> aek@Apple.COM (Al Kossow) writes:
>What is the history of net 89? I have noticed that early Excelan cards
>used net 89 with the last two digits of the ethernet address as the IP
>number. These were used by Callan and early SGI machines, and by Apple
>as the internal network number up until a year ago.
>

I was wondering if someone was going to "rumble" us!! It's true. It
could well be our "fault". We've been shipping Ethernet TCP/IP products
for all kinds of platforms since 1983(ish) with a "default" IP address
of 89 plus the bottom 3 bytes of the Ethernet address. I believe early
versions of Berkeley (and possibly current versions) can also derive
their IP address in this manner.

For those familiar with our stuff, our default TCP startup scripts all
have "netload" command lines containing the flag "-h 89.0.0.0". The TCP
code this downloads to our various cards will then use the network
number specified (89 in the default case) and replace the zero's in the
host portion with bytes from the lower end of the Ethernet address.

Incidentally, Callan were an early OEM of ours so that's us too! Now I
think about it, SGI were also. Oops!
----------------------------------------------------------------------------
Keith Brown                                      Phone: (408) 473 8308
Novell San Jose Development Centre               Fax:   (408) 433 0775
San Jose, California 95131                       Net:   keith@novell.COM
----------------------------------------------------------------------------
-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 90 19:56:29 GMT
From:      att!watmath!watserv1!broehl@ucbvax.Berkeley.EDU  (Bernie Roehl)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: X.25 terminal/port servers out there?
In article <4355.26879a8d@vax5.cit.cornell.edu> jeh@vax5.cit.cornell.edu writes:
>What I'm really looking for is the X.25 equivalent of an Annex 
>box that has an Ethernet port on one side and the appropriate 
>synchronous serial port on the other

Hmm.  Don't know if this will work, but there are HDLC cards for PCs...
could you do it with a PC, an ethernet card, an HDLC card and NOS?
You'd have to hack the code a bit, but the low-level stuff and the LAPB
stuff is already there.  (Don't know whether it handles X.25, or if it's
hardcoded for AX.25 only).  You could then write an application (using
Phil's socket routines) that provides a Telnet-to-outbound X.25 capability.
It would listen on the standard Telnet port, and when it gets a call it
opens an X.25 connection.

Dial-in would be similar; incoming sessions would act like telnet clients.

(Hmm... this might actually be useful around here, too).

If Phil is listening, he could probably tell you (us) whether it'll work or
not.  I'm not at all bothered by writing the upper layers myself, but digging
into the guts of LAPB might be a lot of work.

-- 
	Bernie Roehl, University of Waterloo Electrical Engineering Dept
	Mail: broehl@watserv1.waterloo.edu OR broehl@watserv1.UWaterloo.ca
	BangPath: {allegra,decvax,utzoo,clyde}!watmath!watserv1!broehl
	Voice:  (519) 747-5056 [home]  (519) 885-1211 x 2607 [work]
-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 90 21:09:23 GMT
From:      oliveb!orc!bu.edu!bu-it!kwe@apple.com  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET
In article <9006271746.AA07726@vax.ftp.com>, 
jbvb@VAX.FTP.COM (James B. Van Bokkelen) writes:
> If we could hope to expunge all the Class A nets, we might be able to
> redefine 127 class A nets as 32,000 new Class B nets in a future
> HRRFC.  

	32,000+ networks is a lot for a poor national backbone
router to keep track of.  I suggest that that issue be addressed at the
same time as you redefine all those Class As.

	--Kent
-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      27 Jun 90 23:39:34 GMT
From:      excelan!donp@ames.arc.nasa.gov  (don provan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: timimg-out a socket read
In article <VZ74GZC@ccs.ferranti.com> ihsan@ficc.ferranti.com (jaleel ihsan) writes:
>
>The specification requires that if no data is received within 15 seconds,
>I declare the real-time data channel dead.
>
>I do not know of any other means of timing-out the read except to use the
>keep socket "warm" option...

Using keep-alives to keep the socket "warm" only insures that the
remote device is still handling TCP traffic.  It does not insure that
the remote device is actually sending data.  If it's possible for the
device to continue to maintain the TCP connection while not sending
any data, keep-alives and the associated timers will do you no good at
all.  This is yet another reason to avoid depending on TCP to provide
this timeout and, instead, use your own timer to regain control and
handle the error condition outside of TCP.

Generally i find it's a bad idea to try to use TCP as a timing
mechanism.  TCP, being the good general purpose transport protocol it
is, really can't anticipate how long an application is willing to wait
under any given condition.  It's better for the application to handle
such things itself, particularly in a case like this where the desired
timeout condition is so specific.
						don provan
						donp@novell.com
-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 1990 12:31:55 EDT
From:      COINS@A.ISI.EDU
To:        tcp-ip@NIC.DDN.MIL
Cc:        coins@A.ISI.EDU
Subject:   tn3270
     I am looking for an implementation of a tn3270 server for non-ibm
hosts, preferably UNIX-based.  Does anyone know where I
might find such a beast or how I might acquire it?  Barring that, does
anyone know where I might find specifications for a TN3270 server?
Thank you
Lynn
-------
-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jun 90 16:52:31 -0500
From:      dab@berserkly.cray.com (David Borman)
To:        tcp-ip@nic.ddn.mil
Subject:   telnet sources

A new version of the BSD telnet/telnetd is now available.  This
is basicly what will be on the 4.4BSD test tape.  The compressed tar
file can be gotten via anonymous ftp from "ucbarpa.berkeley.edu",
in "pub/telnet.90.06.28.tar.Z".

If you have been using the sources from March 1 that were available,
you are encouraged to get this new version, as it has many bug
fixes.

No diffs between the March 1 sources and these sources are provided,
because the source tree for telnet was re-organized ("telnet/Source"
is gone, all it's contents were moved up to "telnet".)

Questions/comments go to
		Dave Borman
		Cray Research, Inc.
		1440 Northland Drive
		Mendota Heights, MN 55120
		dab@cray.com.

Both telnet and telnetd have been compiled on:
			telnet	telnetd
	BSD 4.4		  X	  X
	UNICOS 5.1	  X	  X
	UNICOS 6.0	  X	  X
	SunOs 3.5	  X	  X (no linemode in server)
	SunOs 4.0.3c	  X	  X (no linemode in server)
	SunOs 4.1	  X	  X (no linemode in server)
	DYNIX V3.0.12	  X	  X (no linemode in server)
	Ultrix 3.1	  X	  X (no linemode in server)

Some of the features in this release (full list in the README file):

	Add support for the ENVIRON and XDISPLOC options.
	In order for the server to work, login has to have
	the "-p" option to preserve environment variables.

	Add the SOFT_TAB and LIT_ECHO modes in the LINEMODE support.

	Add the "-l user" option to command line and open command
	(This is passed through the ENVIRON option).

	Add the "-e" command line option, for setting the escape
	character.

	Add the "-D", diagnostic, option to the server.  This allows
	the server to print out debug information, which is very
	useful when trying to debug a telnet that doesn't have any
	debugging ability.

	Add support for both FORW1 and FORW2 characters.  The
	telnet escpape character is set to whichever of the
	two is not being used.  If both are in use, the escape
	character is not set, so when in linemode the user will
	have to follow the escape character with a <CR> or <EOF)
	to get it passed through.

Some of the bug fixes:

	Turn off the literal next character when not in LINEMODE.

	Don't recognize ^Y locally, just pass it through.

	Fix telnetd's processing of options so that we always do
	the right processing of the LINEMODE option, regardless
	of who initiates the request to turn it on.  Also, make
	sure that if the other side went "WILL ECHO" in response
	to our "DO ECHO", that we send a "DONT ECHO" to get the
	option turned back off!

	Fix the TERMIOS setting of the terminal speed to handle both
	BSD's seperate fields, and the SYSV method of CBAUD bits.

	Change how we deal with the other side refusing to enable
	an option.  The sequence used to be: send DO option; receive
	WONT option; send DONT option.  Now, the sequence is: send
	DO option; receive WONT option.  Both should be valid
	according to the spec, but there has been at least one
	client implementation of telnet identified that can get
	really confused by this.
-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 90 08:59:51 GMT
From:      usc!cs.utexas.edu!ntvaxb!billy@ucsd.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Major bug in TALK on WIN/TCP for VMS
Hi,

In WIN/TCP for VMS 5.1, TALK does not handle userids with numeric characters
in them correctly.  For example, TALK turns the userid AC02 into acPR and
the userid OB23 into obRV.  The bad part of this problem is that TALK will
not let this userid connect to others via TALK..... :(

If anybody has any suggestions, please let me know.  I have sent in a 
modification request.  I have 1500 userids of which 1200 or so have numbers 
in them....

================================================================================
Billy Barron                  Bitnet : BILLY@UNTVAX
VAX system manager            THENET : NTVAX::BILLY
University of North Texas   Internet : billy@vaxb.acs.unt.edu
                                SPAN : UTSPAN::UTADNX::NTVAX::BILLY
================================================================================

PS The ANONYMOUS account on TWG.COM gives a "User Authorization Failure"
   message now.
-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 90 09:55:24 GMT
From:      mcsun!ukc!dcl-cs!aber-cs!odin!pcg@uunet.uu.net  (Piercarlo Grandi)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: timimg-out a socket read

In article <VZ74GZC@ccs.ferranti.com> ihsan@ficc.ferranti.com (jaleel
ihsan) writes:

   I am trying to use tcp-ip for real-time application.  The application
   consists of a client in the field that collects real-time data every
   two seconds and sends it to the server which stores it in the database.
	[ ... ]
   The specification requires that if no data is received within 15 seconds,
   I declare the real-time data channel dead.

This is a fuzzy specification. What do you mean by "received"? If all
you mean is "data present at the socket" you can just time out the
select(2) call. If you mean "connection still alive" things are
different, but I cannot believe it...

   I do not know of any other means of timing-out the read except to use the
   keep socket "warm" option, [ ... ]

But this is something that has to do with the lower level protocols. You
want to check for the presence of *application* "data", I understand,
not whether the other side of the connection is still keeping open the
virtual circuit. The keepalive timeout has to do with whether the TCP
circuit is still there, not whether there is any data on it, really. Of
course if the circuit is dropped by the other side you assume that data
will not be forthcoming, but then the converse is not true.

Knowing that the circuit is still there (kind of carrier detect) will
not help you determine whether it is still being used...

   Did I choose the wrong vendor, or did I made a mistake in choosing tcp-ip
   for real-time application ? (8=:|)

I believe that you chose the wrong protocol. I reckon that for real time
work the default should be UDP, not TCP. I do not really think that you
need reliable, ordered virtual circuits, especially if the data you deal
with is, as in most real time monitoring applications, perishable and
time stamped. I think that for sampling/monitoring unreliable and
connectionless is better, and lower overhead. Hey, even NFS uses it.
Hey, they even use UDP for real time speech transmission...
--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jun 90 13:56:33 EDT
From:      SSJACK%ECUVM1.BITNET@ncsuvm.ncsu.edu
To:        TCP/IP List <tcp-ip@nic.ddn.mil>
Subject:   PD tn3270

I understand that there is a public domain tn3270 program available. Does
anyone know where I can locate this guy?

Our site consists of Ungermann-Bass NetOne TCP/IP with NIUpc and NIU boxes.
We are currently running plain vanilla TELNET and are unable to communicate
with other sites using tn3270.

Thanks in advance for your help.

========================================================================
Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================
-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 90 09:57:02 GMT
From:      usc!elroy.jpl.nasa.gov!spacm1!audit036@ucsd.edu  (--->D.L.)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: X.25 terminal/port servers out there?
> In article <4355.26879a8d@vax5.cit.cornell.edu> jeh@vax5.cit.cornell.edu writes:
>>What I'm really looking for is the X.25 equivalent of an Annex
>>box that has an Ethernet port on one side and the appropriate
>>synchronous serial port on the other
>
	DEC does have an X.25<>DECnet gateway, that O.K. ?
--
>>> between fact and fantasy there is a thin zone, the creative zone <<<-> D.L.
-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Jun 90 15:59:30 EDT
From:      hung@eniac.seas.upenn.edu (  Han  Hung)
To:        tcp-ip@nic.ddn.mil
Cc:        hung@eniac.seas.upenn.edu
Subject:   BSD UNIX Networking Source Code
Hi,

I was told that I can obtain the publicly available BSD UNIX networking
source code right from the ARPANET.  Does anyone know any more about
this.  I'm new to the networking community.   

Thanks,
kman

Kevin Agatone
c/o Advanced Computer Applications, Inc.
107 Penns Trail
Newtown, PA  18940
(w) 215-860-0700
(h) 215-579-9769

-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 90 14:37:58 GMT
From:      ncrlnk!ncrwic!sfc!chas@uunet.uu.net  (Charles Binford)
To:        tcp-ip@nic.ddn.mil
Subject:   Closing a Telnet session - exit or new Login:
I login to a unix host from my PC with telnet, finish what I'm doing, 
type ^d to logout, and then..... sometimes my session closes and
I'm back to my DOS prompt OR sometimes I get the Unix Login: banner
again.  WHY?   Usually a given host / pc telnet package will perform the
same way.  I have two different hosts with the same TCP package configured
the same way (as far as I can tell) that act different when using the same
pc package.

Any ideas?
-- 
Charles Binford, Automation Engineering, NCR PPD Wichita
    <C.Binford@Wichita.NCR.COM>
    <uunet!ncrlnk!ncrwic!c.binford>
-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 90 14:46:00 GMT
From:      fed!m1rlr01@uunet.uu.net  (Rich Rauscher)
To:        tcp-ip@nic.ddn.mil
Subject:   Fiber-ethernet
I'm trying to find out what hardware people have had the
most success with when connecting Fiber to ethernet.  My
criteria is based on compatibility (must be 10BaseT compliant),
expandibility, and price. (not neccessarily in that order)
Please mail responses to me and I will summarize.
Thanks,
Rich Rauscher
   ____   _    ____    Rich Rauscher, Unix Systems Programmer   
  | __ | | |  | __ |   Federal Reserve Board of Governors, Washington, D.C.
  |   |  | |  |   |    rauscher@madness.rutgers.edu
  | | \\ | |_ | | \\   rauscher@zodiac.bitnet
-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 90 16:31:55 GMT
From:      COINS@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   tn3270


     I am looking for an implementation of a tn3270 server for non-ibm
hosts, preferably UNIX-based.  Does anyone know where I
might find such a beast or how I might acquire it?  Barring that, does
anyone know where I might find specifications for a TN3270 server?
Thank you
Lynn
-------

-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 90 16:35:01 GMT
From:      stan!dancer!imp@boulder.colorado.edu  (Warner Losh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: The history of net 89
In article <1474@excelan.COM> keith@ca.excelan.com (Keith Brown) writes:
>Incidentally, Callan were an early OEM of ours so that's us too! Now I
>think about it, SGI were also. Oops!

Then why has TWG's documentation had net 89 as the example net for
many years (at least five now)?  Also, they were using net 89 as their
internal net up until about a year and a half ago.  Just curious.

-- 
Warner Losh		imp@Solbourne.COM
-----------[000471][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 90 17:36:19 GMT
From:      hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU  (Rick Jones)
To:        tcp-ip@nic.ddn.mil
Subject:   What Size IP on TR?

a toss-up question...

What size of packets will vendor x's tcp/ip over token ring tend to
send out onto the wire?  I realize that the theory says it could be
upwards of ~4K for 4Mbs and ~17K for 16Mbs (corrections welcomed;-),
but what sizes might I realisticly see if I were to stick an analyzer
on a TRN today, and oh, say, 2 years from today...

inquiringly,
rick jones

stardard disclaimers, and standard promises to summarize to the net
etc...
-----------[000472][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 90 17:56:33 GMT
From:      SSJACK@ECUVM1.BITNET
To:        comp.protocols.tcp-ip
Subject:   PD tn3270


I understand that there is a public domain tn3270 program available. Does
anyone know where I can locate this guy?

Our site consists of Ungermann-Bass NetOne TCP/IP with NIUpc and NIU boxes.
We are currently running plain vanilla TELNET and are unable to communicate
with other sites using tn3270.

Thanks in advance for your help.

========================================================================
Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
========================================================================

-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 90 19:01:29 GMT
From:      eplrx7!mcneill@louie.udel.edu  (Keith McNeill)
To:        tcp-ip@nic.ddn.mil
Subject:   netstat -i input errors...what do they mean?
When netstat -i reports an input error on an ethernet interface is there
some way to find out more about what the actual input error is?

Thanks,

Keith
-- 
    Keith D. McNeill              |    E.I. du Pont de Nemours & Co.
    eplrx7!mcneill@uunet.uu.net   |    Engineering Physics Laboratory
    (302) 695-9353/7395           |    P.O. Box 80357
                                  |    Wilmington, Delaware 19880-0357
--
The UUCP Mailer
-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 90 19:46:19 GMT
From:      van-bc!ubc-cs!calgary!ctycal!pat@ucbvax.Berkeley.EDU  (Patrick Woo)
To:        tcp-ip@nic.ddn.mil
Subject:   BSD TN3270 port to SYSV
Hi, I am porting the UCB TN3270 to a CLIX system (SYSV with BSD extension).
I got the following message in the compilation process.

"sys_bsd.c", line 218: Undefined symbol:  CBREAK
"sys_bsd.c", line 220: Undefined symbol:  CRMOD
"sys_bsd.c", line 294: Undefined symbol:  FIOASYNC

Can someone tell me what should I set those parameter to or which header file
has them in it.
Thanks in advance :-)
-- 
  Patrick Woo                ctycal!pat@calgary.UUCP
  Land Information Services                 or
  The City of Calgary       ...{alberta,ubc-cs,utai}!calgary!ctycal!pat
-----------[000475][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 90 20:03:29 GMT
From:      dsac.dla.mil!dsacg3.dsac.dla.mil!dsacg2.dsac.dla.mil!nrm1989@tut.cis.ohio-state.edu  (Christine E. Frisinger)
To:        tcp-ip@nic.ddn.mil
Subject:   OIPX and TCP/IP concurrently
We resently acquired a new office and have been told to make them 
technically compatible with our systems.  They currently have a
server (Samsung) with Novell Netware 2.1.2 running over Arcnet; and
they have 16 Z-248 pcs connected via Arcnet to this Novell Server.  
We are to convert them to TCP/IP running on Ethernet.              

We'd like to put the TCP/IP down to the pc level to give the pcs the 
total protocol suite (such as telnet, ftp, nfs, etc ...), so we'd 
like to avoid just putting a gateway or bridging board in the Novell
Server if possible.  Our idea is to recable the Server and 16 pcs for 
Ethernet and put Ethernet controller boards in the Server and pcs.  
We would then load Sun's PC-NFS onto the 16 pcs and have them boot 
between the drivers necessary to load PC-NFS (TCP/IP) or the Novell
(IPX).   

We believe this will work; however, since we don't have it currently 
running anywhere we'd like someone who has seen it work (or who knows
beyond a shadow of a doubt that it will work) to PLEASE let us know 
if we can do this.  Someone expressed an opinion to us that this would
not work--this person felt that it would be a problem to run IPX and 
TCP/IP on the same physical network without a bridge or gateway.  We
are confused and need help because we thought if everthing was running 
standard Ethernet (the physical layers) that the upper layers (IPX and
TCP/IP) would be okay on the same network.

-- 
Chris Frisinger              {uunet!gould,cbosgd!osu-cis}!dsacg1!cfrisinger
Defense Logistics Agency Systems Automation Center | 614-238-9123
DSAC-RMA, P.O. Box 1605, Columbus, OH 43216        | Autovon 850-
All views expressed are mine, I think
-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 90 21:30:40 GMT
From:      shelby!lindy!rt-jqj.Stanford.EDU!jqj@eos.arc.nasa.gov  (JQ Johnson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: X.25 terminal/port servers out there?
In article <4355.26879a8d@vax5.cit.cornell.edu> jeh@vax5.cit.cornell.edu
writes:

>What I'm really looking for is the X.25 equivalent of an Annex
>box that has an Ethernet port on one side and the appropriate
>synchronous serial port on the other

Gandalf, Develcon, and cisco all make boxes that can act as a telnet/Ethernet
to PAD/X.25 gateway.  We have on order a cisco Protcol Translator to serve
this purpose.  Several vendors of Unix boxes, for instance SGI and Sun, sell
software and hardware to make the Unix box an X.25 gateway, including PAD <=>
telnet translation functions.

JQ Johnson                              voice: 415-723-3078
Manager, Special Projects               Internet: jqj@jessica.stanford.edu
Networking and Communications Systems
Pine Hall Rm 125-A 
Stanford University
Stanford, CA 94305-4122
-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      28 Jun 90 22:21:53 GMT
From:      cs.utexas.edu!news-server.csri.toronto.edu!torsqnt!tmsoft!mshiels@tut.cis.ohio-state.edu  (Michael A. Shiels)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: X.25 terminal/port servers out there?
Even better you could use an Eicon X.25 card with NOS and have a telnet
server waiting to connect you to an X.25 session (and maybe emulate some sort
of a PAD) and also an X.25 server waiting to connect you to telnet sessions
again emulating some sort of a PAD.

Eicon is located in Montreal, Quebec.

PS: I already have a preliminary socket interface (hooked into NOS) for Eicon's
X.25 NABIOS (Netbios like) interface.
-----------[000478][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 90 00:47:42 GMT
From:      bellcore-2!envy.bellcore.com!karn@bellcore.com  (Phil R. Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mourning of the passing of the ARPANET

In article <9006271746.AA07726@vax.ftp.com>, jbvb@VAX.FTP.COM (James B.
Van Bokkelen) writes:
|> If we could hope to expunge all the Class A nets [...]

Actually, I'd prefer to do away with the artificial Class A/B/C distinction
altogether. Per-entry subnet masks in routing protocols like OSPF may well
make this practical. I've been using a similar scheme in amateur packet
radio TCP/IP for years and it has worked very well in keeping routing
tables small without requiring flag day conversions when topologies change.

Phil
-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 90 01:59:17 GMT
From:      zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!syd@tut.cis.ohio-state.edu  (Syd Weinstein)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Closing a Telnet session - exit or new Login:
chas@sfc.Wichita.NCR.COM (Charles Binford) writes:
>I login to a unix host from my PC with telnet, finish what I'm doing, 
>type ^d to logout, and then..... sometimes my session closes and
>I'm back to my DOS prompt OR sometimes I get the Unix Login: banner
>again.  WHY?   Usually a given host / pc telnet package will perform the
>same way.  I have two different hosts with the same TCP package configured
>the same way (as far as I can tell) that act different when using the same
>pc package.
This is an easy one (I going to regret that :-))

On Unix via modem whether you get a closed port/hangup
or another login depends on the setting of hupcl in the stty parameters.
If hupcl is set, the port is hung up on the last close (logout),
otherwise it is just recycled, and a new login is posted.
Some systems, the getty is programed to override this and close the
port itself as the getty starts, but, mostly this controls things.

If the TCP/IP login emulates a serial line in the system you connect to,
then the same rules apply for closing it, and whether or not a new
getty is forked or the port closed.

If the TCP/IP does not use waiting ports and getty, then generally
it just closes it on logout to reassign the port.

If you want to force logout to close the connection, just set
hupcl on the stty.  The opposite may keep it open with a new login
or may not depending on how the site has implimented TCP/IP and login
access over TCP/IP.
-- 
=====================================================================
Sydney S. Weinstein, CDP, CCP                   Elm Coordinator
Datacomp Systems, Inc.                          Voice: (215) 947-9900
syd@DSI.COM or dsinc!syd                        FAX:   (215) 938-0235
-----------[000480][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jun 90 15:41 PDT
From:      Michael Stein                        <CSYSMAS@OAC.UCLA.EDU>
To:        jbvb@VAX.FTP.COM
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: What Size IP on TR?
> >What size of packets will vendor x's tcp/ip over token ring tend to
> >send out onto the wire?.....
>
> At one point, there seemed to be a general consensus of the IBM
> implementations that the length indicated in the RIF was to be 2052
> bytes (in fact, some of them insisted on it).  This may have
> changed, but people who coded to suit it may not have.

Watch out!  What the RIF says and what you really want to do may
be different things.

An example is a RIF which says 2052 where there are routers to
Ethernet (max IP packet size of 1500).  Any IP packet larger than
1500 will get fragmented.

Using a RIF size of 1500 (then next smaller than 2052) is worse
but for the other direction.  A 1500 byte RIF size only allows
1500-8 => 1492 bytes of IP packet (8 bytes are used for the IEEE
stuff on TR, but not on Ethernet) and will result in full size
Ethernet packets being fragmented on Token Ring.

PS: Some Token Ring support is leaning toward 4 to 8 K packets...
-----------[000481][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Jun 90 13:13:33 EDT
From:      jbvb@vax.ftp.com  (James B. Van Bokkelen)
To:        hpda!hpcupt1!hpindwa!raj@ucbvax.Berkeley.EDU  (Rick Jones)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: What Size IP on TR?
>What size of packets will vendor x's tcp/ip over token ring tend to
>send out onto the wire?.....

At one point, there seemed to be a general consensus of the IBM
implementations that the length indicated in the RIF was to be 2052
bytes (in fact, some of them insisted on it).  This may have
changed, but people who coded to suit it may not have.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000482][next][prev][last][first]----------------------------------------------------
From:      ljm@obelix.twg.com
To:        tcp-ip@nic.ddn.mil
Cc:        
Subject:   Re: IPX and TCP/IP concurrently

>We resently acquired a new office and have been told to make them 
>technically compatible with our systems.  They currently have a
>server (Samsung) with Novell Netware 2.1.2 running over Arcnet; and
>they have 16 Z-248 pcs connected via Arcnet to this Novell Server.  
>We are to convert them to TCP/IP running on Ethernet.              
>
>We'd like to put the TCP/IP down to the pc level to give the pcs the 
>total protocol suite (such as telnet, ftp, nfs, etc ...), so we'd 
>like to avoid just putting a gateway or bridging board in the Novell
>Server if possible....

You need not throw away your Arcnet boards to get a full TCP/IP stack
on each of your workstations.  Software is available from Wollongong
and clarkson which encapsulates IP within IPX allowing any Novell
workstation to support 'telnet, ftp, nfs, etc ...'.

>We believe this will work; however, since we don't have it currently 
>running anywhere we'd like someone who has seen it work (or who knows
>beyond a shadow of a doubt that it will work) to PLEASE let us know 
>if we can do this...

If you do convert to dual TCP/IP and IPX stacks over Ethernet cards,
I am happy to report that real live people have gotten Novell to work
with NFS/TCP/IP software products from FTP software, SUN, Beame and
Whiteside, and The Wollongong Group.

enjoy,
leo j mclaughlin iii
The Wollongong Group
ljm@twg.com

-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 90 12:49:47 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!uwm.edu!mailrus!bbn.com!mckenzie@ucsd.edu  (Alex McKenzie)
To:        tcp-ip@nic.ddn.mil
Subject:   The history of net numbers
Since there have been a number of questions about the history of network
number assignments, I've searched the "Assigned Numbers" RFCs to see
what light they could shed on the subject.  Here's what I found:

The first RFC which specified "numbers assigned to identify networks for
use in the internetwork protocol experiments" was RFC 717 (1 July 1976).
It gave the following 4 network numbers:
	BBNRCCnet       3
	SanFranPRnet    7
	ARPANET        10
	BostonPRnet    11

The first RFC to assign all network numbers less than 11 was RFC 750 (26
September 1978).  It gave the following assignments:
 0      Reserved
 1      BBN Packet Radio Net
 2      SF Bay Area Packet Radio Net #1
 3      BBN RCC Net
 4      Atlantic Satellite Net
 5      Washington DC Packet Radio Net
 6      SF Bay Area Packet Radio Net #2
 7      CHAOS Net
 8      BBN SATNET Test Net
 9      Ft. Gordon Packet Radio Net
10      ARPANET
11      University College London Net
12      CYCLADES [French national research net]
13      National Physical Laboratory [UK]
14      TELENET
15      British Post Office EPSS [Experimental Packet Switching Service]
16      DATAPAC
17      TRANSPAC
18      LCS Network [MIT]
19      TYMNET
20      Ft. Sill Packet Radio Net
21      DCEC EDN [Experimental Data Net]
I can't see much pattern in the assignments, so this leaves the question
of why ARPANET was given the number 10 unanswered.  Maybe Jon or Vint
has a recollection.

The first RFC to divide the network numbering into Classes was RFC 790
(September 1981).  It specified the Class A/B/C structure.  At the time
there were about 42 total network numbers assigned.

I don't believe net 89 has ever been assigned via the "Assigned Numbers"
RFCs.

Alex McKenzie
 
-----------[000484][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 90 14:44:30 GMT
From:      ncrlnk!ncrstp!npdiss1!mercer@uunet.uu.net, Mercer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PD tn3270
In article <9006282056.AA26687@ucbvax.Berkeley.EDU> SSJACK@ECUVM1.BITNET writes:
:
:I understand that there is a public domain tn3270 program available. Does
:anyone know where I can locate this guy?
:
:Our site consists of Ungermann-Bass NetOne TCP/IP with NIUpc and NIU boxes.
:We are currently running plain vanilla TELNET and are unable to communicate
:with other sites using tn3270.
:
:Thanks in advance for your help.
:
:========================================================================
:Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
:Systems Programmer                                 (919) 757 - 6401
:East Carolina University                          Greenville, NC 27858
:========================================================================

Please copy me as well (or post).

TIA
-- 

Dan Mercer
Reply-To: mercer@npdiss1.StPaul.NCR.COM (Dan Mercer)
"MAN - the only one word oxymoron in the English Language"
-----------[000485][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 90 14:54:42 GMT
From:      mcsun!hp4nl!star.cs.vu.nl!sater@uunet.uu.net  (Staveren van Hans)
To:        tcp-ip@nic.ddn.mil
Subject:   parallel networks routing question
Suppose (part of) a network looks like this

  ---------------------------------------------------------  network A
		|				|
	-----------------		-----------------
	|      A.1      |		|      A.2	|
	|		|		|		|
	|      B.6	|		|      B.7      |
	-----------------		-----------------
		|				|
  --------------------------------------------------------- network B

so two multihomed hosts connected with parallel networks.
Further suppose that network B is preferable to network A, because of
load, or because it is 10x as fast (FDDI vs Ethernet).
How would one set up addressing and routing for such a configuration?

Using the DNS address lookup you get two addresses for each machine,
but most software doesn't understand that currently and only uses the
first one. Now the documentation suggests that you can order the
addresses so that certain preferred networks come in front, but looking
at our bind source code shows that that is not implemented.

Ideally this should be done by the routing layer of course, but current
routing software will probably send a packet for A.2 onto network A, unless
a host route for A.2 points to B.7. You can of course set up all these
routes by hand, but if the network size increases this gets to be too
much trouble.

How do people solve this? Do people actually have situations like this
already? Inquiring minds want to know.

	Hans van Staveren
-----------[000486][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 90 20:39:14 GMT
From:      news-server.csri.toronto.edu!utgpu!utzoo!henry@rutgers.edu  (Henry Spencer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Closing a Telnet session - exit or new Login:
In article <691@sfc.Wichita.NCR.COM> chas@sfc.Wichita.NCR.COM (Charles Binford) writes:
>I login to a unix host from my PC with telnet, finish what I'm doing, 
>type ^d to logout, and then..... sometimes my session closes and
>I'm back to my DOS prompt OR sometimes I get the Unix Login: banner
>again.  WHY?  ...

It is up to the host whether it tries to hang up the line when a user
signs off.  Some don't.  Some do.  Some do, but only if no processes
remain on the line (i.e. if you started something in the background,
or news/mail/etc did so on your behalf, no hangup).  This could easily
depend on details of the telnet daemon, the pseudo-tty implementation,
and the login command, to name just three.
-- 
"Either NFS must be scrapped or NFS    | Henry Spencer at U of Toronto Zoology
must be changed."  -John K. Ousterhout |  henry@zoo.toronto.edu   utzoo!henry
-----------[000487][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 90 21:27:57 GMT
From:      ficc!ihsan@uunet.uu.net  (jaleel ihsan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: timimg-out a socket read... AND THE ANSWER IS ...
... do something like this (info. provided courtesy of ted@Ultra.com):

s = socket();
connect(s,..)
timeval.tv_sec = 15;  /* set timeout to 15 seconds */
timeval.tv_usec = 0;
rmask = 1<<s;
if (select(32, &rmask, (struct fd_set *)0, (struct fd_set *)0, timeval)) == 0 {
    close(s);
}

I intentionally left out information reguarding my OS and the tcp-ip
implementation from my original posting because, before solving the
problem on my platform, I wanted to know:

	1. What does the TCP protocol standard has to say about it.

	2. What the user interface standard has to say about it.

The overwhelming response (I got through news, but mainly through email)
and its unanimity clearly indicates that the answer to 2. above is that
"select(2)" IS the standard user I/F.

The answer to 1. above (courtesy of gjack@datlog.co.uk) is:

Section 4.2.3.6 of RFC-1122 (Host Requirements protocol) says
keepalives MAY be implemented (ie are OPTIONAL), if provided
the interval MUST be configurable.

Thankyou so much to those who replied.

BTW, the OS I *have* to work with is Intel's RMX (Real-Time Executive)
and the tcp-ip implementation is from a third party vendor who has
taken some unix tcp-ip driver and ported a subset of it to RMX, and
that's one of the problems.

In addition to the standard user I/F "read()", the vendor provides an
RMX async read with time-out capability.  When the timer times-out,
a "no-data-to-read" indication is returned but unfortunately the read
is not canceled and no mechanism is provided so that I can cancel the
read (ie a "cancel io" function is not provided by the tcpip driver)
On top of that the standard user I/F function "select()" is not provided.
Pretty unreasonable thing to do !!!

So if the time-out occurs, I want to close the socket and try to
reestablish the connection.  But due to the pending read I cannot
do it without having a dangling TCP connection.  And I cannot
afford to leave a dangling connection, because if happens a few
times, resources associated with the connections will dry up and
my system will be dead in the water !!!

Jaleel
-----------[000488][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 90 21:35:39 GMT
From:      ficc!ihsan@uunet.uu.net  (jaleel ihsan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: timimg-out a socket read
In article <12600781585.32.LYNCH@A.ISI.EDU>, LYNCH@A.ISI.EDU (Dan Lynch) writes:
> 1)  As noted by Comer, the application (meaning vendor) is not obliged
> to expose the timer values to the application, but also, the vendor is certainly
> not prevented from doing so.  Most implementations are, in fact, not too
> good about letting the individual application instance set values such
> as timer values.  This is simply a matter of choice.  The protocol supports
> the concept, but if an implementaiton had to keep track of this on a
> "per instance" basis, it would add to the implementation storage space
> requirements.  

I agree asking TCP to keep timers on a "per instance" basis would be
an unreasonable and I dont want to be unreasonable !!! However asking
the OS to keep a timer on a "per read" basis would not be an unreasonable
request.

Jaleel
-----------[000489][next][prev][last][first]----------------------------------------------------
Date:      29 Jun 90 22:41:00 GMT
From:      CSYSMAS@OAC.UCLA.EDU (Michael Stein)
To:        comp.protocols.tcp-ip
Subject:   Re: What Size IP on TR?

> >What size of packets will vendor x's tcp/ip over token ring tend to
> >send out onto the wire?.....
>
> At one point, there seemed to be a general consensus of the IBM
> implementations that the length indicated in the RIF was to be 2052
> bytes (in fact, some of them insisted on it).  This may have
> changed, but people who coded to suit it may not have.

Watch out!  What the RIF says and what you really want to do may
be different things.

An example is a RIF which says 2052 where there are routers to
Ethernet (max IP packet size of 1500).  Any IP packet larger than
1500 will get fragmented.

Using a RIF size of 1500 (then next smaller than 2052) is worse
but for the other direction.  A 1500 byte RIF size only allows
1500-8 => 1492 bytes of IP packet (8 bytes are used for the IEEE
stuff on TR, but not on Ethernet) and will result in full size
Ethernet packets being fragmented on Token Ring.

PS: Some Token Ring support is leaning toward 4 to 8 K packets...

-----------[000490][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 90 01:36:30 GMT
From:      bellcore-2!envy.bellcore.com!karn@bellcore.com  (Phil R. Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: X.25 terminal/port servers out there?

In article <1990Jun27.195629.25792@watserv1.waterloo.edu>,
broehl@watserv1.waterloo.edu (Bernie Roehl) writes:
|> Hmm.  Don't know if this will work, but there are HDLC cards for PCs...
|> could you do it with a PC, an ethernet card, an HDLC card and NOS?

It's possible, but it would take some work. You'd have to write an X.25
packet layer (level 3). Also, the LAPB in AX.25 has diverged a bit from
standard CCITT X.25, and you might have to make some changes to make it
interoperate properly. And the LAPB would have to be extricated from the
AX.25 addressing stuff. I tried to make it modular, but having never
actually separated the two sections I wouldn't want to bet that it would
go perfectly the first time.

Phil
-----------[000491][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 90 03:58:38 GMT
From:      ficc!ihsan@uunet.uu.net  (jaleel ihsan)
To:        tcp-ip@nic.ddn.mil
Subject:   RE: timing-out a socket read

Keeping in mind the real-time requirements, the only acceptable way
I can keep my own timer in the application (as opposed the OS keeping it
for me) is if the the OS provides me a function to "read data or time-out"
such that the time out is implemented in an interrupt/event driven manner.
(Unfortunately this is not available to me, and this is what I am trying
to get from my TCP-IP vendor.)

Sleeping for 1 second and rechecking if data is there yet or not, (and
repeating this for 15 seconds, in case I want a 15 second time-out) is
unacceptable for my real-time application for the following reasons
(which happen to be some very basic real-time design considerations):

	1. Data may arrive just as I go to sleep.  In this case the
           data processing will be delayed by a WHOLE second.  This
           is unacceptable.

	2. In order to reduce the aforementioned data processing
           delay, I cannot reduce by sleep timer (say form 1 to 0.1 sec),
           because the program that is trying to read data (and has
           to be one of the high priority tasks) will use up the CPU
           resource just checking if the data is there or not.
           This is unacceptable too !

Real life happens to be little more complicated in real-time and thats
why I like real-time applications !!!
-----------[000492][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 90 06:03:14 GMT
From:      emv@math.lsa.umich.edu (Edward Vielmetti)
To:        news.software.nntp,news.admin,comp.protocols.tcp-ip
Subject:   nntp usage of the nsfnet backbone


I was curious as to how heavily used the NSFnet backbone was for NNTP
traffic.  Some (though certainly not all) of the useful raw data is
available from nis.nsf.net in the STATS directory; the file
NSFyy-mm.PORTS gives the traffic breakdown by port for traffic which passes
through the NSSes.

As you can see, traffic is growing at a healthy clip, doubling in just
under 9 months.  It also looks as though NNTP traffic is staying at
about the same fraction of overall network usage, hovering in at
around 11-12%.  By point of comparison, VMNET (BITNET II) traffic rose
in absolute terms to just about 100M packets, but has been declining
in relative terms from a high of 5.4% down to about 3.4% of total traffic.
On the other hand, FTP traffic has gone from 17.5% of the total up to
almost 24%; the big jump came in Jan 90 when FTP data jumped from 367M
packets to 522M packets.  I suspect that X11R4 had something to do with that.

I don't imagine that the NSFnet is going to stop passing NNTP traffic
any time soon, given the general utility of netnews and its relatively
steady-state consumption of backbone resources.  It would seem to be
reasonable to suggest the following for those people who are setting
up NNTP connections to try to minimize the number of hops that the
bulk of their incoming traffic has to traverse; in particular, if you
are a leaf site on the left coast, it would hardly make sense to get
all of your news from a single site on the right coast.

NSF89-08.PORTS: nntp               119      156,203,409     11.578
NSF89-09.PORTS: nntp               119      198,647,273     13.161
NSF89-10.PORTS: nntp               119      205,263,003     11.962
NSF89-11.PORTS: nntp               119      237,806,649     12.287
NSF89-12.PORTS: nntp               119      223,701,824     11.604
NSF90-01.PORTS: nntp               119      241,124,672     10.951
NSF90-02.PORTS: nntp               119      268,790,579     11.623
NSF90-03.PORTS: nntp               119      287,652,752     11.400
NSF90-04.PORTS: nntp               119      308,344,616     11.451
NSF90-05.PORTS: nntp               119      333,694,048     11.718

--Ed

Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
comp.archives moderator

-----------[000493][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 90 20:01:20 GMT
From:      zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!uhnix2!davison@tut.cis.ohio-state.edu  (Daniel B. Davison)
To:        tcp-ip@nic.ddn.mil
Subject:   IP addresses of timechimers needed
Is there a list of timechimers somewhere?  I didn't see any listed in
rfc1119.

Thanks


dan
ps whoever made rfc1119 a postscript-only file needs to be spoken to
firmly. 

--
dr. dan davison/dept. of biochemical and biophysical sciences/univ. of
Houston/4800 Calhoun/Houston,TX 77054-5500/davison@uh.edu/DAVISON@UHOU

"Without the voice of reason, every faith is its own curse" -- Sting

Disclaimer: As always, I speak only for myself, and, usually, only to
myself.
-----------[000494][next][prev][last][first]----------------------------------------------------
Date:      30 Jun 90 21:48:36 GMT
From:      uvaarpa!murdoch!bimbo!boyter@mcnc.org  (Maj Brian Boyter)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PD tn3270
In article <9006282056.AA26687@ucbvax.Berkeley.EDU>
> :I understand that there is a public domain tn3270 program available. Does
> :anyone know where I can locate this guy?
In article <126@npdiss1.StPaul.NCR.COM>
> Please copy me as well (or post).

I think you mean the tn3270 which Berkeley modified from telnet code....
It is FTP-able from ucbarpa.berkeley.edu or uunet.uu.net....   
That version works on many unix systems...   
There are ports to HPUX and IRIS on iris613.gsfc.nasa.gov
and Dec 3100 on bimbo.tn.cornell.edu

Brian

-- 
---------------------------------------------------------------
   Maj. Brian A Boyter
   US Army Foreign Science & Technology Center
   Charlottesville, Va 22901                         __
   off: (804)980-7362                              (    )
   home:     973-9440                             {      }
   FAX:      973-9047                              (    )
   boyter@fstc-chville.army.mil                      ||
                                                     ||
   Just say glow......                       _______<  >_______

END OF DOCUMENT