The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1991)
DOCUMENT: TCP-IP Distribution List for July 1991 (439 messages, 277958 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1991/07.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 Jul 91 08:13:55 GMT
From:      emv@msen.com
To:        comp.protocols.tcp-ip
Subject:   ``cream skimming''


I'm collecting good quotes on networking and competition.  In
particular I'd like to track down the genesis of the phrase "cream
skimming" as applied to the commercialization of the net. 

Other quotes welcomed.

--Ed
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com

--- cream skimming ---
			
'I, unfortunately, believe we will see what you call a ARPA net style
 network as the "commercial" players see that cream skimming is just too
 profitable.  Its just too hard to resist capturing the big guys via
 direct connect and leaving the little fish for the "utility" networks.'
		Dave Farber, com-priv, Nov 1990.

'In the immortal words of Bob Kahn: "You gotta have the flow to get the skim."'
		Steve Wolff, com-priv, May 1991.

'At the June 1990 FARNET meeting, Al Weis, IBM VP for Engineering and
 Scientific Computing, met with the FARNET executive committe at a non-
 disclosure meeting to inform them that a new not-for-profit corporation,
 tentatively called Newnet, was being set up.  He asked the FARNET
 executive committee to work with him in helping to define the relationship
 between the regionals and the new entity.  In a series of meetings over
 the summer the FARNET executive expressed apprehension at the prospect
 of the regionals competing directly with a corporation backed by such
 players as IBM and MCI.  The FARNET executive committee, in a letter to
 Weis on Aug 2, 1990, underscored the idea that the regional networks and
 the coalitions that they have fostered not only provide operations services
 but are acting as catalysts for information exchange and application
 development...The midlevels have been able, in many cases, to use revenue
 generated from larger and wealthier institutions to support the connection
 of smaller, poorer institutions to the network.  If NewNet "skims the cream"
 from the market or is not sensitive to the balances that currently exist,
 the position of the midlevel networks, and more importantly of the smaller
 users of the NSFNET, may be jeopardized.'

		Richard Mandelbaum and Paulette Mandelbaum,
		"The Strategic Future of the Mid-Level Networks",
		December 21, 1990; in com-priv, Mar 1991.

'The market-driven suppliers of TCP/IP based Internet connectivity are
 naturally going after those markets which can be wired at low cost
 per institution, i.e. large metropolitan areas, especially those with
 a high concentration of R&D facilities, such as Boston, San Francisco,
 and Washington DC.  In the voice environment, this kind of targeted
 marketing by unregulated companies is widely recognized as cream-skimming.'
		Brian Kahin, editor,
		"Commercialization of the Internet, Summary Report",
		November 1990; Network Working Working Group (sic),
		Request for Comments, RFC 1192.  Based on a workshop
		held by the Science, Technology, and Public Policy
		Program of the John F. Kennedy School of Government,
		Harvard University, March 1-3, 1990. [*]

[*] Found with the assistance of WAIS, Brewster Kahle's "Wide Area
    Information Service", in particular the "internet-rfcs" server
    running on quake.think.com.  An invaluable resource.  See
    quake.think.com:/pub/wais/ for details.  It's a shame that
    com-priv isn't in a WAIS somewhere.

[**] com-priv archives on uu.psi.com:/archive/com-priv/*

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 91 09:02:30 GMT
From:      VANCE@TGV.COM (Icarus)
To:        comp.protocols.tcp-ip
Subject:   Re:  Traceroute done differently?

>Is there a traceroute like utility written for unix that uses the
>record route option and or the strict source route option? When I got
>traceroute today I was suprised to find that it doesn't use these ip
>options.

If there is such a utility, it wouldn't be very useful in the Internet.  The IP
Header Length in an IP datagram is only 4 bits, giving you a maximum size IP
header of 15 32-bit words.  5 words are taken up by required fields, leaving 10
words for options.  Can't get many IP addresses into what's left.

Regards,
-----Stuart

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 91 09:23:31 GMT
From:      pah@xtel.co.uk (Pippa Hennessy)
To:        comp.os.os2.misc,comp.protocols.tcp-ip
Subject:   TCP/IP under OS2

-------

Has anyone got any experience of products that run under OS2 using
TCP/IP?  If so, I'd appreciate an e-mail telling me about products,
experiences, or anything.  I'm posting on behalf of a friend who is
supposed to plan the development of a system involving a WAN, TCP/IP,
and OS2.....

Pip (the hairy one)

-- 
==================Pippa Hennessy (the hairy one)==================
| p.hennessy@xtel.co.uk   tel +44 602 412648  fax +44 602 790278 |
|  X-Tel Services Ltd, University Park, Nottingham, NG7 2RD, UK  |
==============the moon's a balloon and I'm a banana===============

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 91 09:32:33 GMT
From:      craig@SICS.SE (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   IEEE Network: Call for Submissions


[A small personal note.  When I decided to run for SIGCOMM Chair this
summer I also decided to step down as editor of SIGCOMM's journal,
Computer Communication Review (CCR) -- I'd have to step down as editor
if I became chair.  Shortly after I'd made that decision, weeks ago
IEEE asked me if I'd be willing to take on editing IEEE Network --
they feel it needs editorial restructuring.  One of my conditions of
accepting is that we not position IEEE Network in such a way as to harm
CCR. -- Craig]

	Call for Submissions -- IEEE Network

IEEE Network Magazine is the IEEE's flagship publication in the
area of computer communication.  To better serve the interests of the
of the computer communication community, IEEE Network is
going through an editorial restructuring under a new Editor-in-Chief,
starting with the January 1992 issue.

One of the new editorial goals is to organize the issues of your magazine
around topics perceived to be important by the computer communications community
at large.  This involves organizing the issues around articles received through
open submission on topics of interest to the community.  Good quality submission
from you will be the key to the Magazine's success.

IEEE Network publishes technically refereed articles on all topics
related to the exchange of information -- of any type, including data, text,
images, and voice -- among computers or among computers and individuals using
computer based communication technology.  To help ensure that good
submissions are published in a timely fashion, the editorial board's
goal is to return reviews to authors within ten weeks of submission
and to publish articles within six months of receiving final copy.

The editorial goal of the magazine is to provide its readers with highly
readable, carefully edited, useful, and timely information.  This includes
articles discussing new results and technologies as well as articles on useful
practices and techniques, retrospective articles, and commentaries or reasoned
polemics.  As an illustration of the general flavor desired, a submission that
sketches the underlying mathematics of a new queueing theory result and then
illustrates its usefulness by presenting an alternate solution to a network
planning problem would be highly preferable to one that dwells on the
mathematical development of the result itself.

Topics of interest include, but are by no means limited to, the following:

    * progress in the development and implementation of gigabit and terabit
	data networks and switching systems;

    * naming and directory services, especially for systems designed
	to scale to billions of end systems;

    * traffic analysis and modeling techniques;

    * network operations;

    * novel distributed applications;

    * thoughts about the future of communication networking (integrated
	services? to what extent? why?);

    * synchronization (e.g. voice and video channels);

    * network security (both practices and mechanisms);

    * technology deployment and enhancement

    * solutions to deployment problems (such as getting FDDI interfaces
	to got at 100 Mbs; implementing 802.6 interfaces; etc)

Prospective authors encouraged to show their interest in and enthusiasm for
computer communications by submitting articles on topics of their choice to
the new editorial board at the following address:

    IEEE Network Magazine
    attn: Editor-in-Chief (submissions)
    IEEE
    345 East 47th St
    New York City, New York 10017-2394
    USA

*Please do not send submissions to any other address, as only submissions sent
to the IEEE in New York will be considered.*

A method for submitting articles electronically is in preparation.  Contact
us at the address above if you are interested in submitting electronically.

Craig Partridge, Editor-in-Chief (effective January 1992)
John Daigle and John D. Spragins, Senior Editors
IEEE Network Magazine

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 91 14:38:25 GMT
From:      jas@proteon.com (John A. Shriver)
To:        comp.protocols.tcp-ip
Subject:   TCP Throughput over E-net (Trailers)

Oh, please, no, not trailers!  Trailers don't help a Sun.  Sun didn't
put all the fancy DMA stuff info the kernel that Berkeley had.  (Their
machine also does not have such fancy DMA mapping in hardware as a VAX
has.)  They use copy loops to copy the packets from the 82586 or LANCE
data structures into mbufs, so trailers are just a nuisance.

The only machine trailers ever helped was a VAX (who buys them to run
UNIX anymore?), and the benefit was not worth the compatability
problems they caused.

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 91 16:43:04 GMT
From:      bdale@col.hp.com (Bdale Garbee)
To:        comp.protocols.tcp-ip
Subject:   Digital Voice Protocols

I'm interested in corresponding with anyone who is currently working or has
recently worked on digital voice protocols.  

I've asked my library to do a literature search, but in the meantime, is there 
anything online more recent than RFC 741?  Any pointers to good papers and/or
books?  This is a relatively new area of interest for me.

Bdale

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 91 17:00:39 GMT
From:      steve@CISE.NSF.GOV (Stephen Wolff)
To:        comp.protocols.tcp-ip
Subject:   ``cream skimming''

You do a grave injustice to Bob Kahn by lumping in his aphorism "You gotta
have the flow to get the skim" with quotes on the subject of cream-skimming.

The implication of Bob's quote is just the OPPOSITE of cream-skimming; i.e.,
you can't subsidize a pro bono publico activity by a surcharge on your main
customers unless the "flow" from them is large enough to make the "skim"
for public service imperceptible.

-s

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 91 17:19:21 GMT
From:      vaf@Valinor.Stanford.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re: OSPF Implementation on Stub Networks

In article <9106301231.aa26650@delmarva.delmarva.COM>, scoggin@delmarva.delmarva.COM (John Scoggin) writes:
|> Are there any medium-to-large (>10 routers) out there who have implemented
|> OSPF within their nets?  I am familiar with the testing done at University of
|> Maryland (thanks for publishing those excellent papers!), but I am curious
|> just how many folks are actually using OSPF and what their experience has
|> been in terms of performance and stability.
|> 
|> We are hoping to implement OSPF internally when Wellfleet releases it (Real
|> Soon Now).
|> 
|> ----------------------------------------------------------------------
|> John K. Scoggin, Jr.	
|> Supervisor, Network Operations		Phone:  (302) 451-5200
|> Delmarva Power & Light Company		Fax:	(302) 451-5321
|> 500 N. Wakefield Drive			Email:	scoggin@delmarva.com
|> Newark, DE  19714-6066	
|> ----------------------------------------------------------------------

BARRNet has been running OSPF since version 1 became available from Proteon over a year and a half ago. At present, we are running OSPF on 31 Proteon routers and plan to run it on at least some of our cisco routers as well, once the software is available from cisco. Our experience has been that OSPF works very well in a network of our size and we expect it to continue to work well as we deploy it on more and more routers in our system (the eventual goal is to have OSPF running on all 80+ cisco and Proteon 




routers in BARRNet as well as on all 30 or so cisco routers in the Stanford campus network).

	Vince Fuller, Stanford/BARRNet

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 91 19:01:33 GMT
From:      etb@milton.u.washington.edu (Eric Bushnell)
To:        comp.sys.apollo,comp.protocols.tcp-ip
Subject:   routed problem on Apollo 400s

One of my apollos has a tcp/ip problem that's got me stumped.
If somebody could offer some clues, I'd really appreciate it.

Summary of the problem:

routed on an HP/apollo 400s running Domain OS 10.3.4 loses its 
routing table after one to five days.

The gory details:

Every few days, this host becomes unable to communicate with hosts
outside its own tcp/ip subnet. netstat -r says "no route entries found"
routed itself keeps running--it just doesn't seem to rebuild its
routing tables. It doesn't mark the interfaces, eth0 and lo0, down.
To fix it, I have to kill and restart routed. It then works for another
one to five days. 

It doesn't seem to be a network problem. There are
two other apollos next to it (DN 4500 and 5500) on the same ethernet
segment which do NOT suffer this problem. Also, when routed is running
correctly after being restarted, I can detach the network connection,
let the routes time out, then reconnect the net, and routed DOES rebuild
the routing table. Besides that, low-level apollo services (non-tcp/ip)
are still working.

I've been running routed with logging, and I've also been running a 
script that checks netstat -rn every 3 minutes and logs the time and
the output of stderr. 

When it happened early this morning, routed logged route changes
until 1:12 AM. The netstat checker, however, did not return an error
until 4:52 AM.

The machine is an HP/Apollo 400s running Domain OS 10.3.4. It runs
tcpd -c (the -c is for compatibility with apollo hosts running Domain 10.2)
and routed -f -q. It's native (for apollo services) network is 802.3.

Finally, I have another 400s with the same configuration, running the
same OS and the same tcpd and routed processes, on a similar network,
and it does NOT have this problem.

Work-around:

I can add a default route, which lets the node communicate after
routed fails, but this is not an optimal or desirable solution.

The pathetic plea for help:

If you have some information that might lead to the arrest and
capture of this annoying problem, please post it or send me some
mail.

Thanks.


-- 
Eric Bushnell
Univ of Washington Civil Engineering
etb@u.washington.edu

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 91 19:08:20 GMT
From:      jamieson@synapse.bms.com (Stephen Jamieson)
To:        comp.protocols.tcp-ip
Subject:   Vendor for vendor code 00: 00:03

I was wondering if anyone out there known the vendor who
owns vendor code 00:00:03. 


Thanks in advance

steve
   ___                                      
   ] [ Stephen Jamieson / Network Engineer  
  / o \ Scientific Information Systems      
 /-o---\ Bristol-Myers Squibb Pharmaceutical Research Institute
 \___o_/  Internet: jamieson@bms.com / Phone: 609-921-5674
  

-- 
   ___                                      
   ] [ Stephen Jamieson / Network Engineer  
  / o \ Scientific Information Systems      
 /-o---\ Bristol-Myers Squibb Pharmaceutical Research Institute

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 91 19:11:34 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Throughput over E-net (Trailers)

In article <9107011438.AA13159@sonny.proteon.com> jas@proteon.com
(John A. Shriver) writes:
>They use copy loops to copy the packets from the 82586 or LANCE
>data structures into mbufs, so trailers are just a nuisance.

I always thought that Sun picked up the Van Jacobson patches plus did
some of their own optimization to get these good results.  One older
version of VMS based TCP/IP system that didn't have the VJ patches did
about 250K/sec, while another version (that did have the VJ patches)
did about 300-500K on the same machine against the same sun.

Warner
-- 
Warner Losh		imp@Solbourne.COM
But it was our hill.  And they were our beans.

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 91 19:12:26 GMT
From:      eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert)
To:        comp.protocols.tcp-ip
Subject:   Re: Questions around WELLFLEET Routers

From article <9106281702.AA13272@enet-gw.pa.dec.com>, by richardson@remacp.enet.dec.com ("John C. Richardson / Digital Equip. Corp / 508467-8720"):
> 
> 	Hello All,
> 
> 	I'm trying to size up some equipement and iron out some issues:
> 
> 	Can anyone tell me if the Wellfleet Multi-Protocal Routers have
> 	any diagnostics (floppy or tftp) other than the ROM based power
> 	-up diags?  The machines in review are the LN-2000 (Link Node)
> 	and CN-3000 (Concentrator Node).  They (Wellfleet) offer hardware
> 	& maintenance support via Prime Computer, and neither will ellaborate..

Why should you want to buy from a company that is not interested
in answering your questions ?
Anyway: there is an event trace which is available from within the
manager mode and which can additionally be written to floppy or
reported by snmp. It's quite basic though and far less informative than
those of some other vendors.

> 	-Mean time between failures of either type (including the FN-1000,
> 	 Feeder Node).

Depends on the software release and configuration that you are running.
Mostly stable if you don't push it.

> 	-The CN-3000 can have a secondary power supply installed as backup,
> 	 How reliable is it?
> 
> 	-What do you _like_ , _dislike_ about the units?

Most important: See your own first remark.

> 	-Any "Un-documented Features" that pop up ?

If you mean "bugs" - it depends on the software release and the configuration
that you are using. There really is no global measurement for this, except
that the MTBF depends very much on customer support and that is measurable
(See above).


> 		Public forum or personal Email accepted

There is a mailing list wellfleet-l@nstn.ns.ca dedicated
to wellfleet router, please cast further questions onto that list,
but don't expect so may active participants as the cisco mailing list carries.


> 	Thank you,

If it helps
---

             Toerless.Eckert@informatik.uni-erlangen.de
    /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=Eckert/G=Toerless
    ... "abuse" means you didn't write a proposal and get grant money,
    otherwise it's "research". -- Edward Vielmetti

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 91 20:56:57 GMT
From:      rp@rpx.UUCP (Rich Patterson)
To:        comp.protocols.tcp-ip
Subject:   Where can I get current RFCs ?  -- The addr. I have doesn't work.

Hi,
	I am trying to find out where I can obtain the current RFCs.  In
the past I used: service@nic.ddn.mil, however it doesn't seem to work
anymore.  Could someone send me current information on how to access the RFCs.
Thanks in advance.

Rich Patterson
rp@rpx
rpx!rp@decwrl.dec.com
{decwrl,pyramid}!rpx!rp

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 91 21:01:07 GMT
From:      C36735@TRMETU.BITNET
To:        comp.protocols.tcp-ip
Subject:   interconnections of ethernet network to another systems

WE HAVE THE FOLLOWING WORKSTATION AND THE MAINFRAME :

- ONE CYBER 932 MAINFRAME
- SIX CYBER 910/400 WORKSTATION
- THREE HP APOLLO DN4500 WORKSTATION
- ONE HP 9000 MODEL 319C SYSTEM
- ONE IBM 6150 RT MODEL 25 SYSTEM

THERE ARE IEEE 802.3 NETWORK AND APOLLO TOKEN RING NETWORK:
ETHERNET NETWORK CONSISTS OF ONE CYBER 932 MAINFRAME AND SIX CYBER 910
WORKSTATIONS. APOLLO TOKEN RING NETWORK IS CONSISTING OF THREE HP APOLLO
WORKSTATIONS. TCP/IP SOFTWARE IS RUNNING ON THE ALL OF THE WORKSTATIONS
AND THE CYBER 932 MAINFRAME.

WE WANT TO CONNECT APOLLO TOKEN RING NETWORK, IBM RT PC SYSTEM , HP 9000
SYSTEM AND IBM 3090 TO THE ETHERNET NETWORK.

WHAT ARE THE ALTERNATIVE SOLUTIONS REGARDING INTERCONNECTIONS OF THE
THESE SYSTEMS?
WHAT WILL BE THE HARDWARE AND SOFTWARE CONFIGURATIONS.

I WILL BE GLAD IF YOU SEND ME THESE INFORMATIONS.

                                      HAYDAR SELBES
                                  METU CAD/CAM CENTER

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Jul 91 22:43:51 GMT
From:      cas@unislc.uucp (Charles Stephens)
To:        comp.protocols.tcp-ip
Subject:   Need GOSIP protocols - DNSP EGP BGP


Hello,

	I am trying to find source code for the following GOSIP
	compliant protocols:

		Domain Name Server - RFCs 882, 973, 974, 1035, and 1101

		Exterior Gateway Protocol - RFCs 888 and 904

		Border Gateway Protocol - RFC 1163

	Any leads, preferably (but not limited to) public-domain, will
	be greatly appreciated. I have all the RFCs.

							Thnx, CAS
--------------------------------------------------------------------
C. A. Stephens
		"Get in, get it done, get out."
						R. J. Ringer
-- 
-------------------------------------------------------------
C. A. Stephens
		"Get in, get it done, get out."
						R. J. Ringer

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 01:10:37 GMT
From:      emv@msen.com (Ed Vielmetti)
To:        comp.archives.admin,comp.protocols.tcp-ip
Subject:   long-term viability of comp.archives


Postings to comp.archives in July will be much less than "normal".
I'm taking a breather to work on the code, to try to get my filtering
to be less time-consuming, to take some time off, and to make sure
that there's an Internet connection available for my use.

If you are running an automated service that relies on comp.archives
data, be aware that it's going to not have the usual volume of inputs
for a while.  I'm going to try to get out a few every week.

The long-term viability of comp.archives depends on MSEN getting its
Internet connection approved and hooked up; some unwanted political
snags hit late last week and they're going to take some effort and
energy to put right.  (If necessary I will post the gory details,
don't you worry about that.)  If we're not on the net, then obviously
I can't provide the service to anyone (paying or gratis); my employer
(day job) is willing to have me spend some time watching the net for
useful stuff, but not to the extent that comp.archives entails.  

I did not expect these problems to come to a head so quickly, but as
it turns out I need to make sure that we can afford keep an Internet
connection at reasonable terms much more than I need to watch the net
for neat stuff.  

[Please forward to other lists as necessary.]
-- 
Edward Vielmetti, vice present for research, MSEN Inc. emv@msen.com

"With all of the attention and publicity focused on gigabit networks,
not much notice has been given to small and largely unfunded research
efforts which are studying innovative approaches for dealing with
technical issues within the constraints of economic science."  
							RFC 1216

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 02:54:34 GMT
From:      CASNER@ISI.EDU (Stephen Casner)
To:        comp.protocols.tcp-ip
Subject:   Re: Digital Voice Protocols

We are working on packet voice and packet video at ISI.  RFC 741
describes the first version of the Network Voice Protocol that was
ARPAnet-specific.  A second version, NVP-II, was defined in an
unpublished document written at ISI and dated April 1981.  That
document should have been made into an RFC but never was.  It is not
currently available on-line, but I can mail a paper copy to you if you
send your postal address.

NVP-II used ST-I (IEN 119) as an underlying protocol.  A multimedia
conferencing system built on those protocols is currently operating
over the TWBnet.  A new version of ST has recently been specified in
RFC 1190 and implemented by BBN in the SPARCstation.  Part of our
current work is to update NVP to correspond to the changes in ST-II
versus ST-I, also considering new ideas in how connection management
should be done.
						-- Steve Casner
						   Casner@ISI.EDU
-------

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 07:50:00 GMT
From:      ELESKG@NUSVM.BITNET (Winston)
To:        comp.protocols.tcp-ip
Subject:   RE: SETTING UP DOMAIN NAME SERVER

I have received quite a number of replies, all of which tells me that I
have phrased my question badly. I was actually looking for a list of
root servers, and that was what I received from a number of replies. I
wanted a most recent copy, and that was sent over the net just after I
put out the message. Anyway, many thanks to all who have replied.

Winston

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 09:39:51 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: Digital Voice Protocols

In <678423274.0.CASNER@ISI.EDU> CASNER@ISI.EDU (Stephen Casner) writes:

> A new version of ST has recently been specified in
> RFC 1190 and implemented by BBN in the SPARCstation.

Just FYI -- another implementation ST-2 is being done here as an experiment
at the Swedish Institute of Computer Science.

Craig Partridge
on sabbatical at SICS

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 10:04:41 GMT
From:      holdenm@grendel2.acc.stolaf.edu (Mark Holden)
To:        comp.protocols.tcp-ip
Subject:   Re: CMC (was Board Level Ethernet/TCP/IP Products)

In article <1991Jun30.214202.2558@kth.se> perand@admin.kth.se (Per Andersson) writes:
>In article <1991Jun10.201046.16912@sctc.com> smith@sctc.com (Rick Smith) writes:
>>CMC --
>>It was obvious from my mail that CMC is well known. I also got responses
>>from CMC employees on the Net. The general form of non-employee messages
>>was "We tried them two years ago, their protocol software was buggy, and
>>they didn't fix things very fast." I passed this perception along to
>>the guys at CMC. They said their software has vastly improved in the
>>past couple of years.......
>Anyone have actual experience with CMC boards in an Internetlike environment?
>Folks at work have started using CMC instead of Excelan board for some reason,
>and there are some strange problem with default router, arps and such going on,
>which wasn't a problem with the Excelan board? The router is Cisco btw.

	My CMC experience is limited to their TranServer Terminal Servers.
I found their hardware to be buggy, nad it tended to die occasionally for
inexplicaple reasons.  The product was diffucult to configure, cryptic,
and poorly documented.  Their support was almost non-existant, and in general
it seemed that they were jerking us around.  However, at the price, the units
worked well enough once we got them configured, only needing to be rebooted
occasionally.  Most of my dealings with these CMC products were ~6 months
ago, and since I'm no longer working at that job, for all I know, they've
set everything right and the machines work beautifully, but I doubt it.
Now don't get me wrong, I don't have it in for CMC, and I don't even hate that
product, but I *am* deeply frustrated with both.

						Mark Holden

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 11:08:38 GMT
From:      thomas@nexus.se
To:        comp.protocols.tcp-ip
Subject:   Re: STREAMS flow control in SunOS 4.1.1

In article <1991Jun28.090418.13395@odin.corp.sgi.com> hwajin@sgi.com (Hwa-jin Bae) writes:

Problem solved!
It was a known bug in SunOS and patch 100199-03, TLI Jumbo patch fixes
the problems.

The problem with a non-echoing pty0 was solved with patch 100106-02.
The problem was that when running x29 the pty would sometimes be left
with the xtty module pushed on the pty.

Thomas
--
Real life:      Thomas Tornblom             Email:  t_tornblom@nexus.se
Snail mail:     Communicator Nexus          Phone:  +46 18 171814
                Box 857                     Fax:    +46 18 696516
                S - 751 08 Uppsala, Sweden

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 12:10:29 GMT
From:      jamieson@synapse.bms.com (Stephen Jamieson)
To:        comp.protocols.tcp-ip
Subject:   vendor name for vendore code 00: 00:03

Does anyone know the vendor that owns this code ?


thanks in advance,

-steve
   ___                                      
   ] [ Stephen Jamieson / Network Engineer  
  / o \ Scientific Information Systems      
 /-o---\ Bristol-Myers Squibb Pharmaceutical Research Institute
 \___o_/  Internet: jamieson@bms.com / Phone: 609-921-5674
  

-- 
   ___                                      
   ] [ Stephen Jamieson / Network Engineer  
  / o \ Scientific Information Systems      
 /-o---\ Bristol-Myers Squibb Pharmaceutical Research Institute

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 13:54:10 GMT
From:      jcrowder@groupw.cns.vt.edu (Jeff Crowder)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk,comp.dcom.lans
Subject:   snmp for Macs


Can anyone recommend an SNMP monitor for an Apple environment?  We have
a user who wants to manage his soon-to-be-installed 10BaseT network
using one of his existing Macs.  Public domain would be preferable but
any pointers would be appreciated (marketing reps welcome).    

Thanks,		

Jeff Crowder
jcrowder@GroupW.cns.vt.edu

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 14:22:00 GMT
From:      rinehart@AEDC-VAX.AF.MIL ("Kathy Rinehart c60191 x3899")
To:        comp.protocols.tcp-ip
Subject:   Owner of TCP/IP trademark

Hi, netlanders!

	I just received an AT&T publication (newsletter, actually) for a 
particular government contract with AT&T.  Under the trademark identification 
section, TCP/IP was identified as "a registered trademark of The Wollongong 
Group".  It also stated "UNIX is a registered trademark of UNIX System 
Laboratories, Inc."  

	The identification of TCP/IP as a registered trademark of TWG is very 
new to me.  This is the first time, in fact, that I can recall seeing TCP/IP 
identified as a registered trademark.  I am new enough to networking to realize 
that there is a lot that I don't know.  Would someone be willing to send me a 
short note verifiying this statement, and how TWG became the registered owner? 
This point is one of curiosity with me, and while I would not have thought that 
UNIX was a trademark of UNIX System Laboratories (I would have expected AT&T to 
have that one), I am really interested in the history of TCP/IP as a trademark.

	Thank you to whoever reads this note, and a special thank you to anyone 
who is willing to indulge my curiousity and catch me up to date.

						Kathy Rinehart
						Rinehart@AEDC-VAX.AF.MIL

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 14:59:08 GMT
From:      cas@unislc.uucp (Charles Stephens)
To:        comp.protocols.tcp-ip
Subject:   Correction, not GOSIP


Hello,

	I have been roundly chastised for referencing DNS, EGP, and BGP
	as "GOSIP compliant protocols". Please accept my apologies.

	I am still looking for leads to source code for the three
	protocols. (Are they called "Internet Protocols", "DARPA
	Protocols", what???)

			Thnx for your patience, CAS
-- 
-------------------------------------------------------------
C. A. Stephens

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 18:50:19 GMT
From:      dricejb@drilex.UUCP (Craig Jackson drilex1)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Is there a PC or NLM RARP server?

We're thinking of getting into Novell's LAN Workplace for DOS
in a big way.  I'd like to avoid putting config info on each
workstation.  LWP does not support BOOTP, but it does support RARP.
Unfortunately, the projected configuration doesn't have any
RARP-capable machines on the PC subnets--just PCs, a Netware 
3.11 server, and a cisco router.

Does anyone have an RARP server which can live in a PC, or even
better can run as an NLM?  I know one shouldn't be too hard to write,
especially for the PC, but it would be even easier to find one.

Thanks.

-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 19:04:51 GMT
From:      krenz@pql840.WEC.COM (RandyKrenz)
To:        comp.protocols.tcp-ip
Subject:   Subnetting/Subnet Masks

Hello NetLanders,

I'm sure this topic has been discussed many times, so hopefully once more
won't hurt. If anyone has some horror stories or success stories with
regard to subnetting, I would like to here from you. I have a handle on
the basics of how it works, I am more interested in practical "rules", 
what people really implement, caveots, etc. Of particular interest to me is
the use of different subnet masks for different subnets. In the interest
of bandwidth, please respond to me directly and I will post a summary if
warranted.
                                                              Thanx
/***************************************************************************/
/* Randolph A. Krenz                                 \W\               /W/ */
/* Senior Engineer - Computer/Facility Operations     \W\             /W/  */
/* Westinghouse Electronic Systems Group               \W\     ^     /W/   */
/* Product Qualification Laboratory                     \W\   /W\   /W/    */
/* P.O. Box 746, M.S. 504, Baltimore, Md, 21203          \W\ /W W\ /W/     */
/* WEC WIN: 285-6232 / AT&T: (301)765-6232                \W W/ \W W/      */
/* Internet: krenz@pql840.bwi.wec.com                      \W/   \W/       */
/***************************************************************************/

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 19:24:50 GMT
From:      fmill@cactus.org (Frederick Milling)
To:        comp.windows.ms,comp.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Ftp, Tcp/Ip

If anyone can help me I'd greatly appreciate it.  Can someone provide for me
the names of vendors that make a version of tcp-ip (that includes ftp and
telnet) for dos and windows.  I'd also would like to know if there is a
shareware version of it, and where can I find it.
   
                                             Sincerely,
                                             Fred Milling
                                             fmill@cactus.org

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 20:35:23 GMT
From:      swm@unccvax.uncc.edu (Swami Manohar)
To:        comp.protocols.tcp-ip
Subject:   SLIP for Xenix



Hi:
	I am not sure if this is the right news group fo rthe 
following question. Please point meto the right group if necessary.

Question:
	Is there a public domain SLIP (Serial line internet protocol) available
for PCs that run Xenix? Please point me to a ftp site
that carries it.( I know that SLIP for SunOS is 
available through anonymous ftp (ai.toronto.edu, riacs.edu))

Thanks very much

Swami Manohar	                        Email: swm@unccvax.uncc.edu 
Computer Science Department             Phone:    704-547-4833
University of North Carolina
Charlotte, NC 28223

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 21:55:54 GMT
From:      raj@ms.uky.edu (Raj Yavatkar)
To:        news.announce.conferences,comp.protocols.tcp-ip
Subject:   Workshop on Multimedia


CALL FOR PAPERS


1992 Workshop on Multimedia Information Systems (MMIS'92)

February 7-8, 1992

Phoenix, Arizona, U.S.A.


Sponsored by:  Arizona State University, Syracuse University, and University of Kentucky


 Integration of computer, communication, and media is revolutionizing information processing and management
technology. A large number of applications require ability to combine audio, video, text, and graphics. This
workshop will deal with the technical issues pertaining to the design, implementation, and application of
multimedia systems. It will be held in conjunction with the 1992 Data Engineering Conference. The topics of
interest include but are not limited to


%  Multimedia Database Systems		%  Sensor Data Management

%  Multimedia Data Model		%  Application Specific Systems

%  Networking for Multimedia Data	%  User Interface

%  Multimedia Software Tools		%  Spatial and Temporal Data Management

%  Distributed Multimedia Systems	%  Mixed Media Synchronization

		%  Future Applications and Requirements


Instructions for Submitting Manuscripts:


Manuscripts must not exceed 25 double-spaced typed pages. Papers must not have been previously published or
currently submitted for publication elsewhere. Manuscripts should include a cover page with a title, each author's
name, affiliation, address, and telephone number, as well as the keywords that identify the central issues of the
manuscript's content. The second page of the draft should contain only the title and an abstract of about 200
words. Send submissions and questions to the Program Chair.


Deadlines:

	%  Four copies of the full manuscript are due by August 16, 1991

	%  Authors will be notified of acceptance by November 1, 1991

	%  Camera ready copy of the manuscript is due by December 1, 1991


Contributing authors are encouraged to submit their work for consideration for publication in a special section on
Multimedia Systems in the IEEE Transactions on Knowledge and Data Engineering.


Organizing Committee:


P. Bruce Berra (General Chair), Department of Electrical and Computer Engineering, Syracuse University,
Syracuse, NY 13244. Tel: (315)-443-4445. Email: berra@cat.syr.edu

Rajiv Mehrotra (Program Chair), Department of Computer Science, University of Kentucky Lexington, KY
40506. Tel: (606)-257-6262 (x215). Email: rajiv@ms.uky.edu

Benjamin Tang (Local Arrangement Chair), Department of Computer Science and Engineering, Arizona
State University, Tempe, AZ 85287. Tel: (602)-965-4155. Email: btang@enuxva.eas.asu.edu

Susan D. Urban (Treasurer), Department of Computer Science and Engineering, Arizona State University,
Tempe, AZ 85287. Tel: (602)-965-2784. Email: urban@asuvax.eas.asu.edu


Program Committee:


S. Christodoulakis, Technical University of Crete, Greece
J. R. Cox, Jr., Washington University, U.S.A.
C. Y. Roger Chen, Syracuse University, U.S.A
D. Davcev, University of Kiril and Metodij,  Yugoslavia
P. Dewan, Purdue University, U.S.A
C. Faloutsos, University of Maryland, U.S.A
A. Ghafoor, Purdue University, U.S.A.
F. Golshani, Arizona State University, U.S.A
W. I. Grosky, Wayne State University, U.S.A
R. Jain, University of Michigan, U.S.A
T. Kato, ETL, Japan
O. Liu-Sheng, University of Arizona, U.S.A
K. Y. Whang, KAIST, Korea
R. Yavatkar, University of Kentucky, U.S.A
R. Popescu-Zeletin, GMD-Fokus, Germany

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 22:19:09 GMT
From:      coates@uc780.umd.edu
To:        comp.windows.ms,comp.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   RE: Ftp, Tcp/Ip

In a previous article, coates@UC780.UMD.EDU wrote:
>In article <7900@cactus.org>, fmill@cactus.org (Frederick Milling) writes:
>>If anyone can help me I'd greatly appreciate it.  Can someone provide for me
>>the names of vendors that make a version of tcp-ip (that includes ftp and
>>telnet) for dos and windows.  I'd also would like to know if there is a
>>shareware version of it, and where can I find it.
>>   
>>                                             Sincerely,
>>                                             Fred Milling
>>                                             fmill@cactus.org
> 
>Many dos pc's use ftp's pc/tcp. They have an ftp server at ftp.vax.com.


Sorry, I transposed elements of the domain name. ftp's ftp server is:
vax.ftp.com

**************************************************************************
*                     Elliott Coates, washington dc                      *
*                         coates@uc780.umd.edu                           *
*                             coates@uc780.bitnet                        *
**************************************************************************

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 22:47:53 GMT
From:      cmilono@netcom.COM (Carlo Milono)
To:        comp.protocols.ibm,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   5251 Emulator over TCP


I am in need of a 5250/5251 emulator that will be able to access an
AS/400 via 802.3 TCP/IP.  Since IBM now supports TCP/IP on nearly every
one of their boxes, there are opportunities to squash the god-awful
twin-axial wiring that went to these antique machines (the 5251's).  

Unfortunately, tn3270 works, but the screens are formatted for 5251 and
much of the functionality vanishes - the application *must* stay (sigh!).

I would prefer a solution that uses packet-drivers and/or NDIS, and optionally
one that works under Windows 3.0...oh, and one more thing...cheap!



-- 
+--------------------------------------------------------------------------+
|                   Carlo Milono                                           |
|    Personal:    cmilono@netcom.com   or   apple!netcom!cmilono           |
| Hobbes: "Life in the Great Suburban Outback is certainly fraught with    |
|          peril."                                                         |
| Calvin: "If you'd seen it, you'd have been scared too."                  |
+--------------------------------------------------------------------------+

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 23:09:56 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Owner of TCP/IP trademark

In article <9107022002.AA21520@ucbvax.Berkeley.EDU> rinehart@AEDC-VAX.AF.MIL ("Kathy Rinehart c60191 x3899") writes:
>	I just received an AT&T publication (newsletter, actually) for a 
>particular government contract with AT&T.  Under the trademark identification 
>section, TCP/IP was identified as "a registered trademark of The Wollongong 
>Group".  It also stated "UNIX is a registered trademark of UNIX System 
>Laboratories, Inc."  

WIN/TCP is a trademark of Wollongong.  TCP/IP isn't a trademark of
anybody, nor do I think you could trademark it at this point.  Unix is
a well known footnote of AT&T :-) Actually, Unix is a trademark of
AT&T, but I think that it may be assigned to USL these days.  I think
that the publication was in error.

Warner
-- 
Warner Losh		imp@Solbourne.COM
But it was our hill.  And they were our beans.

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Jul 91 23:43:26 GMT
From:      emv@msen.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services

In article <1991Jun30.195156.22690@cs.mcgill.ca> peterd@cs.mcgill.ca (Peter Deutsch) writes:

   For the record, I'm one of the guys behind the archie
   project and I'm rather disappointed both at how hard it
   was for me to get that idea off the ground, and how little
   other development I see being funded, even now.

The funding is all going at X.500 projects (FOX), as instigated by the
NSF.  Anything using any other technology is summarily ignored.  Make
an archie-to-X.500 gateway and you'll get funding.  It doesn't matter
if you have anything interesting to put into the database, that's not
what NSF is funding; just the technology.  It doesn't matter if X.500
is the right solution to the problem, or whether it's a sensible
infrastructure to put the results into, just be sure that you conform.

The smaller amount of work being done on library-science type
protocols (Z39.50) is being done as commericial projects or for the
sake of doing it, a la WAIS.  

   To be fair, we are now getting a lot of interest from
   people who'd like archie source, or who are taking steps
   to see archie doesn't disappear by offering additional
   servers, but I don't see an atmosphere of encouraging such
   ideas at the seed stage with concrete support.

Concrete support is lacking on all fronts.  For instance, go into any
U.S. city with an NSFNET NSS and try as a small business to get
Internet access.  You'll find it somewhere between very expensive and
impossible in all but a few cases.  Try then to get a small business
on the net that actually provides services over the net and sells
those services to paying customers on the net, and you'll find it even
more difficult.  There are vested interests which do not want the net
to be accessable at low cost, that do not want to see innovation
(unless they are being funded to do that work), and that abhor
competition.   "Conspiracy in restraint of trade" is the phrase that
naturally comes to mind.

   Judging from Ed Vielemetti's previous posting about the
   troubles they're having keeping comp.archives going there
   is just not that much being spent on building the tools to
   make use of those T3 links you Americans are blessed with,
   even when there are demonstrated results. 

Peter, the thing to do (if you can pull it off) is to shut down all of
the archie servers in the world down cold solid for a month, so that
when people try to access them they get a nice note saying that it's
traditional in (Quebec, Finland, Australia) to take the month of July
off for vacation, and if any of you folks on US Government funded
networks want to get access, you'll have to provide it on your own
net with your own resources.  

The production of interesting services on the Internet seems to be
inversely proportional with bandwidth and funding.  

-- 
Edward Vielmetti, v.p. research, MSEN Inc. 	 	emv@msen.com

"often those with the power to appoint will be on one side of a
controversial issue and find it convenient to use their opponent's
momentary stridency as a pretext to squelch them"

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 00:12:05 GMT
From:      coates@UC780.UMD.EDU
To:        comp.windows.ms,comp.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: Ftp, Tcp/Ip

In article <7900@cactus.org>, fmill@cactus.org (Frederick Milling) writes:
>If anyone can help me I'd greatly appreciate it.  Can someone provide for me
>the names of vendors that make a version of tcp-ip (that includes ftp and
>telnet) for dos and windows.  I'd also would like to know if there is a
>shareware version of it, and where can I find it.
>   
>                                             Sincerely,
>                                             Fred Milling
>                                             fmill@cactus.org

Many dos pc's use ftp's pc/tcp. They have an ftp server at ftp.vax.com.

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 00:50:27 GMT
From:      jet@karazm.math.uh.edu (J Eric Townsend)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services

In article <EMV.91Jul2194321@bronte.aa.ox.com> emv@msen.com (Ed Vielmetti) writes:
>Concrete support is lacking on all fronts.  For instance, go into any
>U.S. city with an NSFNET NSS and try as a small business to get
>Internet access.  You'll find it somewhere between very expensive and
>impossible in all but a few cases.  Try then to get a small business

Call up AlterNet or PSInet.  Hell, I can almost afford a 9600 AlterNet
link for *personal* use.

--
J. Eric Townsend - jet@uh.edu - bitnet: jet@UHOU - vox: (713) 749-2126
Systems Wrangler, University of Houston Department of Mathematics
Skate UNIX! (curb fault: skater dumped)
PowerGlove mailing list: glove-list-request@karazm.math.uh.edu

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 03:01:28 GMT
From:      bcn@june.cs.washington.edu (Clifford Neuman)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services (Archie,Prospero)

In article <72mla6+@rpi.edu> rodney@sun.ipl.rpi.edu (Rodney Peck II) writes:

   Has there been any discussion about setting up a behind-the-scenes load
   balancing system where I could volunteer a certain number of searches per
   hour from my machine and others could do the same?  That would let more of
   us get involved without trying to drink from the firehose.

This can be done using the client/server (i.e. Prospero) interface to
Archie.  The Prospero server only handles a single request at a time.
If the server is busy, additional requests are queued and handled in
the order received.  This has several benefits, one of which is that it
reduces the load on your machine.  To some extent, I believe it can
also improve the throughput (number of requests per hour) over the
case where one has 25 Archie logins all fighting for the same
resources.

There are also benefits to the Archie user of using the Archie client
instead of logging in to the Archie server.  For one, it seems to be
significantly faster, even when the Archie server is heavily loaded.
I am not sure exactly why this is, but part of the reason may be
because I pared away much of the Archie code which was only needed for
the user interface.  For example, all sorting is done by the client,
not by the server.

The potential drawback is queuing delays.  I have not found this to be
a problem yet, but part of the reason is that most people still log in
to the Archie server, and few use the client.  However, if the number
of direct logins to the Archie server was kept low, the load would be
light, and the service time would be short.

With some very minor modifications, the Prospero interface to Archie
could also be made to support load balancing (though for the time
being, I don't even think this is necessary).  All Prospero clients
(including the Archie client) already accept forwarding pointers.  If
upon receiving a request, the server decided that it's queue was too
long, it could return a forwarding pointer telling the client to try
another server.  The clients already know how to react.

What I described above are the advantages of using the Archie client
to access Archie.  Prospero also allows users to access Archie as if
it were part of a file system.  I don't think I sufficiently explained
how to do this in my original announcement.  At the end of this
message I am including an example showing it in action.

	~ Cliff
---
  Script started on Mon Jul  1 22:36:42 1991
  % source /home/ftp/archie/pfs/bin/vfsetup.source
  % vfsetup guest
  % venable
  % cd /archive-sites/archie/regex
  % cd prospero (This command specifies the query)
  % ls          (This command executes it)
  total 0
  -r--r--r--   0 -               0 -            info-prospero.arc
  dr-xr-xr-x   0 -               0 -            prospero
  dr-xr-xr-x   0 -               0 -            prospero-papers
  -r--r--r--   0 -               0 -            prospero.arc
  -r--r--r--   0 -               0 -            prospero.tar.Z
  (Note that the "vls" command could have been used)
  (to show where the files were actually stored    )
  % unalias ls (the account aliases it to ls -l)
  % ls prospero (list a result if it is a directory)
  prog.tar.Z      prospero.tar.Z
  % cat info-prospero.arc  (The file is automatically retrieved and displayed)
  >From bcn@n1dmm  Tue Dec  4 02:33:36 1990
  Received: from n1dmm.cs.washington.edu by june.cs.washington.edu (5.64/7.0jh)
          id AA24763; Tue, 4 Dec 90 02:33:36 -0800
  Received: by n1dmm.cs.washington.edu (5.64/7.0h)
          id AA08497; Tue, 4 Dec 90 02:33:31 -0800
  Date: Tue, 4 Dec 90 02:33:31 -0800
  From: bcn@cs.washington.edu (Clifford Neuman)
  ...
% vdisable
% exit
script done on Mon Jul  1 22:39:33 1991

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 03:09:00 GMT
From:      peterd@cs.mcgill.ca (Peter Deutsch)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services

In article <EMV.91Jul2194321@bronte.aa.ox.com> emv@msen.com (Ed Vielmetti) writes:
>In article <1991Jun30.195156.22690@cs.mcgill.ca> peterd@cs.mcgill.ca (Peter Deutsch) writes:
 .  .  .
>
>   Judging from Ed Vielemetti's previous posting about the
>   troubles they're having keeping comp.archives going there
>   is just not that much being spent on building the tools to
>   make use of those T3 links you Americans are blessed with,
>   even when there are demonstrated results. 
>
>Peter, the thing to do (if you can pull it off) is to shut down all of
>the archie servers in the world down cold solid for a month, so that
>when people try to access them they get a nice note saying that it's
>traditional in (Quebec, Finland, Australia) to take the month of July
>off for vacation, and if any of you folks on US Government funded
>networks want to get access, you'll have to provide it on your own
>net with your own resources.  

Sigh, sadly this is still doable if we were so inclined as
there are actually currently only two in production
operation (ours and the one in Australia). Finland is
still testing (at least I never saw an announcement of
general availability) and none of the US sites are up yet.

Heck, even if we ONLY shut down ours imagine what people
would have to say about what we did to the poor 'ole link
to Oz. But what about all those people who don't know about
which site it is in Oz? Sorry, I can't contemplate getting
1,500 angry letters a day for a month. It's bad enough
that we actually get flames about the quality of our user
interface!

Seriously, I am really glad to be able to provide the
current service, but I'd feel happier if we had some
permanent mechanism for paying people who provide useful
tools for their efforts. This would ensure that others who
wish to do this kind of stuff can do try and do so and
still pay the mortgage and feed the kids. My own formula
is funding from the operators, but hey, I'll take anyone's
money right now...

I am really glad that we have Internet volunteers to
provide such services as we have now, but can we seriously
expect to keep the net growing at the current rate and
still rely on volunteers for our tools? All those graphs
the LSFnet people put out keep showing number of connected
machines, packets, bytes, anything you want growing at
what looks like exponential rates. I just don't see it
continuing (Yeah, I know - Imminent death of Usenet
predicted... :-)

>The production of interesting services on the Internet seems to be
>inversely proportional with bandwidth and funding.  

Well, there may be some truth to this. At the School of
Computer Science at McGill we started out with a 9600 baud
link to the States and zero funding for it except when I
could bully a few people, such as our local Computing
Centre, into renting access (now my employer. tee hee). We
now scream along with a pair of 56k baud circuits paid for
by our regional, and saturated by archie (I was told by the
NOC people in Toronto that they estimate that as much as 40
percent of the Montreal-US link traffic is archie
related!). And still they refuse to pay for it, at least
not yet.... :-)

Well, I guess we should count ourselves lucky they don't
ask us to shut down because we're too successful!


				- peterd


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

Zen Master to hot dog vendor:  "Make me one with everything."

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

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 03:33:51 GMT
From:      rodney@sun.ipl.rpi.edu (Rodney Peck II)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services

In article <EMV.91Jul2194321@bronte.aa.ox.com> emv@msen.com (Ed Vielmetti) writes:
>Peter, the thing to do (if you can pull it off) is to shut down all of
>the archie servers in the world down cold solid for a month, so that
>when people try to access them they get a nice note saying that it's
>traditional in (Quebec, Finland, Australia) to take the month of July
>off for vacation, and if any of you folks on US Government funded
>networks want to get access, you'll have to provide it on your own
>net with your own resources.  

I've considered setting up an archie server here, but I definitely cannot
handle the load that would result.  Naturally, there should be some sort of
regional support for such a machine.  I suppose that's what the discussion
and annoyance is all about.

Has there been any discussion about setting up a behind-the-scenes load
balancing system where I could volunteer a certain number of searches per
hour from my machine and others could do the same?  That would let more of
us get involved without trying to drink from the firehose.

-- 
Rodney

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 03:39:54 GMT
From:      pte900@jatz.aarnet.edu.au (Peter Elford)
To:        comp.protocols.tcp-ip,comp.archives.admin
Subject:   Re: On the need to develop Internet user services

In article <1991Jun30.083257.17896@cs.mcgill.ca>, peterd@cs.mcgill.ca (Peter Deutsch) writes:
|> 
|> ... This posting touches a raw nerve with me
|> as I think we (the Internet community) have been rather
|> slow at seeing the real potential of what we have created,
|> or at least in communicating that potential and
|> translating it into tools for our naive or first-time
|> users.

I could not help but notice that this posting (at least on my
system) immediately followed a posting from Ed Vielmetti with 
the following signature;

"With all of the attention and publicity focused on gigabit networks,
not much notice has been given to small and largely unfunded research
efforts which are studying innovative approaches for dealing with
technical issues within the constraints of economic science."
                                                        RFC 1216

Which captures the essence of your posting ...

|> How many _new_ network-based tools have we seen in the
|> past two years? In the past five? How accessible is the
|> Internet for people who just want information or services,
|> without a crash-course in the UNIX sub-culture or an
|> update on networking research? How many _user level_
|> documents do you have on the Internet in your user
|> library? You _do_ have a user library at your site,
|> don't you?
|> 
|> For the record, I'm one of the guys behind the archie
|> project and I'm rather disappointed both at how hard it
|> was for me to get that idea off the ground, and how little
|> other development I see being funded, even now. From what I
|> see there's just not much money being spent on developing
|> new or existing services by the people funding the
|> networks. I find this strange when you think how much is
|> being spent on the network infrastructure as a whole.

The Australian Academic and Research Network (AARNet) is funding
a project to address exactly these issues. A single, large
system will be acquired to support the mirroring and caching
of heavily used archives, initially using scripts and ftp, but
(hopefully) later on Prospero. The Australian archie service
(which currently operates out of Deakin University) will be
hosted on this server, as will a finger server developed by
the University of Sydney. WAIS server software is also likely
to be installed.  

This will mean that end-users within the AARNet community will
have a single point of access for the retrieval of information
form the Internet. If the AARNet archive server does not have an
item on-line (as result of mirroring or caching) then services 
like archie will enable it to be located (and retrieved).

Although a single server does not scale well, as suggested by
Peter Deutsch, this is something that a regional network can do
[ mind you, uunet.uu.net does closely approach the single server
concept ].

|> ...
|>
|> And maybe things are worse in Canada, where our tightly
|> regulated carriers sock us with huge line charges that
|> make up a large portion of our yearly networking bill.
|> Thus, when I approached our national and most of our
|> regional organizations for help I was told that there was
|> just no money nor any interest in funding services such as
|> archie (one or two had interest, but no money :-(

It's not a case or worse in Canada, but a case of it being
worse *outside the US*. Just about every non-US member network
of the Internet is faced with higher communications charges
than those in the US (including very expensive international
circuits). This is leads to some interesting attitudes ...

|> ...
|> 
|> I don't know of many other people being funded to build
|> such tools, even now, and I know of fewer in the position
|> of being able to say "okay, let's go for it" when it comes
|> time to implement a good idea. I'm no longer even in that
|> position myself, since I've changed jobs (taking Alan with
|> me, BTW) and our new boss doesn't think we should be
|> working on archie, either...

We (the AARNet archive working group) hope that the work we
put into installing our "information server" can be passed
back to the Internet community in the form of enhancements
to (eg) archie, Prospero - if there are other projects that
need work, then lets hear about them and maybe some of our
funding can be spent twice; once to improve services to the
AARNet, and again when that code is reused elsewhere (this is
nothing new).

|> Judging from Ed Vielemetti's previous posting about the
|> troubles they're having keeping comp.archives going there
|> is just not that much being spent on building the tools to
|> make use of those T3 links you Americans are blessed with,
|> even when there are demonstrated results. I have this
|> recurring nightmare of people using the upcoming Gigabit
|> networks to flood my mailbox with larger and larger pieces
|> of email, while other people ftp ever-larger collections
|> of racy GIFFs and sound files. Meanwhile, Usenet will pass
|> a Gigabyte a day of flames and quoted repostings. Now I
|> looked at those GIFFs too, but is that why we're doing all this?

.... this is my point from above. There seems to be a mentality
that says; "This is link is congested; we better upgrade it",
rather than "This is link is congested; let's address the
reasons why it's congested". Sure, it may be that there is
too much useful work being over a single link and an upgrade
is demanded, but in many other cases avoiding duplication of
file transfer requests or getting users to access local servers
will go a long way to prolonging the life of the existing circuit.

The Internet can become a friendlier, more useful, more efficient
facility for a larger community of users by spending more resources
on doing things smarter, and on tools that address end-user requirements.

|> The fact is there are not all that many user-level
|> Internet services or tools and knowledge of what is there
|> basically spreads by word of mouth like the secret
|> incantations of some ancient tribal cult. I think the time
|> has come for organizations (such as the regional networks
|> or whoever is responsible for your piece of the net) to
|> start funding some real development of user support
|> documentation and services.  Not just tools, but user docs
|> and friendlier front-ends to existing tools, as well.

I agree. AARNet funded a project to support a User Guide last
year, and is funding the archive project and will produce a Handbook
this year.

|> ...
|> 
|> I would love to see each and every person coming onto the
|> net receive a "welcome package" of basic tutorials, plus
|> single sheet cards on the standard user tools (including a
|> general guide to the net, email, news, file sharing, ftp
|> and whatever follow-on to archie we can put together, plus
|> info on the work of people like Ed Vielemetti of
|> comp.archives, the Prospero and WAIS work, accessing your
|> local library catalogues, and so on).

This stuff *must* come from the regional networks. Local 
variations about where the nearest servers are, details on
local libraries, phone numbers, site contacts can not be
developed centrally.

|> The regional coordinators would make the frontend software
|> available to the local networks and info would be collated,
|> coordinated, and verified through them. The time is upon
|> us folks - a lot more people are coming onto the net, and
|> they are no longer being drawn from Engineering and Comp.
|> Sci.  They need help and we have to start getting it
|> together now.

The broader your user base, the better are your chances of
continued funding/support.

|> So what can we do? I've just started a mailing list here
|> at McGill of people in Canada interested in such work.
|> I've started putting useful documentation on our local
|> archive server, and I'm writing articles for our
|> newsletter. Of course we're still trying to develop archie
|> and I'm making a pain of myself to my regionals (and
|> anyone else who'll listen, as quite a few poor souls who
|> had to endure my ravings learned at both Usenix and the
|> Canadian Networking '91 conference the following week! :-)

Maybe this is something that should be taken up on the IETF
User Services mailing list (usac@ISI.EDU). Is your mailing list
private or can anyone join ?

|> ...
|>
|> And yes, for those who are wondering - we've given out the
|> source to archie to several US regional sites who have
|> agreed to run servers. So you wont have to keep getting
|> those "File table full" messages or find the service goes
|> away when the air conditioning fails in a machine room in
|> Quebec (as it did this weekend). It's already running in
|> Australia 

And it's well used.

|> and due to be announced in Europe. We hope to
|> see US sites any minute now.
 
|> Now we'd like to find the time to get the WAIS interface
|> grafted on so we can then get to work on the user-friendly
|> frontends and the more powerful query language everyone
|> keeps asking for. We'd also like to have some code to
|> automatically coordinate updates among the multiple
|> archies that are now running so archive managers don't get
|> hit with multiple listing searches. Several people have talked
|> about integrating comp.archives, archie and the ftp
|> archive sites so you could follow an original posting and
|> the thread discussing the posting, find the software and
|> be sure you've got the most recent version, all in one
|> tool. Hey, I'm game, but I'll need some time..
|>
|> Then we'd get started on the _real_ info server I'd like
|> to build, the one that treats all information as objects,
|> so you can query on attributes such as author, creation
|> date, subject, type, etc. Your front-end tools should know
|> about the info servers, and the info servers should know
|> about each other.

This is motherhood and apple pie; noone can argue the merit in
these enhancements.

|>...
|> 
|> Sorry for the polemic tone of this. I may be preaching to
|> the converted, and I know a lot of good people are doing
|> good work.  I just think it should be better supported and
|> integrated into the network support structure than it is.

I second the motion.

Peter Elford,                           	e-mail: P.Elford@aarnet.edu.au
Network Co-ordinator,	 			phone: +61 6 249 3542
Australian Academic Research Network,		fax:   +61 6 247 3425
c/o, Computer Services Centre,			pager: +61 6 245 3035
Australian National University			post:	PO Box 4     
Canberra, AUSTRALIA					Canberra 2601

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 05:45:34 GMT
From:      peterd@cs.mcgill.ca (Peter Deutsch)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services

In article <72mla6+@rpi.edu> rodney@sun.ipl.rpi.edu (Rodney Peck II) writes:
.  .  .
>I've considered setting up an archie server here, but I definitely cannot
>handle the load that would result.  Naturally, there should be some sort of
>regional support for such a machine.  I suppose that's what the discussion
>and annoyance is all about.
>
>Has there been any discussion about setting up a behind-the-scenes load
>balancing system where I could volunteer a certain number of searches per
>hour from my machine and others could do the same?  That would let more of
>us get involved without trying to drink from the firehose.

The problem is still one of resources. Finding the time to
set this up, program it, test it and make sure it's
reliable is the same as paying for it. If Ed Vielemetti
does that that's something else he is not doing for
himself or his employer. If Alan Emtage does it, that's
something else he's not doing for me (and after all, my
boss is paying Alan and I to run UNIX machines. Archie is
only peripherally associated with this.)


			- peterd



--------------------------------------------------------------------------
+-------+ 	Peter Deutsch		McGill University
| u # u |	peterd@cs.mcgill.ca	School of Computer Science
|/\/\/\/|	
|  a a  |	"From MAILER-DAEMON@hq.demos.su Thu Sep 13 00:45:55 MSD 1990"
 \  a  /	
  \___/         The day we made contact....
--------------------------------------------------------------------------

Look! I can type after the signature!

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 06:15:22 GMT
From:      peterd@cs.mcgill.ca (Peter Deutsch)
To:        comp.protocols.tcp-ip,comp.archives.admin
Subject:   Re: On the need to develop Internet user services

In article <1991Jul3.033954.10823@newshost.anu.edu.au> P.Elford@aarnet.edu.au writes:
>In article <1991Jun30.083257.17896@cs.mcgill.ca>, peterd@cs.mcgill.ca (Peter Deutsch) writes:
 .  .  .
>I could not help but notice that this posting (at least on my
>system) immediately followed a posting from Ed Vielmetti with 
>the following signature;
>
>"With all of the attention and publicity focused on gigabit networks,
>not much notice has been given to small and largely unfunded research
>efforts which are studying innovative approaches for dealing with
>technical issues within the constraints of economic science."
>                                                        RFC 1216
>
>Which captures the essence of your posting ...

Well, Ed and I are in many ways in the same boat. We're
both trying to offer a useful service without any visable
means of support (what was the nickname of the B-26? "The
Flying Prostitute"? because its wings were so small, for
those that didn't hear the story. Or was it the B-25, ah
you get the point...)

.  .  .
>The Australian Academic and Research Network (AARNet) is funding
>a project to address exactly these issues. A single, large
>system will be acquired to support the mirroring and caching
>of heavily used archives, initially using scripts and ftp, but
>(hopefully) later on Prospero. The Australian archie service
>(which currently operates out of Deakin University) will be
>hosted on this server, as will a finger server developed by
>the University of Sydney. WAIS server software is also likely
>to be installed.  

God, maybe I should move back to Oz!!! Alan and I will
start packing tomorrow!  Ooops, your sig has you in
Canberra. Hmmm... :-)

(I was a Melbourne lad when I lived in Oz...)

>
>This will mean that end-users within the AARNet community will
>have a single point of access for the retrieval of information
>form the Internet. If the AARNet archive server does not have an
>item on-line (as result of mirroring or caching) then services 
>like archie will enable it to be located (and retrieved).
>
>Although a single server does not scale well, as suggested by
>Peter Deutsch, this is something that a regional network can do
>[ mind you, uunet.uu.net does closely approach the single server
>concept ].

I absolutely approve of your efforts, although I would add
the obvious caution that no one group can hope to identify
and operate all needed services. There's also the issue of
"combat reliability". If you have your services
distributed to multiple sites, you can loose one and not
paralyze your network. Of course, a single server is an
order of magnitude better than none...

>|> And maybe things are worse in Canada, where our tightly
>|> regulated carriers sock us with huge line charges that
>|> make up a large portion of our yearly networking bill.
>|> Thus, when I approached our national and most of our
>|> regional organizations for help I was told that there was
>|> just no money nor any interest in funding services such as
>|> archie (one or two had interest, but no money :-(
>
>It's not a case or worse in Canada, but a case of it being
>worse *outside the US*. Just about every non-US member network
>of the Internet is faced with higher communications charges
>than those in the US (including very expensive international
>circuits). This is leads to some interesting attitudes ...

Yes, but at least in your example the regional (or
national) network is willing to invest in services. I wish
the rest of us would follow your example...
.  .  .
>|> .  .  .  .  . I have this
>|> recurring nightmare of people using the upcoming Gigabit
>|> networks to flood my mailbox with larger and larger pieces
>|> of email, while other people ftp ever-larger collections
>|> of racy GIFFs and sound files. Meanwhile, Usenet will pass
>|> a Gigabyte a day of flames and quoted repostings. Now I
>|> looked at those GIFFs too, but is that why we're doing all this?
>
>.... this is my point from above. There seems to be a mentality
>that says; "This is link is congested; we better upgrade it",
>rather than "This is link is congested; let's address the
>reasons why it's congested". Sure, it may be that there is
>too much useful work being over a single link and an upgrade
>is demanded, but in many other cases avoiding duplication of
>file transfer requests or getting users to access local servers
>will go a long way to prolonging the life of the existing circuit.
>
>The Internet can become a friendlier, more useful, more efficient
>facility for a larger community of users by spending more resources
>on doing things smarter, and on tools that address end-user requirements.

But when even the time to study the problem is borrowed
from other tasks, you've got a problem. As far as I know
there is not one person in Canada charged with providing
Internet-wide user services as their primary job and not
many in the States, either (and those seem to be people at
NSFnet writing basic documentation. Exceptions anyone?).

Currently, it looks to be 99.9 percent volunteers.

>|> ...
>|> 
>|> I would love to see each and every person coming onto the
>|> net receive a "welcome package" of basic tutorials, plus
 .  .  .
>This stuff *must* come from the regional networks. Local 
>variations about where the nearest servers are, details on
>local libraries, phone numbers, site contacts can not be
>developed centrally.

I agree. Sigh, anybody else working on this?

.  .  .
>|> So what can we do? I've just started a mailing list here
>|> at McGill of people in Canada interested in such work.
 .  .  .
>Maybe this is something that should be taken up on the IETF
>User Services mailing list (usac@ISI.EDU). Is your mailing list
>private or can anyone join ?

"Mine" is as public as I can make it. It's called
"user-services@cc.mcgill.ca" and is now up to about a dozen
people in Canada and the US. The more the merrier, if
you're interested in this subject. I've added the first
posting (which tried to outline the list's mandate) and my
original in this thread to the user-services subdirectory
on "archives.cc.mcgill.ca [132.206.44.2]". Check it out
and drop me a note if you'd like to participate in this
list.

I wonder if the IETF one is open? I'll be sending them a
request, anyways.

>
>|> ...
>|>
>|> And yes, for those who are wondering - we've given out the
>|> source to archie to several US regional sites who have
>|> agreed to run servers. So you wont have to keep getting
>|> those "File table full" messages or find the service goes
>|> away when the air conditioning fails in a machine room in
>|> Quebec (as it did this weekend). It's already running in
>|> Australia 
>
>And it's well used.

So we've heard. I trust you're keeping count. We're
running at 1,500 on a good day! (I really hope that drops
when the others go operational. Poor quiche is also my
newsfeed and it's sloooow! :-)

.  .  .

[* my wish list deleted *]
>
>This is motherhood and apple pie; noone can argue the merit in
>these enhancements.

Well, and archie is a pretty obvious solution to a fairly
simple problem. Still, nobody's done much of the above
list yet, which sort of illustrates my original point, I'd
say.

>
>|>...
>|> 
>|> Sorry for the polemic tone of this. I may be preaching to
>|> the converted, and I know a lot of good people are doing
>|> good work.  I just think it should be better supported and
>|> integrated into the network support structure than it is.
>
>I second the motion.

Thanks. 

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 11:13:06 GMT
From:      dln@crosfield.co.uk (#dave norman)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Sources - summary


TCP/IP Sources - LONG !
--------------

Sometime ago I posted :
>
>We need to implement TCP/IP inside an embedded system
>running VRTX based on AMD 29000's - Gulp !.
>
>
>Has anybody heard of a TCP/IP implementation running under VRTX ?
>if so, where can I obtain the sources ?
>
>Alternatively can anyone please direct me as to where I can get
>the source code for a portable implementation of TCP/IP, so we can
>do the job ourselves.
>
>Any other tips or hints would be greatly appreciated.
>
>| Dave Norman                            | Phone :  +44 442 230000 ext 3354 |
>| Crosfield Electronics Ltd              | Fax   :  +44 442 232301          |
>| Three Cherry Trees Lane,               | email :  dln@crosfield.co.uk     |
>| Hemel Hempstead, Herts. HP2 7RH, U.K.  |                                  |


Here is a summary of the many useful responses I received
---------------------------------------------------------

A.Macpherson@stl.stc.co.uk wrote :

In comp.sources a long time ago, there was a minimal TCP posted ---
it was the one used in the imagen networked laser printer.

Then there is the berkeley source which is freely available

KA9Q for pcs


Tom Sardella <sardella@strfleet.gsfc.nasa.gov> wrote :

We've had some experience running TCP/IP under VRTX for the last 5 years.
We were working with a 68000 system and doing most of our coding in "C".
What we did was get a Host Development Kit from Excelan and ported the 
Unix drivers to our VRTX system.  The TCP/IP code actually runs on their
intelligent controller (Multibus EXOS 201).  You have to download the
code from your host processor and after that it handles the protocol.  
Communication between the host and the EXOS occurs through message
queues in shared memory.

This implementation has worked quite well, except that Excelan has
since been acquired by Novell and the product is no longer available
or supported.  Novell is negotiating with Federal Techologies 
Corporation to sell them the rights, but that is in limbo right now.

That was our experience with implementing TCP/IP on an embedded
system.  Ready Systems has since implemented their own TCP/IP that
runs with VRTX32.  The thing I don't know is whether they have one
for the 29000.  I have a year old price list that says no, but you may
want to check with them.  They're constantly adding new
processor support and I wouldn't be surprised if they either have one
or are planning one.

There was also an article posted within the last week on
comp.protocols.tcp-ip entitled "Board Level Ethernet/TCP/IP Products".
You may want to check that one out.  I have a copy if you need it.  I'd
also suggest posting to comp.realtime.  Several real-time OS vendors
monitor that group.

	Tom Sardella
	NASA/Goddard Space Flight Center
	Greenbelt, MD
	sardella@strfleet.gsfc.nasa.gov


Theo Schouten <ths@nl.kun.cs> wrote :

We have implemented a TCP/IP version on top of a PDOS real-time
kernel, which runs on MC680xx processors. The implementation
is in C. It will not be to difficult to change it to VRTX on AMD29000.

TCP, UDP, IP, ARP and the ethernet driver (curently for the LANCE chip)
are implemented as different tasks. They communicate using data
structures in global memory and by direct calling internal functions.
They run under PDOS and can be placed in ROM.

On the "user" side there is a UNIX socket interface and applications
like FTP, TELNET and TFTP both client and server versions.
These are implemented both under PDOS and under OS9. For VRTX there
is currently only some communication with the ethernet drivers,
to send and receive raw Ethernet packages. This user side can run
(for OS9 it must of coarse) on a different processor as the lower
TCP/IP layers.

The above software has been licenced to the PEP, FORCE companies and to
Eyring, the developer of PDOS.

We can provide you with a source code licence, so that you can
convert it to VRTX and unlimited provide binaries with all the
hardware products you are selling. We are also willing to do the
conversion to your system for a fixed price (for which we need
more information about your system). Also other kind of licences
can be discussed.

We have also developed code for end-node DECNET, both under PDOS
and OS9, using the ethernet driver and working concurently with
TCP/IP.

For OS9 also the SUN/ONC NFS suite ( RPC, NFS client and server)
has been implemented.

Please contact us, if our products and services can be of any use to solve
your problems.

Greetings,
dr. Th. E. Schouten                  tel: +31 80 65 3175
System Integration Services          fax: +31 80 55 3450
Toernooiveld 102                  e-mail: ths@cs.kun.nl
6525EC Nijmegen
The Netherlands


Joshua Sakov <josh@groucho.uucp> wrote :

So far I found that there is a public domain stripped down version of
TCP/IP on usenet. It is called tinyTCP. Let me know if you need help getting
it.

There is also a company called Spider (I think they are in the UK) who
sells the software. I am planning on checking them out.
- see address at end of this article.

Another source that I have found to get me up and running with TCP/IP
and SNMP was a company called SNMP research. The company is run by J.D. Case
who is one of the original authors of SNMP. They will get you up and running
but they are not going to be cheep.


Michael Haberler <mah@parrot.prv.univie.ac.at> wrote :

I suggest you contact Phil Karn <karn@thumper.bellcore.com> for 
commercial licensing of his `KA9Q' IP package. It's the best and most 
portable around. Stronlgy suggested.
-- 
Michael Haberler 		mah@wu-wien.ac.at,  mah@awiwuw11.bitnet
University of Economics and Business Administration
A-1090 Vienna, Augasse 2-6	    Biz:    +43 (1) 31336 x4796 Fax: 347-555
Home: +43 (1) 961-679 (voice & fax) D-Netz: +43 (663) 811-056


Lee Erickson <erickson@alee.uucp> wrote :

Hunter & Ready has their own software component, they call "TNX".
I've been using it in a 68000 environment.
-----
Lee Erickson                uucp: erickson@alee.UUCP
				  ..!gvlv2!alee!erickson
				  ..!cbmvax!alee!erickson
			internet: erickson%alee@gvl.unisys.com
			  usmail: 720 Raynham Rd., Collegeville PA 19426


Shaji (S.) Bhaskar <BHASKAR@bnr.ca> wrote :

I am currently using a TCP/IP from Ready Systems called TNX.  I am using it
on top of a real-time executive called VRTX32, also manufactured by Ready
Systems in California, USA.  Are we talking of the same VRTX?

The software that I have is object only, and is intended for 68000-based
machines.  I dont know if they have anything for the AMD29000.

The address is Ready Systems, 470 Potrero Avenue, P.O. Box 60217,
Sunnyvale, California 94086, USA. Phone: 408 736 2600. Fax 408 736 3400.

I looked at getting other sources.  The one available free is BSD/Tahoe
TCP/IP from Berkeley.  The beast runs in the Unix kernel, so you need
a real guru to port it in any reasonable time.  You have to simulate
Unix to some extent, and cut out lots of frills.

Shaji Bhaskar
bhaskar@bnr.ca


Ralph Merwin <ralph@swmerc.rain.com> wrote :

...... the Berkeley sources are available from several sites
on the Internet.  I don't know if you have access, but if so, look
in the 4.3BSD-tahoe directory on wuarchive.wustl.edu.  It's all there.

Ralph
-- 
-------------------------------------------------------------------------
Ralph Merwin - Merwin Software Services      ralph@swmerc.rain.com
6782 SW 162nd Drive, Beaverton, OR  97007    72170.151@compuserve.com
(503) 642-0256                               


Tarjei Jensen <tarjeij@ulrik.uio.no> wrote :

Look for sites advertising BSD sources. The place to look for these sites are
in the ftp.list found on pilot.njin.net in /pub/ftp-list.

For a msdos version of sockets look at /pub/wattcp on sunee.uwaterloo.ca. This
is a socket library that uses the packet driver spec. It is mainly written in
Turbo C with some assembler for speed.

Greetings from Norway,


Hwa-jin Bae <hwajin@daahoud.wpd.sgi.com> wrote :

try uunet.uu.net

under directory /usr/spool/ftp/bsd-sources/

when i worked at wind river systems, i used this 4.3 bsd tahoe tcp/ip 
code to port it to vxWorks.

*hwajin
--
protocol engines, inc.


"Phil R. Karn" <karn@thumper.bellcore.com> wrote :

You can obtain the package itself (including full source) by anonymous
FTP to ucsd.edu. Look in /hamradio/ka9q/nos. The most recent source
file is src0618.zip; that's a PKZIP format archive. An executable is
in net.exe. A user's reference manual is in /hamradio/ka9q/docs/ka9qnos.nr.Z;
that's a compressed NROFF -ms source file.


Many thanks to all those mentioned above, for their very helpful
responses. I would also like to thank :

Mark Beyer <markb@unix386.convergent.com>
Carl W. Kalbfleisch <cwk@psychosis.ssc.gov>
John A. Murdie <john@minster.york.ac.uk>
Dennis P. Glatting <dennisg@xetron.com>
Glenn Kasten <glenn@ready.eng.ready.com>


Useful vendor addresses
-----------------------

Ready Systems
470 Potrero Avenue
P.O. Box 60217
Sunnyvale
California 94086

Phone : (408) 736-2600

They offer a "TNX" TCP/IP product to run under VRTX on 80386 and
68xxx series.


Process Software Corp
959 Concord Street
Framingham
MA 01701

Phone : (508) 879 6994
Email : sales@process.com

Offer TCP/IP running on DEC kit, under VMS and RSX etc.


Spider Systems Ltd
Spider Park
Stanwell Street
Edinburgh
Scotland

Phone : +44 031 554 9424 - Mark Picksley

Offer a Streams environment implementation of TCP/IP called SpiderTCP.
They also offer a SpiderSTREAMS emulator, to allow porting of SpiderTCP
to VRTX.


GEC / Marconi Software Systems
Borehamwood
England

Phone : +44 081 906 6238

They are a distributor who may sell TCP/IP source that would need
migrating.


Interactive Systems Corporation
1901 N. Naper Boulevard
Naperville
IL 60563

Phone : (708) 505-9100 ext 236

Offer a Portable Streams Environment for porting their TCP/IP to
non-UNIX systems.


The Wollongong Group
1129 San Antonio Road
P. O. Box 51860
Palo Alto
CA 94303-4374

Phone : (415) 962-7229  - Tom Browne

Offer a Portable Streams Environment for porting their
WIN/Streams TCP/IP product family.


FTP Software Inc
U.S.A.

Phone : (617) 264-0900

Do some TCP/IP products.



Regards

	Dave

--

| Dave Norman                            | Phone :  +44 442 230000 ext 3354 |
| Crosfield Electronics Ltd              | Fax   :  +44 442 232301          |
| Three Cherry Trees Lane,               | email :  dln@crosfield.co.uk     |
| Hemel Hempstead, Herts. HP2 7RH, U.K.  |                                  |

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 11:38:30 GMT
From:      sfrazier@mcinix.UUCP (Steven E. Frazier)
To:        comp.protocols.tcp-ip
Subject:   ftp - automatically?

Is it possible to write a script and ftp to a site, change directories and
put a file and get a file via a script?  Has anyone done this before?  Pleas
email me if you could answer this one.

Thanks.

Steve


-- 
Steven E. Frazier
 (614) 761-6612
  VNET 424-6612

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 12:12:40 GMT
From:      apartlow@coyote.JDSSC.DCA.MIL (allen partlow)
To:        comp.protocols.tcp-ip
Subject:   Question on JDSSC - JCS Subnet Masks


Dear TCP/IP Experts,

Before I begin I first would like to say that I was told that
your group might be of help to me by Mr. Hal Huntley at the NIC.
He also told me that I should inform you that I am not on the mailing
list.  Please respond back to me at:  

                   apartlow@coyote.jdssc.dca.mil.

I have a question regarding an unusual internetworking project.
We at jdssc.dca.mil are a Class B network with address 137.130.0.0.
We do not logically segment our TCP network so the subnet mask we
use on all of our hosts and our gateway is 255.255.0.0.

We now have been tasked to add a user community from the Joint Chiefs
of Staff to our network with a seperate domain name, a seperate name
server and a subset of four 255 group addresses of our Class B network.

Their domain name will be of the form xxx.jcs.mil and their addresses
will be:      
  
            137.130.244.0 thru 137.130.244.255
            137.130.245.0 thru 137.130.245.255
            137.130.246.0 thru 137.130.246.255
            137.130.247.0.thru 137.130.247.255

We have a Cisco Gateway (AGS/2) with 1 ethernet interface and one serial
interface.  We will be adding an ethernet interface to attach this JCS
segment.  The subnet mask on the JCS segment would need to be 255.255.252.0.

The subnet mask on the JCS side will prevent JCS traffic from getting out
of that segment.  My question is since we will both have the same first
two octet numbers,  will JDSSC traffic be prevented from getting onto
the JCS segment?

I guess this boils down to whether or not the subnet mask works for both
inbound and outbound traffic on the Cisco Gateway.  I assume that it must
in order to prevent all the traffic on the network from ending up on your
lan but I am still uncertain how these subnet masks will work on the router
when both lans are local to it.

				Thank You for Your Help,


				Allen D. Parltow
				(703) 697-6536  

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 12:32:18 GMT
From:      scs@iti.org (Steve Simmons)
To:        comp.protocols.tcp-ip,comp.archives.admin
Subject:   Re: On the need to develop Internet user services

pte900@jatz.aarnet.edu.au (Peter Elford) writes:

>In article <1991Jun30.083257.17896@cs.mcgill.ca>, peterd@cs.mcgill.ca (Peter Deutsch) writes:
 
>|> I would love to see each and every person coming onto the
>|> net receive a "welcome package" of basic tutorials, plus
>|> single sheet cards on the standard user tools (including a
>|> general guide to the net, email, news, file sharing, ftp
>|> and whatever follow-on to archie we can put together, plus
>|> info on the work of people like Ed Vielemetti of
>|> comp.archives, the Prospero and WAIS work, accessing your
>|> local library catalogues, and so on).
 
>This stuff *must* come from the regional networks. Local 
>variations about where the nearest servers are, details on
>local libraries, phone numbers, site contacts can not be
>developed centrally.

This is a much more difficult task than you would think.  [[Don't get
me wrong, I agree it needs to be done.]]  There is no document which
will permit the computer-naive to sit down and use ftp at all, let
alone permit them to unpack and build what they receive.  For example,
a guide to file sharing is useless to those who have no conception of
what a file is.

There's also a horrible catch-22 here.  Any document which is complete
enough to describe "the net, email, news, file sharing, ftp and
whatever follow-on to archie we can put together, plus . . ." will be
quite large.  A naive user faced with such a document typically turns
to you and says "can't you give me a simple guide?"  The answer is of
course "no, it's a complex answer."  What is needed is a way to provide
service to the naive user, not train them to be experts.

IMHO the answer will be computer usage service folks.  Few of our
researchers do their own database searches -- they describe their query
to our librarians, and the librarians navigate thru the databases.  A
similar thing already occurs with email -- naive users go to their local
postmasters for hard questions.
-- 
  "If we don't provide support to our users someone is bound to
   confuse us with Microsoft."
	-- Charles "Chip" Yamasaki

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 12:47:52 GMT
From:      scs@iti.org (Steve Simmons)
To:        comp.protocols.tcp-ip,comp.archives.admin
Subject:   Re: On the need to develop Internet user services

pte900@jatz.aarnet.edu.au (Peter Elford) writes:

>The Internet can become a friendlier, more useful, more efficient
>facility for a larger community of users by spending more resources
>on doing things smarter, and on tools that address end-user requirements.

True.  But I would seriously question if this is the purpose of the
federally funded portions of the internet.  The commercial applications
are too obvious, while "white pages" has tremendous utility but little
commercial impetus.

Has anyone approached Mead Data Central (nexus/lexus, other dbs) about
funding archive services?
-- 
  "If we don't provide support to our users someone is bound to
   confuse us with Microsoft."
	-- Charles "Chip" Yamasaki

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 13:55:07 GMT
From:      dennisg@kgw1.xetron.COM (Dennis Glatting)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc.hardware
Subject:   need pc product to do ethernet/tcp/ip analysis

i need to do some ethernet/tcp/ip analysis to determine
why i'm having problems between a NeXT computer and a CMC TranServer.

what i'm looking for is a product which plugs into a pc
to do packet analysis of ethernet (thin net) transactions.

although i understand ethernet/tcp/ip i don't have any--what i would
call--real experence;  therefore, the product should assume
a novice user (if that is posible).  i want to be able to store data
to disk such that i--and others--can do postmortem analysis (actually,
i want to uucp textual data).

please respond by email.  i cross posted to accounts to which we
don't subscribe.

thanks in advance...

-- 
 ..!uunet!kgw2!dennisg  | Dennis P. Glatting
 dennisg@Xetron.COM     | The more I read to learn and understand,
                        | and experience with first hand, 
                        | the less I seem to know.

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 14:29:26 GMT
From:      worley@compass.com (Dale Worley)
To:        comp.protocols.tcp-ip,comp.archives.admin
Subject:   Re: On the need to develop Internet user services

I found Peter Deutsch's article informative and well-written, but I
noticed an oddity -- despite that it is entirely concerned with
supplying money to develop software, at no point does it mention
commercial development.  As others have pointed out here, many of the
needed new Internet services have already been proven in concept, and
thus cannot get research funding.  But nobody has mentioned that that
is the natural point at which a commercial service should produce a
practical, "industrial strength" implementation.

However, the barriers to commercialization are enormous:

The biggest barrier is just that we (that is, USAians) are rather bad
at commercialization.  In many fields, we produce the finest research
in the world, but in very few do we produce the best products.  The
Japanese (and many other existing and rising economic powers) are very
good at commercialization, and it is costing the U.S. economy dearly.

The NSFnet is specifically forbidden from carrying commercial traffic.
Thus, although a commercial information service can buy network
service from several vendors, it can't talk to the vast bulk of the
potential customers, who are only connected through the NSFnet.  It's
as if the phone system served only residences, and a business wanted
to use a telephone for talking to customers, but wasn't allowed to.
The explanation "you can connect to another phone system serving only
businesses" doesn't cut it, because the people you want to talk to are
on the existing phone system.

Interestingly, although the NSFnet plans to go to a pay-as-you-go
system for funding, there are no plans to allow commercial usage,
although pay-as-you-go eliminates the one real objection to commercial
usage: the government shouldn't subsidize commercial users.  (Of
course, in most of Europe that wouldn't be considered an objection...)

A further barrier is that an astonishing fraction of the users of
NSFnet have a deep, visceral objection to commercial information
services.  Frankly, I don't understand where it comes from, but it's
there, and it's intense.  Consider the flamage Ed Vielmetti got when
he proposed that he sell the information he had previously prepared
for free!  And there have been many other cases as well.  Of course,
some of the objections have been quite reasonable, but if you examine
the whole tenor of the discussions of commercialized information on
The Net, it is clear that most of the users have a decided prejudice
against it.

Remember, commercialized information services need not be more
expensive than the present system.  After all, we are already paying
for the present system, through taxes.  And commercialized systems can
be astonishingly inexpensive if competition works smoothly -- the U.S.
probably has the cheapest long-distance telephone service in the
industrialized world (figuring in subsidies) precisely because it has
the most capitalist long-distance telephone service.  (AT&T could
probably reduce its rates by 10% if it just stopped running all those
commercials!)  It has gotten to the point that ordinary people feel
little concern about the expense of placing long-distance calls, when
even twenty years ago, they were reserved only for important messages.

Oh, well,

Dale Worley		Compass, Inc.			worley@compass.com
--
Those who will be able to conquer software will be able to
conquer the world.  -- Tadahiro Sekimoto, President, NEC Corp.

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 14:39:47 GMT
From:      kdb@intercon.com (Kurt Baumann)
To:        comp.protocols.tcp-ip
Subject:   Re: snmp for Macs

In article <1976@vtserf.cc.vt.edu>, jcrowder@groupw.cns.vt.edu (Jeff Crowder) 
writes:
> Can anyone recommend an SNMP monitor for an Apple environment?  We have
> a user who wants to manage his soon-to-be-installed 10BaseT network
> using one of his existing Macs.  Public domain would be preferable but
> any pointers would be appreciated (marketing reps welcome).    
> 
> Thanks,		
> 
> Jeff Crowder
> jcrowder@GroupW.cns.vt.edu

I won't recommend one (cause we make one), but as far as I know there is only 
one SNMP monitor that I know of, ours.  It's called WatchTower, and will be 
shipping near the end of this month.  For more information drop me a note.

PS if anyone knows of a PD one, please let me know too.


Kurt Baumann                  703.709.9890
InterCon Systems Corp.   Creators of fine TCP/IP products for
                                       the Macintosh

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 14:55:37 GMT
From:      dennisg@kgw1.xetron.COM (Dennis Glatting)
To:        comp.mail.uucp,comp.protocols.tcp-ip
Subject:   hack on uucp to improve efficiency

i understand that it is possible to hack on uucp binaries
to increase its window size thus increasing its throughput.

okay, how?

i have a Sun 3/60 4.1.1.

-- 
 ..!uunet!kgw2!dennisg  | Dennis P. Glatting
 dennisg@Xetron.COM     | The more I read to learn and understand,
                        | and experience with first hand, 
                        | the less I seem to know.

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 15:14:37 GMT
From:      kdb@intercon.com (Kurt Baumann)
To:        comp.protocols.tcp-ip
Subject:   Re: Owner of TCP/IP trademark

In article <9107022002.AA21520@ucbvax.Berkeley.EDU>, rinehart@AEDC-VAX.AF.MIL 
("Kathy Rinehart c60191 x3899") writes:
> TCP/IP was identified as "a registered trademark of The Wollongong 
> Group".

We did a trademark search on TCP/Connect, our product, and nothing showed up on 
TCP/IP as a trademark.  It would be difficult, if not impossible, to trademark 
TCP/IP.

I believe that they meant WIN/TCP.


Kurt Baumann                  703.709.9890
InterCon Systems Corp.   Creators of fine TCP/IP products for
                                       the Macintosh

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 17:29:07 GMT
From:      kanvik@casbah.acns.nwu.edu (Joel W Kanvik)
To:        comp.os.os2.misc,comp.protocols.tcp-ip
Subject:   Re: TCP/IP under OS2

Try TCP/IP that was developed for OS/2.  I've used it for a while (before
someone crashed my machine).  Works very well.  Comes with LaMail, ftp, and
other little toys.  Also has vt100 executable file, so that you don't have
to configure your terminal.  Pretty slick.  

Joel W. Kanvik
kanvik@casbah.acns.nwu.edu

I speak for myself; noone else.

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 17:50:44 GMT
From:      mmorse@NSF.GOV (Michael Morse)
To:        comp.protocols.tcp-ip
Subject:   Re: On the need to develop Internet user services


> Well, for what it's worth I think newcomers shouldn't even
> have to ask that. This posting touches a raw nerve with me
> as I think we (the Internet community) have been rather
> slow at seeing the real potential of what we have created,
> or at least in communicating that potential and
> translating it into tools for our naive or first-time
> users.

Peter,
   I appreciated your recent posting, and I agree with you that
end-users have been largely ignored on the Internet.  I think there is
a general progression on how new people use the net:
 
  1. E-Mail -- This area is pretty well documented and easy-to-use
               interfaces are available.  All networks users can
               access.
  2. File Transfer -- This area is now growing rapidly.  The ftp
               command itself is too hard (except for some Macintosh
               implementations).  Finding what you want is even
               harder, and is, of course, the area you are working on.
               Mostly limited to network/UNIX savvy users.  
  3. Remote Login -- This is the area that will explode soon.  Many
               university libraries have made their card catalogs
               available.  This is the area that I'm interested in,
               particularly in the area of common (character-based)
               user interfaces, and the escape key/escape sequence
               problem.  Many users can access, but each supplier
               must train and support their user base. 
  4. Coming soon: Gui-based remote login, distributed (RPC)
               applications (such as the weather server), and 
               distributed file systems.  These will be restricted
               to the network experts for the near future.

   You can see this same progression in the acceptance of OSI, which
is just in the beginning of the E-Mail stage, with simple file
transfer being barely there, and Remote Login not even really well
specified yet.
 
   I was wondering if it would be helpful if there was a conference
(or more likely a part of a larger conference) for people who are
providing Internet services to get together and discuss common
problems and solutions?  (Of course your boss may not provide you the
funds to get to the conference  :-) , but that's another problem).  

   Concerning your comments about how we can get some full-time,
funded, people working on some of these problems, I agree that the
regionals are a natural starting point.  In most cases they spend most
of their time making sure the links are up and the routers are
routing, but it's probably time to start looking at how people are
*using* the network.

--Mike

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 18:49:20 GMT
From:      brendan@cs.widener.edu (Brendan Kehoe)
To:        comp.protocols.tcp-ip
Subject:   Visual Traceroute

I just had an idea .. I'm curious if it's been done, or considered, or ..

Picture this: a big X window, with a map of the US [I won't think
world yet] on it .. just the outline of the states. You're a bright
red dot (assuming you have color..or a blinking dot b/w). You type in
the name of the host you want to trace [assuming it's real], and this
program takes each router that the route passes through and plots it
on the display, progressively. Domains would have generic areas, while
the NSF nss's would have their locations pre-determined. Nothing
really hair-trigger accurate, just a generic idea of where the packets
are travelling.

For example:

	xtrace gatekeeper.dec.com
	<foom, big dressed up display>
		... lines form progressively ...
	cs_router.widener.edu	-> in_router.widener.edu
	phl2-gw.prepnet.com	<- in_router.widener.edu
		... prepnet ...
	oday-intf.psc.edu	-> enss-e.psc.edu
	t3-3.cnss40.t3.nsf.net	<- enss-e.psc.edu
	t3-3.cnss40.t3.nsf.net	-> t3-0.cnss105.t3.nsf.net
	t3-2.cnss24.t3.nsf.net	<- t3-0.cnss105.t3.nsf.net
		... the other nss's ...
	t3-0.pa-enss.t3.nsf.net	-> su-b.barrnet.net
		... and finally to gatekeeper.dec.com ...

 Something along the lines of what a network operations center would
have, but on a drastically smaller scale.

 Ideas? Comments? (Forget it?)

Brendan
-- 
     Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu
  Widener University in Chester, PA                A Bloody Sun-Dec War Zone
"You have no right to destroy a man's reputation!" ...
                      ... "Yes I do--I'm the press." - In the Heat of the Night

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 18:51:12 GMT
From:      ji@cs.columbia.edu (John Ioannidis)
To:        comp.protocols.tcp-ip
Subject:   Internet Encapsulation and RFC-1241

RFC-1241 (just published) describes a general mechanism for setting up
tunnels and encapsulating datagrams within IP datagrams. For those
interested in the subject, I have described a specific IP encapsulation
protocol, which I call IPIP ("IP-within-IP", protocol #94) in my
SIGCOMM'91 paper "IP-based Protocols for Mobile Internetworking". 

If you don't want to wait till the proceedings are out, you can get the
paper with anonymous FTP from cs.columbia.edu:/pub/ji/sigcomm91*.ps.Z.
The code for the work described in the paper has been working since
April. Send me e-mail for more details.

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 19:01:42 GMT
From:      elogan@hp835.mitek.com (Ernie Logan)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp - automatically?

To sfrazier@mcinix.UUCP:

I can't seem to email you.

Yes. The method will depend on operating system. *IX will usually require a
file called .netrc (man netrc) and a seperate script file (ftp < scriptfile).
VMS you use DCL scripts. Others do different things.
_________________________________

Ernie Logan
AS/400 TCP/IP Development
elogan@mitek.com

OpenConnect Systems
2033 Chennault Drive
Carrollton, Texas USA 75006
Phone: (214) 490-4090
*-------------------------------*
* "My opinions are mine alone.	*
* No one else would want them."	*
*-------------------------------*

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 19:23:05 GMT
From:      HANK@VM.TAU.AC.IL (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Network maps in PS format V1

This document is meant to catalog all known network maps in postscript
format that are available via the Internet.  One purpose is so that people
can review other network maps for ideas and formats.  The main purpose
is for the newly forming RIPE mapping WG to determine what icons people
use in their network maps and to create an RFC that standardizes the
icons as well as the format that people will create for their network
maps.  Please send all corrections and additions to this list to:
hank@vm.tau.ac.il

CAVAET:

Some Postscript maps won't print correctly on many laser printers.
This is due to the files being in Apple Postscript rather than in
standard postscript.  Most maps reported here will print properly.
-----------------------------------------------------------------
1) anonymous ftp name and number
   aarnet.edu.au   139.130.204.4

2) cd __________
   pub/maps

3) get ___________.ps
   aarn-backbone.ps

4) What is included in your map?
   Backbone of AARNet network, link speeds, comment on topology

5) How often is it updated?
   Whenever something significant changes! Say, every three months,

6) Contact?
   P.Elford@aarnet.edu.au
-----------------------------------------------------------------
1) anonymous ftp name and number
   ftp.cc.berkeley.edu        128.32.136.9

2) cd __________
   pub

3) get ___________.ps
   ucb.map.ps

4) What is included in your map?
   The UCB IP routers

5) How often is it updated?
   Whenever I feel like it (actually I just created it recently).

6) Contact?
   cliff@garnet.berkeley.edu
-----------------------------------------------------------------
1) anonymous ftp name and number
   Arizona.EDU  128.196.128.233

2) cd __________
   networks.maps

3) get ___________.ps
   uanet-prepped.ps

4) What is included in your map?
   Subnets of the University of Arizona's network (128.196.0.0).

5) How often is it updated?
   Once every couple of months or so.

6) Contact?
   Leonard@Arizona.EDU
-----------------------------------------------------------------
1) anonymous ftp name and number
   NIS.NSF.NET    35.1.1.48

2) cd __________
   maps

3) get ___________.ps
ASIANET  PS       V        128        276          8  1/17/89  1:30:13
BACKBONE NEW-PS   V        117       6765         50 10/01/90 14:41:43
BACKBONE OLD-PS   V         94       2437         25  2/24/89 15:40:22
BACKBONE OLD2-PS  V         94       2445         25  2/24/89 15:39:57
BACKBONE T1-PS    V        106       6375         46  4/18/91 12:36:39
BACKBONE T1T3-PS  V        108       7088         51  4/23/91  9:39:58
BACKBONE T3-PS    V        117       6515         46  4/18/91 15:05:57
BARRNET  PS       V        124       1222         10  5/30/90 11:39:03
BITNET   PS       V        130       2870         85  1/17/89  1:30:20
BITNET4  PS       V        130       3389        101  1/17/89  1:30:28
CERFNET  PS       V        876       3594         24 11/30/90 11:03:39
CICNET   PS       V         28      23597         68  2/11/91 18:16:12
CORNELL  PS       V        112        110          2  2/17/89  1:53:49
DC       PS       V         99        421          5  3/23/89 11:01:45
EARNET   PS       V        129       1447         43  1/17/89  1:30:33
ESNET    PS       V         94       2462         25  5/05/89 14:10:25
HARVARD  MAP      V         78         59          1  2/17/89  1:57:53
LOSNETTO PS       V        106       1309          9 11/27/90 17:26:12
MERIT-MI PS       V         88       6449         19  6/01/90 11:50:09
MIDNET   PS       V        132        730          6  2/17/89  1:52:58
NA_NETS  PS       V         94       2802         26  5/17/89  9:56:55
NCAR     PS       V        255       1602         11  2/17/89  1:52:46
NETMAP   DOC      V         78       1140         13  2/24/89 16:05:27
NETNORTH PS       V        129        511         16  1/17/89  1:30:36
NYSERNET PS       V         53       2475          9  2/17/89  1:56:40
PREPNET  PS       V         80       1856          9  2/22/89  9:59:39
PSC_IP   PS       V         80       3479         18  2/22/89  9:59:48
RICENET  PS-LW    V         57       2079          8  3/07/89 16:31:24
SCINET   PS       V         94       2536         26  4/28/89 14:23:35
SCINETDC PS       V        100        280          3  4/28/89 16:40:31
SESQUINE PS-LW    V         53        610          3  3/07/89 16:31:11
SURANET  PS       V         87       1158         13  3/23/89 11:01:40
SURAN289 PS       V         96        468          4  3/07/89 16:29:10
TEXASIP  PS       V         96        405          4  3/07/89 16:28:32
UIUC     PS       V         93        904          5 12/28/88 14:10:34
UIUC-MAP PS       V         72       3892         14 12/28/88 14:10:45
UMNET    PS       V        124       1343          9  5/30/90 10:14:22
UNETS-A  PS       V         94       3824         29  5/14/90 14:29:51
USENIX   PS       V         79       4916         17  2/10/89  9:29:59
USNETS   PS       V         94       3824         29  5/14/90 14:26:37

4) What is included in your map?

5) How often is it updated?

6) Contact?
   userhelp@nis.nsf.net
-----------------------------------------------------------------
1) anonymous ftp name and number
   mcsun.eu.net       192.16.202.1

2) cd __________
   ripe/maps

3) get ___________.ps
   Jun  4 10:25 europe.ps
   Feb  2  1990 map01-netnums.ps.Z
   Feb  2  1990 map01-speeds.ps.Z
   Jun 15  1990 map02-netnums.ps.Z
   Jun 20  1990 map02-speeds.ps.Z
   Jul  9  1990 map03-legend.ps.Z
   Jul  9  1990 map03-netnums.ps.Z
   Jul  9  1990 map03-speeds.ps.Z
   Aug 28  1990 map04-legend.ps.Z
   Aug 28  1990 map04-netnums-1p.ps.Z
   Aug 28  1990 map04-netnums-2p.ps.Z
   Aug 28  1990 map04-speeds-1p.ps.Z
   Aug 28  1990 map04-speeds-2p.ps.Z
   Nov  9  1990 map05-legend.ps.Z
   Nov  9  1990 map05-netnums-1p.ps.Z
   Nov  9  1990 map05-netnums-2p.ps.Z
   Nov  9  1990 map05-speeds-1p.ps.Z
   Nov  9  1990 map05-speeds-2p.ps.Z
   Feb 27 14:16 map06-legend.ps.Z
   Feb 27 13:55 map06-netnums.ps.Z
   Feb 27 13:54 map06-speeds.ps.Z
   Jun  4 10:25 us-europe.ps

4) What is included in your map?

5) How often is it updated?

6) Contact?
-----------------------------------------------------------------
1) anonymous ftp name and number
   nic.nordu.net    192.36.148.17

2) cd __________
   maps

3) get ___________.ps
   Nov  9  1990 ch-map-netnums.ps
   Nov  9  1990 ch-map-speeds.ps
   May 26 20:35 europe.ps
   Mar  2  1990 fi-map.ps
   Mar  2  1990 fr-map.ps
   Nov  9  1990 map05-legend.ps
   Nov  9  1990 map05-netnums-1p.ps
   Nov  9  1990 map05-netnums-2p.ps
   Nov  9  1990 map05-speeds-1p.ps
   Nov  9  1990 map05-speeds-2p.ps
   Mar 14  1990 nl-map.ps
   Mar  2  1990 no-map.ps
   Nov  9  1990 nordunet.ps
   May 26 20:36 us-europe.ps

4) What is included in your map?

5) How often is it updated?

6) Contact?
-----------------------------------------------------------------
1) anonymous ftp name and number
   ftp.pitt.edu    130.49.253.1

2) cd __________
   /prepnet/maps

3) get ___________.ps
   member_map_mmddyy.ps
   connectivity_map_mmddyy.ps

4) What is included in your map?
   member map is the geographical locations of our members and shows
   the backbone circuits; connectivity map shows how the routers are
   connected and the speed of the connections

5) How often is it updated?
   member map is updated each time we have a new member; connectivity
   map is updated each time a member is connected or a member changes
   some configuration

6) Contact?
   kf1b+@andrew.cmu.edu
-----------------------------------------------------------------
1) anonymous ftp name and number
   spot.colorado.edu   128.138.129.2

2) cd __________
   westnet

3) get ___________.ps
   map.ps

4) What is included in your map?
   A logical map of Westnet, the Rocky Mountain states Internet
   regional network.

5) How often is it updated?

6) Contact?
---------------------------------------------------------------------
1) anonymous ftp name and number
   nisc.sesqui.net         128.241.0.84

2) cd __________
   pub

3) get ___________.ps
   texas.ps

4) what is included in your map?
   The combined IP topology of Sesquinet and THEnet implemented as
   a single autonomous system of Cisco routers.  No detail at the
   campus level is included.

5) how often is it updated?
   Whenever this topology changes.

6) Contact?
-----------------------------------------------------------------
1) anonymous ftp name and number
   vm.tau.ac.il            132.66.32.4

2) cd __________
   hank.400

3) get ___________.ps
   ilanmap.ps

4) what is included in your map?
   The cisco router backbone in Israel, line speeds, router interfaces and
   subnet addresses.  Certain headers and legends are in Hebrew.

5) how often is it updated?
   Whenever this topology changes.

6) Contact?
   ccyilan@technion.technion.ac.il

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 20:14:57 GMT
From:      moraes@cs.toronto.edu (Mark Moraes)
To:        comp.protocols.tcp-ip,comp.archives.admin
Subject:   Re: On the need to develop Internet user services

scs@iti.org (Steve Simmons) writes:
>                                             There is no document which
>will permit the computer-naive to sit down and use ftp at all, let
>alone permit them to unpack and build what they receive.

Not strictly true.  Here's one I wrote for our facility a while back.
Your observation that no-one reads it is fairly accurate.  Still, it's
useful to mail to people when they ask "what's this anon. ftp" thing.
Yeah, I know it could use updating, but this isn't the stuff I'm paid
to do.  Known drawbacks:
- Unix biased; no info on dealing with the simtel20s of the world.
- Should probably be upgraded to document more common archive formats.
- assumes you have an ftp that understands nameservers.  At least one common
brand of workstation as shipped has a deficient ftp.

The document is also available from ftp.cs.toronto.edu as doc/ftp.help.

	Mark.

---
       Using "anonymous ftp" to get files from other machines

              Mark Moraes, University of Toronto

Anonymous ftp is a facility offered by many machines on the Internet.
This permits you to log in with the ftp program with the user name
'anonymous' or the user name 'ftp'. When prompted for a password, type
your e-mail address -- it's not necessary, but it's a courtesy for
those sites that like to know who is making use of their facility. Be
courteous.

You can then look around and retrieve files. (Most anonymous ftp sites
do not permit people to store files)  The ftp program prompts you with

ftp>

and offers a few commands that are similar to Unix.  "cd" changes your
directory on the remote machine, "lcd" changes your directory on the
local machine, "get" will get a file, etc. See the manual page for ftp
(use the command "man ftp")

Typically, a directory called 'pub' is where the interesting things
are stored. Some sites will have a file with a name like ls-lR, that
contains a complete list of the files on that site. Otherwise, you can
type ls -lR and get such a listing -- for some sites, this can take
a LONG time.

Usually, files are grouped in archive files, so you don't have to get
many small files separately. The most common archival file format for
the Internet is tar. Occasionally, people use shell archives (shar)
instead. tar archives can be unpacked by running the tar command --
you may want to first do a 'tar t' on the file to see what it contains
before unpacking it. Be careful when unpacking shell archives since
they have to be run through the Bourne shell to unpack them. (The
simplest way is to use the unshar command)

Files are often stored compressed -- for Unix, the most common scheme
is the compress program, indicated by a .Z suffix on the file name.
Sometimes, people use programs like arc or zoo, which are combined
archival and compression formats. (There are probably other archival
formats as well - talk to the systems staff if you encounter them and
don't know how to deal with them)

When retrieving non-text files, you must use binary mode, otherwise
the file gets messed up. To do this, use the 'binary' command. (It's
safe to set this for text files. If the site at the other end is
non-Unix, you may need to use some other mode -- see the documents for
that site and for ftp)

An example session follows -- the commands I typed are all underlined
with a row of carets (^^^^) and are usually typed at the % or ftp>
prompt.

% ftp cs.toronto.edu
  ^^^^^^^^^^^^^^^^^^
Connected to cs.toronto.edu.
220 neat.cs FTP server (Version 5.55 Tue Aug 8 22:48:27 EDT 1989) ready.
Name (cs.toronto.edu:moraes): anonymous
                              ^^^^^^^^^
331 Guest login ok, send ident as password.
Password:moraes@csri.toronto.edu
         ^^^^^^^^^^^^^^^^^^^^^^^
230 Guest login ok, access restrictions apply.
Remote system type is UNIX.
ftp> dir
     ^^^
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 62
drwxr-xr-x  2 0        0             512 Nov 20  1988 bin
drwxr-xr-x 11 0        0            2048 Dec 29 00:45 pub
226 Transfer complete.
ftp> cd pub
     ^^^^^^
250 CWD command successful.
ftp> dir
     ^^^
200 PORT command successful.
150 Opening ASCII mode data connection for /bin/ls.
total 4523
...
-rw-r--r--  1 0        0           51251 Sep 16 12:02 ssl.tar.Z
...
226 Transfer complete.
ftp> hash
     ^^^^
Hash mark printing on (1024 bytes/hash mark).
ftp> binary
     ^^^^^^
200 Type set to I.
ftp> get ssl.tar.Z
     ^^^^^^^^^^^^^
200 PORT command successful.
150 Opening BINARY mode data connection for ssl.tar.Z (51251 bytes).
##################################################
226 Transfer complete.
51251 bytes received in 0.94 seconds (53 Kbytes/s)
ftp> quit
     ^^^^
221 Goodbye.

Now, to see what ssl.tar.Z contains, I can use:

% uncompress < ssl.tar.Z | tar tvf - 
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
drwxrwxr-x 7/0        0 Sep 16 11:58 1989 ssl/
-rw-r--r-- 7/0      301 Sep 16 11:58 1989 ssl/Makefile
-rw-r--r-- 7/0      240 Jun  2 01:08 1988 ssl/README
-rw-r--r-- 7/0    20642 Feb 26 21:43 1988 ssl/file.ssl
-rw-r--r-- 7/0     5241 Feb 21 15:25 1988 ssl/file.sst
-rw-r--r-- 7/0    56581 Sep 16 11:57 1989 ssl/ssl.c
-rw-r--r-- 7/0    20642 Feb 26 20:08 1988 ssl/ssl.ssl
-rw-r--r-- 7/0     5241 Feb 26 21:41 1988 ssl/ssl:sst.c
-rw-r--r-- 7/0     5395 Feb 26 21:41 1988 ssl/ssl:sst.h
-rw-r--r-- 7/0    12211 Mar 30 22:34 1988 ssl/sslskel.c
-rw-r--r-- 7/0      274 Feb 26 20:42 1988 ssl/sslskel.ssl
-rw-r--r-- 7/0       55 Feb 26 20:42 1988 ssl/sslskel.sst.c
-rw-r--r-- 7/0     1001 Feb 26 20:42 1988 ssl/sslskel.sst.h

To extract the files, I use

% uncompress < ssl.tar.Z | tar xvf - 
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ssl/
ssl/Makefile
ssl/README
ssl/file.ssl
ssl/file.sst
ssl/ssl.c
ssl/ssl.ssl
ssl/ssl:sst.c
ssl/ssl:sst.h
ssl/sslskel.c
ssl/sslskel.ssl
ssl/sslskel.sst.c
ssl/sslskel.sst.h

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 20:30:28 GMT
From:      brunner@telebit.com (Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Re: Miniumum hardware required to support SLIP connection?

In article <518@cysog.UUCP> drt@cysog.UUCP (David R. Trinidad) writes:
>
>How hard is the configuration on the Netblazer and how reliable
>is it ???
>
Well, I've configured a few and it isn't too hard. The first time felt like
the first time I configured a cisco router. My suggestion is that one first
prints the startup.cnf and/or default.cnf files and then read them with the
documentation (3 ring binder) adjacent. Then do lots of for-fun setups such
as adding users, dialup interfaces and routes to mars. If you've two NB boxes
and a couple of modems in your office/lab you will win big on the learning
curve problem we all face with new systems, especially this one which is a
mix of ip skills and modem smarts, which not a lot of people have. After you
have finnished with the for-fun exercise, you can pre-configure the remote
box and have it drop shipped to your remote site.

How reliable is it? Well, the hardware is reliable and Telebit is going to
ship the next release _real_ soon now. It (the unreleased next release) has
been much more exhaustively tested than prior versions. Some of the new
features are cute too. There won't be a useful "reliability" comment on the
new release until its been used for a while -- ask the same question in August.
BTW, this comes to you via an NB box hanging off of Alternet's present Mountain
View point-of-presence.

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 20:41:35 GMT
From:      snorthc@relay.nswc.navy.mil (Stephen Northcutt)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Is GOSIP ready for prime time?

John R. Brinkema writes:
... I said no! and went into
>a tirade about how GOSIP was an incomplete standard, that what existed was
>too new, and consequently not as fast or reliable as my current protocol
>(TCP/IP) and in any event not fully supported by the UNIX vendors that
>supply my systems.

The VJ enhancements to TCP are also new, do you implement them?
What pray tell is fully supported by UNIX vendors?
GOSIP, may in fact be an incomplete standard, but the fine NIST
folk are working that issue.  Next will be GOSIP 3 and so forth,
from what I see in the POSIX arena this could go on for quite some
time.  When will GOSIP be complete?  Never.  How could it be, there
will always be something to add.  

> He, in return gave a defense of the ISO protocols and
>those parts of GOSIP that he has used.  His defense has caused me to
>reconsider my position: he (unlike me) has first hand experience in
>integrating GOSIP systems and all his experiences have been postitive.

Hmmm.  Sounds like OSI is his religion, not his protocol.  "ALL" of my
experiences have NOT been positive with TCP or OSI.  I do wish you had
posted the essence of his arguments. 

>My world is almost 100% Unix.  In time we will be migrating to GOSIP, but
>I assumed that day would be in 5 to 10 years.  Am I being too consevative;

We keep asking people not to migrate, after all the work the ISO
community has done, to finally have the users switch over to OSI
and then go back to TCP, its cruel:-)

On the timeframe for your transition to OSI.  Only you can answer
that.  Do you make the decision?  Do you have the $$$ to buy new
protocol stacks?  Can you get an address space (I sure can't)?
Does GOSIP have something you don't already have?  Does TCP offer
you something you require and can't get from GOSIP.  The answer
to the last two questions is probably yes.  You may find your 
shop adding GOSIP to a couple of systems to meet specific needs
enabling OSI on your routers and primarily running TCP.

>will GOSIP give me something that I don't have now (I sleep fairly well
>and Monday morning is usually quient - something unusual for network
>administrators).

GOSIP may in fact give you something you may not have now.  Compliance
with Federal law, (that thing I took an oath to uphold).  When I
buy a system, I have to check off whether it is compliant with
FIPSPUB umpty squat or NA.  I think I have to sign that sheet.

Personally I think a power outage does more harm to our net than
protocol x or y.  Anyway, you seem to be considering OSI in the
extremes.  Perhaps GOSIP is not ready for prime time.  X.400 may
still have advantages over RFC822 type mail.  There are cases
where FTAM might suit a need better than FTP.  I wish our phone
system here was ISDN capable....

My personal concern is that we are discussing the wrong problem.
TCP or TP4  can both be made to work.  Meanwhile there is a
lot of work going on in new ways to network: SONET, ATM, Fibre
channel ...  It is not clear to me That these have any real need
or notion of TP anything.  Best of luck.  Stephen.

===================================================================
   ** my dream: voice, video, data, 3 services, 1 network **
===================================================================

Stephen Northcutt (snorthc@relay.nswc.navy.mil)     News Admin

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 21:15:03 GMT
From:      HANK@VM.TAU.AC.IL (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   NIC.NSF.NET

I can ping it by number but by name it seems as if it has lost its nameserver.
Is anyone else having problems getting to nic.nsf.net (35.1.1.48)?

Hank

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 21:52:55 GMT
From:      wmarko@UB.D.UMN.EDU (William J. Marko)
To:        comp.protocols.tcp-ip
Subject:   commercial internet access

commercial internet access providers,

the following two firms are interested in learning more about
internet access.  those of u wishing to provide such a service, please
call either or both of the firms listed below.

if either of the firms should become your customers, i will expect my
commission in the mail... :^)

Richard Collins   Wachovia Student Loan Center 	919-896-2263
winston-salem, NC

Erich Berger   University Accounting Services   414-784-9035  ext. 461.
brookfield, WI

thanks
-- 
Bill Marko			wmarko@ub.d.umn.edu	internet
UMD Information Services	wmarko@umndul		bitnet
10 University Drive		218-726-8842		work
Duluth, MN   55812		218-724-7617		home

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 22:19:02 GMT
From:      bartont@next2.msci.memst.edu (Tom Barton)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: Is there a PC or NLM RARP server?

In article <29448@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson drilex1) writes:
>Does anyone have an RARP server which can live in a PC, or even
>better can run as an NLM?  I know one shouldn't be too hard to write,
>especially for the PC, but it would be even easier to find one.

The NOS version of ka9q includes an RARP server. It's obtainable via anonymous
ftp at ucsd.edu:/hamradio/ka9q/nos. Look in other subdirectories of
/hamradio/ka9q for documentation and other variations on ka9q.

-- 
Tom Barton			       Internet: bartont@next2.msci.memst.edu
Department of Math Sciences	         Bitnet: bartont@memstvx1
Memphis State University	          Phone: 901-678-2527

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      3 Jul 91 23:21:19 GMT
From:      jay@retix.retix.com (Jay Logue)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services

In article <EMV.91Jul2194321@bronte.aa.ox.com> emv@msen.com (Ed Vielmetti) writes:
>
>Concrete support is lacking on all fronts.  For instance, go into any
>U.S. city with an NSFNET NSS and try as a small business to get
>Internet access.  You'll find it somewhere between very expensive and
>impossible in all but a few cases.  Try then to get a small business
>on the net that actually provides services over the net and sells
>those services to paying customers on the net, and you'll find it even
>more difficult.  There are vested interests which do not want the net
>to be accessable at low cost, that do not want to see innovation
>(unless they are being funded to do that work), and that abhor
>competition.   "Conspiracy in restraint of trade" is the phrase that
>naturally comes to mind.
>

Care to be specific?  Who are these "interests"?

>
>-- 
>Edward Vielmetti, v.p. research, MSEN Inc. 	 	emv@msen.com
>
>"often those with the power to appoint will be on one side of a
>controversial issue and find it convenient to use their opponent's
>momentary stridency as a pretext to squelch them"


Jay Logue

===============================================================================
Retix

USMail: 2644 30th Street, Santa Monica, CA 90405-3009 U.S.A
   Tel:	(213) 399-1611
   Fax:	(213) 458-2685
 Telex: 4944307
E-mail:	jay@retix.retix.com
 X.400:	C=US;ADMD=TELEMAIL;PRMD=RETIX;O=OSI ONE;S=LOGUE;G=JAY
===============================================================================

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 91 06:39:07 GMT
From:      k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
To:        comp.protocols.tcp-ip
Subject:   Re: NIC.NSF.NET

HANK@VM.TAU.AC.IL (Hank Nussbacher) writes:

>I can ping it by number but by name it seems as if it has lost its nameserver.
>Is anyone else having problems getting to nic.nsf.net (35.1.1.48)?

Yes, I've tried it, and the nameserver response was somewhat ugly.
Looks like they removed the A record, and installed a MX that points
to nnsc.nsf.net

> nic.nsf.net.
Server:  charly.bl.physik.tu-muenchen.de
Address:  129.187.160.10

*** No address information is available for nic.nsf.net.
> set qt=ANY
> nic.nsf.net.
Server:  charly.bl.physik.tu-muenchen.de
Address:  129.187.160.10

nic.nsf.net     preference = 0, mail exchanger = nnsc.nsf.net
nnsc.nsf.net    inet address = 192.31.103.6
nnsc.nsf.net    inet address = 128.89.1.178
> nic.nsf.net.
Server:  charly.bl.physik.tu-muenchen.de
Address:  129.187.160.10

Non-authoritative answer:
nic.nsf.net     preference = 0, mail exchanger = nnsc.nsf.net
Authoritative answers can be found from:
nnsc.nsf.net    inet address = 192.31.103.6
nnsc.nsf.net    inet address = 128.89.1.178
nnsc.nsf.net    inet address = 128.89.1.2
NS.NIC.DDN.MIL  inet address = 192.67.67.53
AOS.BRL.MIL     inet address = 192.5.25.82
AOS.BRL.MIL     inet address = 128.20.1.2
AOS.BRL.MIL     inet address = 128.20.0.7
AOS.BRL.MIL     inet address = 192.5.25.114
AOS.BRL.MIL     inet address = 192.5.25.66
A.ISI.EDU       inet address = 26.3.0.103
A.ISI.EDU       inet address = 128.9.0.107
C.NYSER.NET     inet address = 192.33.4.12
TERP.UMD.EDU    inet address = 128.8.10.90
NS.NASA.GOV     inet address = 128.102.16.10
NS.NASA.GOV     inet address = 192.52.195.10
> set qt=a
> nic.nsf.net.
Server:  charly.bl.physik.tu-muenchen.de
Address:  129.187.160.10

*** No address information is available for nic.nsf.net.
>

Sincerely,
Klaus Steinberger

--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
BITNET: K2@DGABLG5P             Internet: k2@bl.physik.tu-muenchen.de

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 91 11:42:52 GMT
From:      eckert@immd4.informatik.uni-erlangen.de (Toerless Eckert)
To:        comp.protocols.tcp-ip
Subject:   Geographic position (Was Re: Visual Traceroute)

From article <Q6AAN9@cs.widener.edu>, by brendan@cs.widener.edu (Brendan Kehoe):
> I just had an idea .. I'm curious if it's been done, or considered, or ..

As for visual traceroute, there is really only one small thing missing:
How to get from an ip-address to a geographic position. The most
simple solution woulde be some kind of hack a POSITION RR into the DNS,
or maybe get an agreement how the position information could be
encoded into a TEXT RR. This last approach would be the most usable as
of today, because the first requires modifications to the nameserver sources,
and the second not.

Maybe there is already such an agreement ?

The clean way of course would be to include such geographic information
in the MIB. Currently there is only a sysLocation element in the MIBII
and this is only for informational purposes so that the actual geographic
location is not available.

---

             Toerless.Eckert@informatik.uni-erlangen.de
    /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=Eckert/G=Toerless
    ... "abuse" means you didn't write a proposal and get grant money,
    otherwise it's "research". -- Edward Vielmetti

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 91 12:17:37 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   Re: Network maps in PS format V1



 >This document is meant to catalog all known network maps in postscript
 >format that are available via the Internet.  One purpose is so that people

and RIPE are always complaining about people wasting bandwidth:-)

this kind of announcement will lead to untold numbers of people
ftp-ing all these (large)  files from all these places --

here is a very good opportunity for NICs to show their strength, and
collect these all in a good oldfashioned hierarchica; way (did i hear
someone say archie or whatever happened to inter-NIC?), and make them
available locally (compressed)

also, let me point out that good maps are drawn using some structured
editor so that the map can be re-read in to be updated (rather than
hacked in raw postscript)

this often means that there is a version of the map in a much smaller
format, which could be shipped with a variety of converter programs
(we use autocad) to output to more than just postscript printers

i urged someone (i forget who) at INET to go round writing down all
the beautiful maps that were being drawn of eastern europe, soth and
central maerican and USSR networks as these are a fantastic
psychological help to fixing broken networks, and would make a great
addendum to a new edition of the MATRIX (or the online version if it
ever appears)...

jon

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 91 17:32:16 GMT
From:      peterd@cs.mcgill.ca (Peter Deutsch)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services

In article <scs.678544338@wotan.iti.org> scs@iti.org (Steve Simmons) writes:
>pte900@jatz.aarnet.edu.au (Peter Elford) writes:
>
>>In article <1991Jun30.083257.17896@cs.mcgill.ca>, peterd@cs.mcgill.ca (Peter Deutsch) writes:
 
>>|> I would love to see each and every person coming onto the
>>|> net receive a "welcome package" of basic tutorials,.  .  .
 .  .  .
>>This stuff *must* come from the regional networks. Local
>>variations about where the nearest servers are, details on 
>>local libraries, phone numbers, site contacts can not be 
>>developed centrally.  
> 
>This is a much more difficult task than you would think.  [[Don't get me
>wrong, I agree it needs to be done.]]  There is no document which 
>will permit the computer-naive to sit down and use ftp at all, let 
>alone permit them to unpack and build what they receive.  For example, 
>a guide to file sharing is useless to those who have no conception of
>what a file is.

Who says they need to get one document? If I were king
there'd be an envelope they receive, containing a range of
booklets. The cover of each would indicate what it was, in
clever graphics and with simple, obvious titles (like "A
Pocket Guide to the Internet" - And Hey, I used it here
first!  That title is mine! :-) then a more detailed
exposition, then a one page summary for each tool. We also
need courses, magazine articles and more. We need _user_
support services.

> 
>There's also a horrible catch-22 here.  Any document which is complete 
>enough to describe "the net, email, news, file sharing, ftp and 
>whatever follow-on to archie we can put together, plus . . ." will be 
>quite large.  A naive user faced with such a document typically turns 
>to you and says "can't you give me a simple guide?"  The answer is of 
>course "no, it's a complex answer."  What is needed is a way to provide 
>service to the naive user, not train them to be experts.

Well, there was once a time when you looked at your
neighbor's horseless carriage and said "hey, that's neat.
Can you tell me in simple terms how to run one of those
thing-a-me-bobs?" and the answer was "Sorry, but you need
to know about cylinders and compression and double-clutching the
non-synchronized transmission, and what to do if
the crankcase leaks, and oh, yeah the magneto for the
ignition system is a flakey item and should be rewound and
don't forget to strain your fuel, and no, kerosene wont
work and this model uses a tiller and that one a wheel,
and..."

You get the idea. Now you can jump in your Japanes
econobox and, without any knowledge of the wonderful advances
in metallurgy and automotive engineering, go buy a pint of
milk. The cars are infinitely more complex, but infinitely
easier to use (they also come in more colours... :-)

If we can't present the information distribution paradigm
in a relatively simple manner, maybe it's _NOT_ just that
we're so smart and they're so dumb.  Maybe our paradigm
isn't finished yet?  Just my own opinion, but the basic
_services_ we could offer here (as opposed to the
technology to deliver thoses services) are actually rather
straight-forward. We just haven't figured out how to
package and describe them yet. My original thesis can be
reworded to be "I think it time we focus on this part, folks".

For what it's worth the paradigm I would like to push for
information distribution is that of the "Electronic Book
Store" (for those who've seen my raves on this, I promise
to keep this short).

Basically, I would love the time to build an on-line
equivalent to the conventional bookshop. Each host would
be an "information store" and each participating user
would have a "shelf" or "stack" in the store. Anyone could
put info on-line, others could (automatically) call in and
query the "info-objects" on author, title, subject, and
other typed attributes.

Each of us would be "publishers" and would own our work.
Users would talk of "peterd@cc.mcgill.ca's recent paper"
and "whatever@whereever.fi's racy pictures" and even
"archie@quiche's responses to my recent questions".  The
metaphor is simple to explain. The technology is doable
now. Our frontends would be smart and friendly, our water
would be pure and there'd be world peace in our time.
(Well, maybe we can't have the clean water... :-(

Okay, I'll get off the soapbox, but I do think we should
look at our technology a bit. I spent this morning with a
quite bright high school teacher who's looking at setting
up an on-line bulletin board for other teachers. He was a
little baffled by the sequence needed to login and run a
conventional newsreader on our UNIX machines. His fault? I
think not. rn as the electronic cork board? Not yet,
folks. The metaphor is simple, the current implemention
sucks the big one for most would-be users.

>IMHO the answer will be computer usage service folks.  Few of our
>researchers do their own database searches -- they describe their query
>to our librarians, and the librarians navigate thru the databases.  A
>similar thing already occurs with email -- naive users go to their local
>postmasters for hard questions.

In my original posting I _did_ make a rather off-hand
comment to the effect that we could eliminate tech report
librarians with proper technology, and at least one person
called me on it in email. Okay, I admit that I was waxing
eloquent and didn't really mean it. What I meant to say
was that we should be educating our librarians, and
working with them to develop tools so that people _could_
do the simple accesses and the librarians _could_ do the
complex ones. Currently it takes a real UNIX weenie to get
the most of the Internet. There's just not enough of us
UNIX weenies to go around!

As for the information - I believe that currently only a
fraction of what could and should be on-line is actually
out there. I'd love to see a lot more info, and the tools to
access that data in a clean and straightforward manner.  A
follow-on to archie, the Prospero work, the WAIS work, all
are pointing us in the right direction. I actually have
high hopes that two years from now we're all going to look
back and be amazed at what we've done. Still, we do need
debate on where we should go, how to get there, and what
we'll do when we arrive. (we also need money. And you
thought I'd get through an entire posting without saying
the word "money"? :-)

				- peterd


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

>> Zen Master to hot dog vendor:  "Make me one with everything."
> 
> Um, not to get too serious here, but Zen Masters don't want to be one
> with everything.  "Great Yogi to hot dog vendor" would be better, except
> they don't eat hot dogs.
> 
.  .  . What do great Yogis eat, besides picnic baskets......?

			 - So, like this .sig has spawned a thread!

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

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 91 18:35:19 GMT
From:      ELESKG@NUSVM.BITNET (Winston)
To:        comp.protocols.tcp-ip
Subject:   SUMMARY: TCP/IP FOR IBM MVS/XA MAINFRAME

I received a number of responses from the net regarding a TCP/IP package
for linking SUN workstations and an IBM MVS/XA mainframe. Most of them
recommended the TCP/IP software that is developed by IBM themselves.
There are also a few other alternatives, the most popular of which is
Interlink Computer Sciences, Inc. I have done some editing on the emails
that I received and appended them to this message.

Lastly, I would like to thank everyone who responded.

Winston Seah
========================================================================
<<<<<< Responses/Recommendations/etc >>>>>>

There are several packages available for MVS.  Whether they are "good" or not
depends on your point of view!

ACC (Advanced Computer Communications?) produces a package called ACCES/MVS.
Of course, IBM also produces its' own TCP/IP package.

There is a lot of development going on within IBM - you can tap into a lot
of discussion between users and the developers at IBM through the IBMTCP-L
mailing list on BITNET.  IBM has been very helpful and honest on this mailing
list, quite a shock for some of us old IBM users!

----------------------------------------------------------------------
John K. Scoggin, Jr.
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		Fax:	(302) 451-5321
500 N. Wakefield Drive			Email:	scoggin@delmarva.com
Newark, DE  19714-6066
----------------------------------------------------------------------
=========================================================================
We are using the TCP/IP marketed by IBM and have had execellent experience
with ftp and rpc.  We have not tried nfs.  Release 2 has just become
available.
--
Betty Jo Armstead              SVERDRUP Technology Inc.
21000 Brookpark Rd.Ms 142-2    Phone:216-433-5086
Nasa Lewis Research Center     FAX: 216-433-8000
Cleveland Ohio 44135           From: xxbja@csduts1.lerc.nasa.gov
=========================================================================
i believe ibm has a tcp/ip package which has the functionality u need
from what u have said above.  i would then expect that u would use a
tn3270 package on your suns to access the ibm via tcp/ip.

there are packages out there which will allow for full screen telnet
into the ibm if u need that capability as well.

--
Bill Marko			wmarko@ub.d.umn.edu	internet
UMD Information Services	wmarko@umndul		bitnet
10 University Drive		218-726-8842		work
Duluth, MN   55812		218-724-7617		home
=========================================================================
Use IBM's MVS TCP/IP Version 2 software with a BTI ELC2 in 8232 mode
to provide the IBM to Ethernet interface.

You may also want to look through the archives of the IBMTCP-L which
discusses the IBM TCP/IP products.

Richard Hintz  opsrjh@uccvma  hintz@oz.ucop.edu
University of California
=========================================================================
Interlink Computer Sciences supplies this capability with the SNSTCP package
and the channel attached ethernet interface(called 3722).  SNSTCP provides
the complete internet protocol suite at high performance/low cpu utilization.
A very nice Application Program Interface(including assembler, sockets,
and RPC), Network File Server, and Remote Tape Dump/Restore are also available.
The corporate office is:

Interlink Computer Sciences, Inc.
47370 Fremont Blvd.
Fremont, CA 94538
(415) 657-9800

Sincerely,
Steve Morgan
spm@interlink.com
(301) 317-6600
=========================================================================
This isn't exactly what you're asking for, but my company's network
(UltraNet) includes TCP/IP connections for both IBM MVS and Sun,
although it is a hardware REPLACEMENT for Ethernet rather than
software to run over it.  [Sort of like adding FDDI cards to the Suns
and IBM, although up to ten times faster.]  We have several customers
doing essentially what you described (many Sun workstations and an IBM
[or equivalent] mainframe providing database support), so we must not
be TOO expensive ...  :-)

Let me know if you'd like more information.  I'm a software engineer,
not a marketing or sales type, but I'm sure there are sales types that
would be more than happy to talk with you!  [:-) again]

wayne

    Wayne Hathaway               domain: wayne@Ultra.COM
    Ultra Network Technologies     uucp: ...!ames!ultra!wayne
    101 Daggett Drive             phone: 408-922-0100 x132
    San Jose, CA 95134           direct: Hey, you!
=========================================================================
IBM's own product seems to do the job quite well.  If you want more
info on how it works here, you might drop a line to Keith Dinicola,
who is an MVS programmer here (DINICOLK@ARIZVM1.BITNET).

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Telecommunications, Tucson AZ 85721
=========================================================================
IBM and Interlink Computer Sciences both have TCP/IP products
for MVS/XA.  We run the Interlink product (SNS/TCPaccess).

Roger Fajman                                   Telephone:  +1 301 402 1246
National Institutes of Health                  BITNET:     RAF@NIHCU
Bethesda, Maryland, USA                        Internet:   RAF@CU.NIH.GOV
=========================================================================
There is access mvs.  IBM also has a tcp/ip product for MVS.

Even though we run access mvs here I would get a trial version of
the ibm tcp/ip product.

Both will require more hard ware.

We use tcp/ip over a hyper channel with the access mvs product.
We have looked at the IBM product.  It was too slow for us at the time
but that was last year so IBM may have fixed this problem.

Bill Jones
=========================================================================
    We are using the IBM's TCP/IP packet for our MVS/XA mainframe for
the last year and a half.  It work pretty well in the most parts.  However,
our admin users are only using the tn3270 and ftp to access the systems.
We did not run any sendmail or nfs on the mailframe.  All those funtions could
be served better by using some real unix system like Ultrix or SunOS.

   The problem you might have with the IBM's TCP/IP software is the terminal
emulation.  If a user telnet out on the IBM mailframe from a 3270 terminal to
a non IBM system, they might have the difficultly on the terminal display.
If the remote system's telnetd has "line mode" implementation, the result is
not that great either.

   The Interlink's tcp/ip software for the IBM MVS system will know how to
handle these terminal emulation problem.  We did not use that software here
but I have heard a good review for it on the network.

--
Hock-Koon Lim, Information Network services
Case Western Reserve University; Cleveland, Ohio, USA  44106
(216) 368-2982        lim@ins.cwru.edu
=========================================================================
I know of two vendors who provide TCP/IP for MVS/XA Mainframes.

One is Fibronics/Spartacus Engineering Division which can
be reached at (617) 937-1600 (they will refer you to a salesman
in your area).  Their address is

	Fibronics/Spartacus
	One Lowell Research Center
	847 Rogers St.
	Lowell, MA (don't remember the ZIP).

I used to work at Fibronics.  They sell a stable, usable TCP/IP
which tends to lack some advanced features, but has a very nice
telnet server program which accepts logins from many terminal
types without need to use TN3270 on the remote host.

IBM also provides a solution.  I don't know specifically how
to reach them, but they have offices everywhere.  Their TCP/IP
tends to have more advanced features, but when I saw it, it
was not yet stable.  That may have changed, since I have only
seen their earliest releases.

The best solution overall is reported to be the IBM software
on top of the Fibronics hardware (the K2000).  If you call
Fibronics, they may be able to give you details on how
to make this solution work.  It may involve unsupported software.

Good luck with this!

Sincerely,

Margaret Forsythe    Technical Support Manager    FTP Software, Inc.
(617) 246-0900       FAX:  (617) 245-7943         E-mail:  mrf@ftp.com

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 91 19:04:57 GMT
From:      jcurran@bbn.com (John Curran)
To:        comp.protocols.tcp-ip,comp.archives.admin
Subject:   Re: On the need to develop Internet user services

In article <WORLEY.91Jul3102926@sn1987a.compass.com> worley@compass.com (Dale Worley) writes:
>The NSFnet is specifically forbidden from carrying commercial traffic.
>Thus, although a commercial information service can buy network
>service from several vendors, it can't talk to the vast bulk of the
>potential customers, who are only connected through the NSFnet.  It's
>as if the phone system served only residences, and a business wanted
>to use a telephone for talking to customers, but wasn't allowed to.
>The explanation "you can connect to another phone system serving only
>businesses" doesn't cut it, because the people you want to talk to are
>on the existing phone system.

  This is quickly becoming a non-problem.  Many mid-level networks are
  already interconnected to allow commercial traffic.  There is already
  a large base of unrestricted networks in the US which looks more than
  sufficient to support startup information providers.

>Interestingly, although the NSFnet plans to go to a pay-as-you-go
>system for funding, there are no plans to allow commercial usage,
>although pay-as-you-go eliminates the one real objection to commercial
>usage: the government shouldn't subsidize commercial users.  (Of
>course, in most of Europe that wouldn't be considered an objection...)

  Hmm..  I might be under the wrong impression, but I am fairly sure
  that you can or will be able to obtain access to backbone very similiar
  to the NSFNET backone for commerical traffic very soon now..

>A further barrier is that an astonishing fraction of the users of
>NSFnet have a deep, visceral objection to commercial information
>services.  Frankly, I don't understand where it comes from, but it's
>there, and it's intense.  Consider the flamage Ed Vielmetti got when
>he proposed that he sell the information he had previously prepared
>for free!  And there have been many other cases as well.  Of course,
>some of the objections have been quite reasonable, but if you examine
>the whole tenor of the discussions of commercialized information on
>The Net, it is clear that most of the users have a decided prejudice
>against it.

  This is quite true.  One of the most valuable aspects of the current
  Internet is that while it costs money to connect, the information that's
  available via it is *free*.  It's hard to imagine what the Internet would
  be like today if there were a charge to use most services.. I'd wager 
  that many sites would disconnect. (Imagine trying to budget for it..) 

>Remember, commercialized information services need not be more
>expensive than the present system.  After all, we are already paying
>for the present system, through taxes.  And commercialized systems can
>be astonishingly inexpensive if competition works smoothly -- the U.S.
>probably has the cheapest long-distance telephone service in the
>industrialized world (figuring in subsidies) precisely because it has
>the most capitalist long-distance telephone service.  (AT&T could
>probably reduce its rates by 10% if it just stopped running all those
>commercials!)  It has gotten to the point that ordinary people feel
>little concern about the expense of placing long-distance calls, when
>even twenty years ago, they were reserved only for important messages.

  Certainly that model (information providers competing ala long-haul carriers)
  would work, but much of the current lethargy in commercializtion of 
  information comes from not aving model that preserve the current "flavor"
  of the Internet (i.e. maintaining the utility of the Internet to those
  who can't absorb a pay-foruse service).  A typical conflict is 
  comp.archives versus a funded search and archival service.  There will always
  be a "free to the user" service (even if someone has to volunteer to run it)
  and yet it's very existence dilutes the demand for a higher-quality at-cost
  effort.
 
  So here's the summary:
 
    Many people want "richer" services than the current Internet offers.
    Many people cannot/will not be able to pay to purchase these information
      services from individual providers, and hence want NSF/DARPA/someone else
      to pick up the cost.
    The NSF is quite understandably trying to extract itself from funding what
      an operational network, and would probably not be interested in paying 
      for the OPERATION of improved information servers. (Note that research
      into information sharing tools and technology is another matter..)

  The only way I see to provide better information services, and accomodate 
  the above is for the Network Providers (i.e. mid-levels, regionals, etc..)
  to solicit, fund, and incorporate these commericial information services 
  into their offerings.  Most network providers can share the cost among many
  members, and there's a good potential for competition between information
  services for a given network provider.
 
  There is some infrastructure needed for the above:
 
    Commercial providers have to insure "commercial level" access to any
    network provider they're going to serve.
 
    Commercial information providers must be able to restrict access to 
    given set of networks (and thus protect their information property)
  
    Network Providers must be able market their purchased information
    services effectively.  Such services may be used to differentiate 
    one network provider from another. 

    Network Providers should incorporate the cost of these services into
    their existing services costs. As long as such costs are not pay-for-usage,
    then the end users will still see the resources made available as "free".
 
/John

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 91 19:07:45 GMT
From:      emv@msen.com (Ed Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Network maps in PS format V1

In article <9107041452.AA01292@ucbvax.berkeley.edu> J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes:

   here is a very good opportunity for NICs to show their strength, and
   collect these all in a good oldfashioned hierarchica; way (did i hear
   someone say archie or whatever happened to inter-NIC?), and make them
   available locally (compressed)

ha.  here we have an example yet again of well funded projects
yielding nothing (inter-NIC), and seat-of-the-pants efforts generating
good results (archie).

the one attempt to collect all of the ps maps (at nis.nsf.net in the
maps directory) is so old and out of date as to be useless.

That's why the good old USA built a T3 network, so that people can
slosh files all over the country without heed for how big they are or
where they originally came from.

--Ed

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 91 19:20:55 GMT
From:      nick@spider.co.uk (Nick Felisiak)
To:        comp.protocols.tcp-ip
Subject:   Re: IP in the World (was UK) (was Fingering the English)

In article <9106241111.AA25830@ucbvax.Berkeley.EDU> J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft) writes:
>
>In terms of real interconnecting networks, we (UCL-CS) had Internet 
>(read ARPANET) access via SATNET from 1976, and UK x.25 access around 
>the same time
>
>they have been very similar in terms of functionality/performance
>ever since ...
>
>(Performance: e.g. JANET-II is 2Mbps about same time as T1 NSFNET, we
>arte going to 34 Mbps aropund this year, while NSFnet goes to T3...in
>fact reliability of JANET is markedly better than most the
>Internnet...
>Functionality: the Internet (wide area) does FTP/SMTP/TELNET, we have
>NIFTP, Grey Book/X.400, PAD/XXX).

I agree that the UK coloured books are substantially functionally
equivalent to the popular Internet protocols.  Unfortunately for the
UK academic community, they are not as popular.  I can't go and get
a tape from a UK university giving me a freely-available base with
which to implement these protocols.  This means that the JNT (the
UK body akin to NSFNET, I suppose) have spent a pile of money (either
directly, or through the Universities whose policies they dictate)
on 'special' versions of products supporting the UK suite.

I know this since I work in a company which makes some of these products.
The simple fact is that the UK University community has spent a lot of
money marching out of step with the rest of the world.

The impact is not limited to cost, either.  If I choose a splendid new
machine from a manufacturer, I can expect it to work on my company's
network the day it arrives.  Someone gives me the next IP address for the
subnet it will live on, and off I go.  If the University down the road
decides it has to have one of these, and has to offer it over JANET,
it (or the supplier, depending on how good a deal was struck)
faces weeks or months of work to provide the UK protocols.

In a 'service' environment, it seems to me that had the JNT
implemented a transition to TCP several years ago, the UK University
community would be served better and cheaper.

>
>now if you want fancy stuff like NFS/AFS, X/NeWS, Video, you dont
>really get that much yet wide area...see paper by Paxson, or me at
>INET'91 or some folks from USC at SIGCOMM '91 for traffic stats...
>
 
>in terms of research, i started at UCL in '81 working on
>interconnected *cambridge* rings running universe datagrams, and byte
>strem protocol, with satellite hops to europe - pretty similar to the
>US research going on at the time...
>
>we now are loooking at 60Mbps ATM networks, and packet voice & video
>in UK & UK-Europe - again pretty similar to what is happening in the
>US
>
>the arguments over what packet format carries the bits over the wire
>are rather long in the tooth - what is relevant is: what *algorithms*
>go in the end systems and routers/switches to give the QoS the users
>want (e.g. reliablilty/throughput/delay versus cost)...

For a researcher into network protocols, these are the right
considerations. For a supplier of network services to computer users,
they are exactly the wrong questions.

>
>the socialogocal/political arguments should be left to
>sociologists/politicians and people who have to argue with European
>Telecom companies who operate a very disruptive cartel similar 
>to that which airline companies have this side of the pond...
>and what ...
>
>jon

I'll second that!

Disclaimer:
I don't usually bother with disclaimers, but this is *definitely* a
personal view.

Nick

-- 
Nick Felisiak 						nick@spider.co.uk
Spider Systems Limited					+44 31 554 9424

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      4 Jul 91 23:41:10 GMT
From:      jerry@ora.com (Jerry Peek)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services

In article <1991Jul3.030900.27683@cs.mcgill.ca> peterd@cs.mcgill.ca (Peter Deutsch) writes:
> I am really glad that we have Internet volunteers to
> provide such services as we have now, but can we seriously
> expect to keep the net growing at the current rate and
> still rely on volunteers for our tools?

I'd like to take a different angle on this.  About four years ago, I
decided to set up a series of shell scripts and directories full of
"ls -R" listings of something like 500 anonymous ftp sites.  To share
the database with other people, I talked our system manager into letting
me store the listings in a few megs of our anonymous ftp area (at
rodan.acs.syr.edu).  Patching it together and maintaining it took a lot
of my free time.  Even though there was a fair amount of use, I got almost
no feedback, no compliments, nothing.  It was a really strange feeling...
knowing that people were using (and, I guess, appreciating) all the work
I put into it... but hardly ever getting a "thank-you".

The point I'm trying to make is that if someone provides a free service
you use, I hope you can offer to pitch in and help... even just a little. 
Free services, free software, arguing for support from management for the
computer, disk space, etc... it can be pretty lonely for the people who
give the service.  Got an old Sun 3/50 in the machine room?  Pretty good
at programming and have a weekend to spare?  Mail the person and offer. 
If you can't help, at least say thanks.

I hope this doesn't sound like sour grapes.  I'm not looking for
sympathy. ;-)  I'm trying to explain what it can feel like to do this.
I bet there are lots of people out there with good ideas but not enough
support to get them rolling... or keep them going enough to catch on.

Enough already!  BTW, I eventually met Alan Emtage as he was getting
archie started.  The archie idea caught on -- I was glad to nuke my
setup in favor of it!  I put in a README file that explained why and
told how to use archie, gave a few weeks' notice, etc.  You could
probably figure:  I got two e-mail messages after I shut mine down...
and both were negative.  Ah, well. :-)

--Jerry Peek, O'Reilly & Associates, jerry@ora.com or uunet!ora!jerry

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 91 00:32:33 GMT
From:      coates@UC780.UMD.EDU
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services

Thanks Jerry!

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 91 01:08:04 GMT
From:      emv@msen.com (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: On the need to develop Internet user services

>  This is quickly becoming a non-problem.  Many mid-level networks are
>  already interconnected to allow commercial traffic.  There is already
>  a large base of unrestricted networks in the US which looks more than
>  sufficient to support startup information providers.

It may look more than sufficient from Cambridge or the Bay Area, but
startup information providers in other parts of the country have it
somewhat rougher.  Things differ tremendously on a state by state
basis; the information provider that could set up shop in one location
in a month would spend considerably longer somewhere else negotiating
their way onto a network that they could afford.  In some locations the
local internet service provider might have not any reason at all to do
anything except obstruct the newcomer's connection because it would
mean competition for customers and maybe state funding.

All completely hypothetical of course :-|		< straight face

--Ed

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 91 01:16:32 GMT
From:      thad@public.BTR.COM (Thaddeus P. Floryan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Throughput over E-net (Trailers)

In article <9107011438.AA13159@sonny.proteon.com> jas@proteon.com (John A. Shriver) writes:
>[...]
>The only machine trailers ever helped was a VAX (who buys them to run
>UNIX anymore?), and the benefit was not worth the compatability
>problems they caused.

Sorry I brought it up; the original poster asked for ANY insight concerning
his alleged performance problems (I still CANNOT believe he was complaining
about 200Kbytes/S ! :-) and RTFM suggested the use of trailers.

Since I received email from John a day or so earlier than his post, I already
removed trailers ("ifconfig {en0 | ae0 | whatever} -trailers" and noticed NO
performance change either on my office's net or my lab's net (both of which
sport a wide variety of hosts ranging from Sun, SGI, AT&T, Convergent/UNISYS,
IBM, Mac, etc.).

My original response suggested disk fragmentation playing an important role,
and as evident from the (consenting?) silence my assessment was correct.

Use of "netstat -i" may also help pinpoint troubles; I just discovered a bad
transceiver (both Ierrs and Oerrs were non-zero) and replaced it giving
marginally better thoughput to/from one host.  Given THIS, I just put
together a cron-initiated script to collect netstat data from all hosts every
night.

Anyone else have tips and techniques for monitoring/tweaking net performance?

Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 91 01:25:12 GMT
From:      thad@public.BTR.COM (Thaddeus P. Floryan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Throughput over E-net (Trailers)

In article <1991Jul1.191134.28197@solbourne.com> imp@solbourne.com (Warner Losh) writes:
>I always thought that Sun picked up the Van Jacobson patches plus did
>some of their own optimization to get these good results.  One older
>version of VMS based TCP/IP system that didn't have the VJ patches did
>about 250K/sec, while another version (that did have the VJ patches)
>did about 300-500K on the same machine against the same sun.

I'm sorry, but my mind just boggles when I see some of the transfer stats
that people post for host-host file transfers.  EVen using some acknowledged
fast machines, I cannot approach those posted numbers (and this includes
systems from Sun, H-P, etc.)

I refer to the "ftp" transfer stats; is there some OTHER method to measure
"disk -> net -> disk" transfer speed?

Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 91 15:23:53 GMT
From:      pww@bnr.ca (Peter Whittaker)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services

In article <1991Jul4.173216.12656@cs.mcgill.ca> peterd@cs.mcgill.ca (Peter Deutsch) writes:
>Who says they need to get one document? If I were king
>there'd be an envelope they receive, containing a range of
>booklets. The cover of each would indicate what it was, in
>clever graphics and with simple, obvious titles (like "A
>Pocket Guide to the Internet" - And Hey, I used it here
 ^^^^^^

Shouldn't that be a "packet guide"....

(is a :-> necessary?)

--
Peter Whittaker      [~~~~~~~~~~~~~~~~~~~~~~~~~~]   Open Systems Services
pww@bnr.ca           [                          ]   Bell Northern Research 
Ph: +1 613 765 2064  [                          ]   P.O. Box 3511, Station C
FAX:+1 613 763 3283  [__________________________]   Ottawa, Ontario, K1Y 4H7

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 91 15:33:02 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Throughput over E-net (Trailers)

In article <3313@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes:
>I'm sorry, but my mind just boggles when I see some of the transfer stats
>that people post for host-host file transfers.  EVen using some acknowledged
>fast machines, I cannot approach those posted numbers (and this includes
>systems from Sun, H-P, etc.)
>
>I refer to the "ftp" transfer stats; is there some OTHER method to measure
>"disk -> net -> disk" transfer speed?

You don't want to use FTP for benchmarking; it is a fairly complex protocol,
especially if you're transferring text (which is *not* transferred by just
copying the bytes to the network), and it's not terribly well implemented
in 4BSD.  To get raw speed measurements, you probably want to write a simple
little program that just opens a disk file and a network connection and
throws bytes from one to the other, with no complications.
-- 
Lightweight protocols?  TCP/IP *is*     | Henry Spencer @ U of Toronto Zoology
lightweight already; just look at OSI.  |  henry@zoo.toronto.edu  utzoo!henry

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 91 19:25:29 GMT
From:      josevela@mtecv2.mty.itesm.mx (Jose Angel Vela Avila)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   KA9Q NOS with bootp server WHERE ??



 Hi folks ..


 Does any body knows where is the KA9Q NOs program that supports BOOTP server
  I have the documentation (ka9qnos.mr) that were in 

	ucsd.edu in /hamradio/ka9q/docs
 And it says that it has bootp server, I try NOS programm from /nos directory
 and it DOESN'T have bootp support :-(

 Help me please !!!


 As allways thanks !!


Jose A. Vela Avila

josevela@mtecv2.mty.itesm.mx

    ITESM

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 91 20:26:05 GMT
From:      dwells@fits.cx.nrao.edu (Don Wells)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services

In article <1991Jul4.173216.12656@cs.mcgill.ca> peterd@cs.mcgill.ca
(Peter Deutsch) writes:
...
   In article <scs.678544338@wotan.iti.org> scs@iti.org (Steve Simmons) writes:
   >pte900@jatz.aarnet.edu.au (Peter Elford) writes:
 ...
   >IMHO the answer will be computer usage service folks.  Few of our
   >researchers do their own database searches -- they describe their query
   >to our librarians, and the librarians navigate thru the databases.  A
   >similar thing already occurs with email -- naive users go to their local
   >postmasters for hard questions.
...
   What I meant to say
   was that we should be educating our librarians, and
   working with them to develop tools so that people _could_
   do the simple accesses and the librarians _could_ do the
   complex ones. 

Yes. Librarians need to view themselves as managers of archives of
_information_, not as managers of archives of cellulose fiber and
carbon particles. Some (many?) librarians do see themselves this way
today.  Computer people who specialize in information retrieval
technology should feel a natural affinity with such librarians, and
should cooperate with them and pay attention to what they know about
providing information access services.

--

Donald C. Wells             Associate Scientist        dwells@nrao.edu
National Radio Astronomy Observatory                   +1-804-296-0277
Edgemont Road                                     Fax= +1-804-296-0278
Charlottesville, Virginia 22903-2475 USA            78:31.1W, 38:02.2N 

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 91 20:31:54 GMT
From:      casey@gauss.llnl.gov (Casey Leedom)
To:        comp.protocols.tcp-ip,comp.dcom.modems,alt.dcom.telecom
Subject:   Looking for ISDN BRI to RS232, RS422, Ethernet connectivity options


  Two problems regarding using an ISDN (Integrated Services Digital
network) BRI (Basic Rate Interface) for data transport:

    1.	Allowing widely used serial devices cheap access to the ISDN
	BRI.  This would allow, say, Macintoshes, PCs, terminals,
	workstations, etc. to use RS232, RS422, etc. to use an ISDN
	line for ``dial up'' applications.

	A device that implemented this functionality would function in
	much the same way as current analog line modems.  In fact, I
	wouldn't be the least bit surprised if such a device offered an
	``AT'' command set ...  Obvious features would be ISDN synchronous
	``B'' channel to standard RS232/RS422/etc. asynchronous bridging
	with buffering and flow control, V.42 and V.42bis for error
	control and compression, etc.

    2.	Allowing ``direct connect'' between ISDN and Ethernet via
	something like a terminal server with various network transport
	protocols like TCP/IP, DECNET, etc. to allow connection to
	network hosts and facilities.

	Our laboratory is currently getting ready to investigate a
	product from Gandalf that does this.  My only experience with
	their products was nearly ten years ago, so I'm interested in all
	opinions about their product line today.

  Note that I am *NOT* interested in special hardware that plugs into
Macintoshes, PCs, workstations, etc. to allow them direct access to the
ISDN BRI.  These devices are just too expensive right now and aren't
available for enough hardware to make it interesting.  I'm looking for
something cheap like an ISDN ``modem'' that can be taken home and allow
people to ``dial in'' and then something on the other end that can allow
people to access the network via standard protocols (although in our my
case I'm only interested in TCP/IP there are others who need DECNET/LAT
and even AppleTalk.)

  Please send all responses directly to me.  I will summarize all
responses back to these groups in a couple of weeks.

  Also, ***PLEASE*** INDICATE ANY INFORMATION THAT SHOULD ***NOT*** BE
INCLUDED IN SUCH A SUMMARY.  I accidentally included information on a
non-announced product in one summary because the respondent didn't tell
me not to include that information even after I'd asked to be told what
shouldn't be included.  I guess it was in too small a type.

  And, just to make sure that doesn't scare you off from sending such
information to me, I'll note that the laboratory has some 12,000
employees, has its own ISDN phone system and is actively looking for ways
to provide ISDN connectivity to its employees in their homes throughout
the Bay Area.  I.e. we're a ***BIG*** potential market.  If you wish, we
will sign non-disclosure agreements, but remember, we're looking for
cheap ways of providing connectivity because we're talking about so many
installations.  I.e. forget about sending me information on absurdly
expensive ISDN ``modems.'' Sorry to be such a hard-*** about this, but I
want everyone to know the ground rules right from the start.

  Thanks for your attention and thanks in advance for your input!!!

Casey

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 91 21:53:59 GMT
From:      seth@ctr.columbia.edu (Seth Robertson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Throughput over E-net (Trailers)

In article <1991Jul5.153302.17217@zoo.toronto.edu> you write:
>In article <3313@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes:
>>I'm sorry, but my mind just boggles when I see some of the transfer stats
>>that people post for host-host file transfers.
 
>To get raw speed measurements, you probably want to write a simple
>little program that just opens a disk file and a network connection and
>throws bytes from one to the other, with no complications.

Two such programs are available in ftp.ctr.columbia.edu [128.59.64.40]
in /pub/net

The first, netout, is a modified version of the original program of
the same name which was written by Thomas Ferrin.  Basically it
determines netwourk throughput by sending to the TCP discard port of
inetd.

The second is that champion of champions, ttcp.  ttcp can act as a
network pipe or as a network throughput tester.

Using netout, I was able to get 6.5Mb/s throughput between two
SparcStation 2s which translated to 7.8Mb/s network usage.


                                        -Seth Robertson
                                         seth@ctr.columbia.edu

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 91 23:17:46 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: On the need to develop Internet user services

In article <64986@bbn.BBN.COM> jcurran@BBN.COM (John Curran) writes:
>  This is quite true.  One of the most valuable aspects of the current
>  Internet is that while it costs money to connect, the information that's
>  available via it is *free*.  It's hard to imagine what the Internet would
>  be like today if there were a charge to use most services.. I'd wager 
>  that many sites would disconnect. (Imagine trying to budget for it..) 

It's certainly true that we've become spoiled by the free services that are
available on the Internet.  However, I don't think that most sites would
disconnect if most service providers charged money.  First off, there's
quite a bit of network use that isn't about using potentially-commercial
services; probably the largest amount of network use is for netnews and
email between users.

I don't think charging money for information services on the Internet need
spell the end.  Commercial information services, e.g. Compuserve, GEnie,
and Prodigy, are doing reasonably well in the real world, using other
networks (Tymnet, Telenet, private networks).  If they were on the
Internet, I'd expect many more people would sign up due to easy
accessibility from their workstations.

As for budgeting, why should budgeting for Internet-accessible information
services be any different from other online information services, or other
services in general?

-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      5 Jul 91 23:25:13 GMT
From:      stevenf@m2xenix.psg.com (Steven Frazier)
To:        comp.protocols.tcp-ip
Subject:   SLIP Scripts

I am looking for a script that would be executed opon a particular
login.  In other words I would like to set up several SLIP scripts on
my SCO Unix machine.  Then when a particular machine calls in with their
password it would execute the correct SLATTACH with the write IP addresses.

If I have done that, and the person logs out (drops the connection) would there
need to be anything else done?

Please email me here or at osu-cis!mcinix!sfrazier

Thanks in advance.

Steve

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 91 07:56:22 GMT
From:      peterd@cs.mcgill.ca (Peter Deutsch)
To:        comp.protocols.tcp-ip
Subject:   On paying for the Internet (was: Re: On the need to develop . . . )

In article <64986@bbn.BBN.COM> jcurran@BBN.COM (John Curran) writes:
>In article <WORLEY.91Jul3102926@sn1987a.compass.com> worley@compass.com (Dale Worley) writes:
 .  .  .
>>some of the objections have been quite reasonable, but if you examine
>>the whole tenor of the discussions of commercialized information on
>>The Net, it is clear that most of the users have a decided prejudice
>>against it.
>
>  This is quite true.  One of the most valuable aspects of the current
>  Internet is that while it costs money to connect, the information that's
>  available via it is *free*.  It's hard to imagine what the Internet would
>  be like today if there were a charge to use most services.. I'd wager 
>  that many sites would disconnect. (Imagine trying to budget for it..) 

Sorry, but I have to take exception to this. The
information is NOT free, it is merely provided to the
users for a flat fee - not the same thing at all...

Oh, but you argue, "I didn't pay anything for this
information!" Yes you did.  Maybe you paid a subscription
directly at the start of the year, or maybe your Dean had
to forgo the budget increase to pay for your network link,
but somewhere along the way money is changing hands. As a
former systems manager who had to find the $1,500 a month
in line charges for our link to CSnet I know this for a
fact. Rest assured, each and every one of you is paying
for access to archie and the other Internet services. The
only problem I see is that nobody's figured out how to get
the money to us up here in Montreal! :-)

To be fair, I'm probably being a little pedantic here. The
point perhaps was that most of us are living in a world
where we can budget for a flat annual fee but can't cope
with charges that increase with usage. This is true and I
agree that it is a real problem. We have the potential for
a fabulous information resource here, but I believe that
we are going to have to find ways to pay people for
providing services if we are going to realize the
potential of the network.  Note that I didn't say "charge
people for access". We've already figured out how to do
that and we've got them convinced it's free! ;-)

The current world view does encourage people to think that
Internet services are their "right" or that currently they
are provided for nothing. What a marketing coup! No wonder
net access is growing so fast...

>
>  Certainly that model (information providers competing ala long-haul carriers)
>  would work, but much of the current lethargy in commercializtion of 
>  information comes from not aving model that preserve the current "flavor"
>  of the Internet (i.e. maintaining the utility of the Internet to those
>  who can't absorb a pay-foruse service).  A typical conflict is 
>  comp.archives versus a funded search and archival service.  There will always
>  be a "free to the user" service (even if someone has to volunteer to run it)
>  and yet it's very existence dilutes the demand for a higher-quality at-cost
>  effort.

Well, I have already argued in a previous posting that I
feel at least part of the problem is due to a lack of
emphasis on providing services (charged or free) as we've
built the network infrastructure. In effect, we've been
saying "let the users decide what to do with it, we have
to get the line speed up". This, and an apparent fear of
commercial packets sullying our wires, I believe are
behind the current lack of services.  The attitude against
commercial traffic is changing, and I for one think this
will help us in the long run. I also see a shift in
attitude that I hope will encourage support for
information providers as part of the infrastructure.  That
will help, too.

And I would add that I don't think that there's anything
wrong with "free to the user" services, in principle.
After all, that's what drives most of the U.S. television
industry and when you think about it, that's exactly the
model the Post Office uses for your mail.

You can be sure that you are paying for every episode of
"I Dream of Jeannie" and "Seseme Street" whenever you go
down to the supermarket file an income tax return and you
pay for every bill and piece of junk mail to be delivered
to your door. You're just not paying the Post Office
directly...

There really is no such thing as a free lunch.  Either you
pay in advertising or through your taxes, but ultimately
the consumer is paying the full price of the service.  The
question is only how fair and efficient is the payment
mechanism back to the providers.

For what it's worth, I see the Free Software Foundation GNU
project in the same light. I love their work, but I don't
tell people that their software is free. If NeXT gives
them a dollar, I can assume that I will pay my share of
that dollar on my NeXT workstation (if you'll pardon the
pun :-) If people prefer to pay for it that way, so be it,
as long as it works. In the case of the Free Software
Foundation we've figured out how to pay people to write
useful software. I expect we'll figure out how to do it
for Internet services of various strips and hues as well,
given time.

>  So here's the summary:
> 
>    Many people want "richer" services than the current Internet offers.

True.

>    Many people cannot/will not be able to pay to purchase these information
>      services from individual providers, and hence want NSF/DARPA/someone else
>      to pick up the cost.

Not necessarily. As one of the providers of archie, I can
say that we get a _LOT_ of letters of gratitude and I can
only ever recall one flame (somebody criticized our user
interface. For what it's worth, he was right. In our
defense, it's not done yet...)

Now I'm sure many of those people who wrote us would be
happy to drop a nickel in a box each time they used our
services.  Currently, there really no practical way to do
that, so we go hungry, but don't sell the average user short.
Just because we don't have an infrastructure in place for
charging doesn't mean that nobody will pay when given the
chance.

Of course, there are free-loaders, but I happen to believe
that most people, given the choice of quality information
at a price or volunteer services or dubious reliability
will take the quality goods when it matters to them. I
also believe there are enough times where it matters to
support quite a lot of providers.

Now a lot will depend upon the quality of their services,
the ease of use and the support they can give. If we need
an infrastructure to be able to provide information
services, that let's design it. The need and willingness
to pay are there now.


>    The NSF is quite understandably trying to extract itself from funding what
>      an operational network, and would probably not be interested in paying 
>      for the OPERATION of improved information servers. (Note that research
>      into information sharing tools and technology is another matter..)

Well, we've probably all heard it said that the Internet
is like a highway system. Now, most highways are freeways,
not tollways. In general, societies have decided to fund
such services from general tax revenue since this is
somehow perceived to be the best/fairest/most
efficient/most whatever way to do it. I would expect that
we will continue to fund our "information highways" on the
same basis, for the same reasons, although maybe the
funding agency will change. Of course, there's a big
debate coming up about who gets to drive on this
particular stretch of road, but that's probably best left
to another thread.

So let's continue to beat this poor simile for a while.
If the Internet is like a highway system, then are service
providers like trucking companies? Or are they more like
traditional merchants, shipping goods over the highway
system? I think the later, perhaps with an emphasis on
mail order shopping. The problem has been that in our
environment we've tended to focus on the delivery
mechanisms, not the goods being delivered. In fact most of
the expense in a commercial transaction is traditionally
for the value of the goods, not the transport and
delivery. We shouldn't loose sight of that.

And so how do we currently fund our mail order merchants?
Well, sometimes you pay when the package is delivered to
your door, and sometimes you pay with your credit card
number when ordering. Sometimes they send you a bill and
sometimes you pay in advance. How are we going to
do the equivalent with our information servers?

Well, maybe some people will pay for access codes and
connect time (a la Compuserv). Maybe people will use
front-end access software that does the accounting (an
Internet postage meter? You heard it here first, folks).
Maybe we'll see a sudden explosion of growth in pay per
byte networks. I would bet the farm on the last one, but
the first two are real possibilities. There will be others,
too. We need an infrastructure for this, so the price of
collecting doesn't swamp the cost of the transaction. If
we're going to have pay as you go, we're going to have to
look at integrating this into the network structure.

The is a fair while away, if we ever get around to it.
That's what I think that our regionals and other interested
parties who already have fees coming in should help us
service providers out. In the long term we may have
efficient collection mechanisms.  In the short term they
are the ones in the position of handling the cash and
should take responsibility for spreading it around where
it's needed.

>  The only way I see to provide better information services, and accomodate 
>  the above is for the Network Providers (i.e. mid-levels, regionals, etc..)
>  to solicit, fund, and incorporate these commericial information services 
>  into their offerings.  Most network providers can share the cost among many
>  members, and there's a good potential for competition between information
>  services for a given network provider.

I agree that the regionals have a role as information
providers, but God forbid that they be the only ones. I
hope (and expect) that we will solve the billing problems
and we'll get information servers you've not yet dreamed
of. Once we get the mechanisms in place and build a market
I predict that we'll have information cornucopias to
choose from. (God, I'm a Pollyanna sometimes! :-)
> 
>  There is some infrastructure needed for the above:
>    one network provider from another. 
 .  .  .
>    Network Providers should incorporate the cost of these services into
>    their existing services costs. As long as such costs are not pay-for-usage,
>    then the end users will still see the resources made available as "free".

I agree that for the short term, network providers should
include information services as part of their
infrastructure cost. I also agree that many people still
see the Internet as the electronic equivalent of air, free
for the taking. That's really our own fault (if in fact it
is a fault) and we should be working on education so
people know some of what involved in all of this.

We should also be working on efficient, effective ways for
charging per service. This should not be an impossible
task. After all, Bell has solved this problem for the
telephone service and cable companies now have pay per
view movies. Are we not just reinventing the wheel here?
The trick is to define the model we want to work with.
Once we have that the rest should fall out fairly easily.



				- peterd

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

>> Zen Master to hot dog vendor:  "Make me one with everything."
> 
> Um, not to get too serious here, but Zen Masters don't want to be one
> with everything.  "Great Yogi to hot dog vendor" would be better, except
> they don't eat hot dogs.
> 
.  .  . What do great Yogis eat, besides picnic baskets......?

			 - So, like this .sig has spawned a thread!

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

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 91 08:05:33 GMT
From:      peterd@cs.mcgill.ca (Peter Deutsch)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services

In article <DWELLS.91Jul5152605@fits.cx.nrao.edu> dwells@fits.cx.nrao.edu (Don Wells) writes:
.  .  .
> .  .  .  Computer people who specialize in information retrieval
>technology should feel a natural affinity with such librarians, and
>should cooperate with them and pay attention to what they know about
>providing information access services.

Well, I use to consider myself quite a UNIX weenie, but in
the past couple of years I've developed a lot of sympathy
for those who find our technology "Not Yet Ready for Prime
Time". I now am fairly irritated when I heard a UNIX
zealot rubbish naive users or even make the usual gross
assumptions about what to consider "intuitive".
Conversely, I have a _lot_ of sympathy for librarians and
would love to give them the tools to enter my world.
There's a lot of neat stuff about to happen at the
junction of these two worlds.


				- peterd

^X ^I .signature

------------------------------------------------------------------------------
+-------+ 	Peter Deutsch		Computing Centre,
| u # u |	peterd@cc.mcgill.ca	McGill University
|/\/\/\/|	
| a   a |	"Well she turned me into a newt!"
 \  a  /	"A newt?"
  \___/         "I got better."
------------------------------------------------------------------------------

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      6 Jul 91 11:40:38 GMT
From:      sac@Apple.COM (Steve Cisler)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services

I agree with Peter Deutsch that there are not enough Unix experts
to handle the flood of questions that current Internet citizens
will receive from new immigrants. 

As a member of the Coalition for Networked Information, an org
comprised of cs people and library staff who share Peter's goals,
there are a number of working groups devoted to directory services,
user education, and publishing ventures.

My own job at Apple has been with giving input on projects such
as WAIS and in showing librarians the kinds of tools that are
available on the Internet.

Shortly, there will be a 90kb guide to library services on the Internet
and Bitnet. Once the draft is finished I'll post a pointer.  The ascii
file is free; the printed version will be very cheap. It was all done
by net-savvy librarians.

Steve Cisler
Apple Library
sac@apple.com

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 91 06:45:56 GMT
From:      emv@msen.com (Ed Vielmetti)
To:        comp.archives.admin,bit.listserv.pacs-l,comp.protocols.tcp-ip
Subject:   Re: COSINE Information Service


Forwarded in the hopes that it'll provide some insight into the
efforts that other computer networks outside of the US are putting
into network services.  The emphasis appears to be on European
services rather than general internet, and on OSI protocols rather
exclusively; but it is interesting and refreshing to have a federally
sponsored effort actually ask network users what sort of information
they would like to get at.

In my own response I sent back information about WAIS, archie,
comp.archives, the U of Michigan "Weather Underground", and a few of
my favorite library catalogs.  Perhaps the Europeans can be convinced
to take care of the USA's "network roadmapping" needs :-)

--Ed

Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
	     MSEN Inc. 628 Brooks Ann Arbor MI 48103 USA
questions about MSEN products & services please send to info@msen.com

   From: foest@ZPL.DFN.DBP.DE
   Subject:      COSINE Information Service

(Rough translation from the original German as found on dnet.inet, all
errors mine!)

A European information system is being built within the framework of
COSINE.  The consulting firm "Level-7" has a contract to do this work
in cooperation with the University of Brussels.  Level 7 is sending
out a questionaire to all member networks, see the attached message.
It would be best if as many as possible would answer this questionaire
-- you can win 100 English Pounds!

Many thanks for your assistance, and at the same time thanks for all
who answered the IXI inquiry.

   Mit freundlichen Gruessen
   Gerti Foest


   ----------------------------------------------------------------------
   Survey of potential users of the CONCISE information service

   All completed replies to this survey which are received by the 10 July
   1991, will be entered into a prize draw. The winner will be picked out
   at random from the responses and will receive a prize of 100 UK pounds.

   The CONCISE project is one of the COSINE projects (co-operation for
   open systems interconnection networking in Europe). The CONCISE
   information service will provide information about networks and
   networking, events and other matters of European interest. Access to
   the service will be by several different network facilities.

   The following lists the types of information that will be stored in the
   information server. Please indicate your personal level of interest in
   each subject on a scale of 1 (no interest) to 10 (very interested), or
   0 (do not understand the subject). Enter the number to the left of each
   subject in the list.

       projects
       conferences and meetings
       COSINE
       network products
       special interest groups
       networks
       information servers
       name servers
       conference servers
       distribution lists servers
       file servers
       bulletin boards
       data bases
       super computers and special facilities
       service machines
       gateways, relays, and converters
       miscellaneous network resources and servers

   Any other comments on the information to be stored:



   In the following questions, indicate your selected choices with a '*'
   to the left of the items.

   Access to the CONCISE service will be by the following methods. Please
   indicate which you have heard of:

       X.400
       FTAM
       electronic mail
       Interactive X.29 (sometimes known as triple X)
       Interactive VTP
       Interactive dial-up using modem

   Please indicate which you use:

       X.400
       FTAM
       electronic mail
       Interactive X.29
       Interactive VTP
       Interactive dial-up using modem

   Please indicate which you have access to, but do not use:

       X.400
       FTAM
       electronic mail
       Interactive X.29
       Interactive VTP
       Interactive dial-up using modem

   What other methods of access would you like to be available?



   The CONCISE service will have a help desk that can be contacted by any
   users. The following are the ways in which the help desk will be
   contacted. If you were to use the help desk, which method would you
   prefer to use:

       X.400 or other electronic mail
       A special command to CONCISE when in interactive use
       Fax
       The normal mail service

   Please list any local or national computer newsletters that you read
   regularly:



   Please list any information servers you have used in the last year:



   Any other comments:



   Enter your name and address (this will only be used to contact the
   prize winner):



   After completing this survey, please send it to:

   concise@helios.iihe.rtt.be  or
   c=be;admd=rtt;prmd=iihe;o=helios;s=concise

   or mail to:

   CONCISE survey
   c/o Level-7 Ltd
   Centennial Court
   Easthampstead Road
   Bracknell
   Berkshire  RG12 1YQ
   UK

   or fax to:

   +44 344 868 442
   ..

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 91 12:38:21 GMT
From:      yman@fee3.vut.edu.au (Y.M. NG)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services

I would like to express my gratitude to all who contributed to the Usenet
in any way.
-- 
Yauman NG                               E-mail: yman@fees.vut.edu.au
Dept of Electrical Engineering, FIT     Tel: (03) 688-4724
Victoria University of Technology,      Australia  3011

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 91 15:28:18 GMT
From:      my@berlioz.nsc.com (Michael Yip)
To:        comp.protocols.tcp-ip
Subject:   ARP Question

Hi,
	I was reading The Simple Book by Marshall T. Rose. 
In section 2.3.1 (pg.35) of the book, he talks about ARP.
He states that ARP alogrithm checks the ARP_OPERATION_CODE
field last.  He goes on saying that it is very clever to do
so, but I don't understand the reasoning.

	Can anyone tell me why the code should check the 
	ARP_OPERATION_CODE foeld last?

-- Mike Yip
   my@berlioz.nsc.com

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 91 16:04:28 GMT
From:      sfrazier@mcinix.UUCP (Steven E. Frazier)
To:        comp.protocols.tcp-ip,comp.unix.questions,comp.unix.shell
Subject:   SLIP - Shell Script

I am looking for a shell script that would do a slattach of a particular
IP address with the IP address of the caller (login user).  Also,
once the connection was broken it would do a sldeattach.  Has anyone
written such a script.

If you have or you could help me out please email me at:
uunet!osu-cis!mcinix!sfrazier

Thanks.

Steve
ZZ
-- 
Steven E. Frazier
 (614) 761-6612
  VNET 424-6612

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      7 Jul 91 20:09:25 GMT
From:      mfullmer@magnus.acs.ohio-state.edu (Mark A Fullmer)
To:        comp.protocols.tcp-ip,alt.security
Subject:   Re: nosy finger daemons

karl.kleinpaste@osc.edu writes:

>Now let me get this straight: I take a copy of Tiger's fingerd and I
>install it on foo.bar.bletch.edu.  Logged into Foo, I finger
>joe@tiger.nrl.navy.mil.  Watching my syslog in another window, I
>observe an incoming finger request from Tiger.  This induces my
>fingerd (being a copy of Tiger's) to perform "finger
>@tiger.nrl.navy.mil" after which I observe another finger request
>coming back from Tiger, to which my fingerd responds with "finger..."
>
>--karl

I assumed the same, so I tried it.

A finger request at nrl produces a finger request from tiger to the originating
machine.  A finger request to tiger produces : connection refused.  No loop.

oh well...

mark
 

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 00:20:35 GMT
From:      wengland@stephsf.stephsf.com (Bill England)
To:        comp.mail.uucp,comp.protocols.tcp-ip
Subject:   Re: hack on uucp to improve efficiency

Newsgroups: comp.mail.uucp,comp.protocols.tcp-ip
Subject: Re: hack on uucp to improve efficiency
Summary: 
Expires: 
References: <2371@kgw2.XETRON.COM>
Sender: 
Followup-To: 
Distribution: 
Organization: Stephen Software Systems Inc., Seattle, +1 206 564 2122
Keywords: uucp g hack

In article <2371@kgw2.XETRON.COM> dennisg@Xetron.COM writes:
>i understand that it is possible to hack on uucp binaries
>to increase its window size thus increasing its throughput.
>

  It is?  Hmmm.  Is it also possible to modify how uucico configures
  the serial port?  For example during a recent news transfer to/from
  uunet my serial port was given the following configuration by uucico:

---- ditty ttyi1A -a -----

onstr \033[5i offstr \033[4i term ansi
maxcps 100 maxchar 50 bufsize 100
-forcedcd fastcook -altpin -fastbaud (19200)
rtspace -dtrpace ctspace -dsrpace -dcdpace
DTR+  RTS+  CTS+  CD+  DSR+  RI-
startc = 0x11 stopc = 0x13
speed 19200 baud;   ispeed 19200 baud;   ospeed 19200 baud; 
line = 0; intr = DEL; quit = ^\; erase = ^H; kill = ^U; eof = ^F; eol = ^A; 
swtch = ^@;susp <undef>;
-parenb -parodd cs8 -cstopb hupcl cread -clocal -loblk -ctsflow -rtsflow 
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -iuclc 
-ixon -ixany -ixoff 
-isig -icanon min = 6 time = 1 -xcase -echo -echoe -echok -echonl -noflsh -iexten -tostop 
-opost -olcuc -onlcr -ocrnl -onocr -onlret -ofill -ofdel 
----      -----

  I would like to have rtsflow and ctsflow on. ( I think. I know my hardware
  can handle it so why not? ) 

  I know that tweeking gettydefs does not work.  Uucico simply overrides
  them when it takes the port from uugetty.  So can I tweek uucico 
  directly?  My objective is to improve my throughput from about 800 CPS
  to over 1200 CPS which my Tbit should be capable of.

-- 
 +-  Bill England,  wengland@stephsf.COM -----------------------------------+
 |   * *      H -> He +24Mev                                                |
 |  * * * ... Oooo, we're having so much fun making itty bitty suns *       |
 |__ * * ___________________________________________________________________| 

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 03:34:02 GMT
From:      zane@ddsw1.MCS.COM (Sameer Parekh)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services


	I agree with the point that a necessarily large guide would alienate
people.  At my high school I was planning an education of graduating seniors
to tell them about the net so that once they got into college they could use
it.
	I realized it was not as easy as it seemed.  I wrote a document
which was approximately 2 pages long.  I asked my friends, those graduating
and under-classmen, to read it and tell me what they found confusing.  They
found the WHOLE thing confusing.

	I COULDN'T shorten it, nor make it simpler.  I read it and it looked
like I was writing for a 12-year old because I was using such simple terms
once I got rid of all the terms people didn't know. (Like email.)

	Then at the end I put my inet address and other people's inet
addresses and my friend (on the net) thought others would be confused byt eh
@ signs and strange lettering. (such as 'zane', 'MCS.COM',
mbodmr.fc.hp.com, etc.)
	So then my friend creating this business card sized paper saying:
How to send mail on the net:
	It said to send mail on the net get an account on your school's
computers and type 'mail zane@ddsw1.MCS.COM'.  Ask a computer wizard at your
school for more help.
	(He didn't use the term wizard...I forgot what he used.)
	
-- 
The Ravings of the Insane Maniac Sameer Parekh -- zane@ddsw1.MCS.COM

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 04:55:29 GMT
From:      thad@public.BTR.COM (Thaddeus P. Floryan)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Throughput over E-net (Trailers)

Many thanks to everyone who sent email referring me to ``ttcp'' for testing
'net performance!

To keep a long story short, it's clear that TODAY's hardware clearly is faster
than that from yesteryear.  Sigh; time to consider budgeting for some new gear.
And please don't ask me to post my "ttcp" results; I've already embarrassed
enough companies this year (requiring net-apologies), and it's only July!  :-)

As a followup to the email, I'd like to share with everyone several items:

1) the versions of ttcp.c I found at nearly every archive site are identical
   at 13033 bytes, and bear the authorship:

	* Modified for operation under 4.2BSD, 18 Dec 84
	*      T.C. Slattery, USNA
	* Minor improvements, Mike Muuss and Terry Slattery, 16-Oct-85.
	*/
	#ifndef lint
	static char RCSid[] = "@(#)$Header: ttcp.c,v 1.10 87/09/02 23:26:36 \
	 mike Exp $ (BRL)";
	#endif

   BTW, it works under SysV, too (simply -DSYSV in your Makefile, although I
   was tempted to include my SysV-compatible gettimeofday() I posted to the
   alt.sources newsgroup last year.)

2) ttcp.c was NOT accompanied by docs anywhere I could find.  After a quick
   perusal of the code, I determined the "simplest" operating mode to be:

	Have a terminal available on each system in the test loop.

	First start a ttcp receiver (at ``other_host_name'' or localhost) per:

		$ ttcp -r -s

	Then start the transmitting ttcp per:

		$ ttcp -t -s other_host_name

	Other options permit altering buffer size, number of packets, etc.
	"./ttcp" will display the usage.

3) there's a VERY interesting adjunct to ttcp called ``ttcp_fwd'' which I
   located at, I believe, sol.ctr.columbia.edu (I "visited" too many sites
   this weekend collecting "net" software) (in addition to ``netout''), which
   permits forwarding sites in the test loop.

One datum I required for my testing was cognizance of WHICH host initiated
any given test (since I log all transactions for future reference), so I added
a few lines to do a "getpeername()"; rather than displaying "ttcp-r accept" my
changes display, for example, "ttcp-r accepted from foo.bar.com".

As repayment for the help received from others, my shar'd diffs to the original
ttcp.c are enclosed for your reference in a patch-compatible format; to enable
the additions add "-DTHADMODS" to your Makefile (and please don't think this
presumptuous of me; consider it as your knowing WHOM to blame if it fails on
your system! :-)

And to give credit where due, the gist of the mod is based on code posted to
comp.unix.questions by wswietse@lso.win.tue.nl (Wietse Venema) on 7 Jun 90
09:04:12 GMT concerning:

 > If I `rlogin' from machine1 to machine2, is there a simple and (relatively)
 > portable way to find out on machine2 the name of machine1?

Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]

-------------------- begin enclosure

---- Cut Here and feed the following to sh ----
#!/bin/sh
# This is a shell archive (produced by shar 3.49)
# To extract the files from this archive, save it to a file, remove
# everything above the "!/bin/sh" line above, and type "sh file_name".
#
# made 07/08/1991 04:38 UTC by thad@thadlabs
# Source directory /u/thad/Filecabinet/WORK/tcpip/src/ttcp
#
# existing files will NOT be overwritten unless -c is specified
#
# This shar contains:
# length  mode       name
# ------ ---------- ------------------------------------------
#   1681 -rw-r--r-- thad.patch
#
if touch 2>&1 | fgrep 'amc' > /dev/null
 then TOUCH=touch
 else TOUCH=true
fi
# ============= thad.patch ==============
if test -f 'thad.patch' -a X"$1" != X"-c"; then
	echo 'x - skipping thad.patch (File already exists)'
else
echo 'x - extracting thad.patch (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'thad.patch' &&
X*** ttcp.c-ORIG	Tue Apr  3 10:01:00 1990
X--- ttcp.c	Sun Jul  7 21:33:32 1991
X***************
X*** 88,93
X  {
X  	unsigned long addr_tmp;
X  
X  	if (argc < 2) goto usage;
X  
X  	argv++; argc--;
X
X--- 88,105 -----
X  {
X  	unsigned long addr_tmp;
X  
X+ #ifdef THADMODS
X+ #ifndef	MAXHOSTNAMELEN
X+ #define	MAXHOSTNAMELEN	BUFSIZ		/* BSD 4.2 ?? */
X+ #endif
X+ 	int     length;
X+ 	struct sockaddr sa;
X+ 	struct sockaddr_in *sin = (struct sockaddr_in *) (&sa);
X+ 	char    host_name[MAXHOSTNAMELEN];
X+ 	struct hostent *hp;
X+ 	char   *inet_ntoa();
X+ #endif /* THADMODS */
X+ 
X  	if (argc < 2) goto usage;
X  
X  	argv++; argc--;
X***************
X*** 202,207
X  		domain = AF_INET;
X  		if((fd=accept(fd, &frominet, &fromlen) ) < 0)
X  			err("accept");
X  		mes("accept");
X  	    }
X  	}
X
X--- 214,239 -----
X  		domain = AF_INET;
X  		if((fd=accept(fd, &frominet, &fromlen) ) < 0)
X  			err("accept");
X+ #ifdef THADMODS
X+ 		length = sizeof(sa);
X+ 
X+ 		if (getpeername(fd, &sa, &length) >= 0) {
X+ 		    if (sa.sa_family == AF_INET) {
X+ 			if (hp = gethostbyaddr((char *) &sin->sin_addr.s_addr,
X+ 				   sizeof(sin->sin_addr.s_addr), AF_INET)) {
X+ 			    fprintf(stderr,"ttcp-r: accepted from %s\n",
X+ 				hp->h_name);
X+ 			}
X+ 			else {
X+ 			    fprintf(stderr,"ttcp-r: accepted from %s\n",
X+ 				inet_ntoa(sin->sin_addr));
X+ 			}
X+ 		    }
X+ 		}
X+ 		else {
X+ 		    mes("accept");
X+ 		}
X+ #else
X  		mes("accept");
X  #endif /* ifdef THADMODS */
X  	    }
X***************
X*** 203,208
X  		if((fd=accept(fd, &frominet, &fromlen) ) < 0)
X  			err("accept");
X  		mes("accept");
X  	    }
X  	}
X  	prep_timer();
X
X--- 235,241 -----
X  		}
X  #else
X  		mes("accept");
X+ #endif /* ifdef THADMODS */
X  	    }
X  	}
X  	prep_timer();
SHAR_EOF
$TOUCH -am 0707213691 'thad.patch' &&
chmod 0644 thad.patch ||
echo 'restore of thad.patch failed'
Wc_c="`wc -c < 'thad.patch'`"
test 1681 -eq "$Wc_c" ||
	echo 'thad.patch: original size 1681, current size' "$Wc_c"
fi
exit 0

-------------------- end of enclosure

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 06:44:01 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP Question

In article <1991Jul7.152818.19584@berlioz.nsc.com>, my@berlioz.nsc.com
 (Michael Yip) wrote:
>Can anyone tell me why the code should check the ARP_OPERATION_CODE
>foeld last?

See the suggested algorithm for processing incoming ARP's in RFC 826.

-- 
<skl@wimsey.bc.ca>

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 07:56:37 GMT
From:      rsw@cs.brown.EDU (Bob Weiner)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk,comp.mail.uucp,comp.mail.sendmail
Subject:   Re: On the need to develop Internet user services

In article <1991Jul08.033402.13071@ddsw1.MCS.COM> zane@ddsw1.MCS.COM (Sameer Parekh) writes:
> 
> At my high school I was planning an education of graduating seniors
> to tell them about the net so that once they got into college they could use
> it.
> 	I realized it was not as easy as it seemed.  I wrote a document
> which was approximately 2 pages long.  I asked my friends, those graduating
> and under-classmen, to read it and tell me what they found confusing.  They
> found the WHOLE thing confusing.


[I don't profess that this will work for those who know nothing about
computers, but I do think it is a good, short example of how to explain a
problem like e-mail addressing to a novice computer user.

It does not discuss X.400 based e-mail but should at some future time.]

==============================================================================

   		   Internet / Usenet Mail Addressing Guide

				 Bob Weiner

			       rsw@cs.brown.edu

				 July 8, 1991


This document discusses how to address mail to or from both Usenet (via UUCP =
UNIX to UNIX Copy Protocol) and the Internet (via SMTP = Simple Mail Transfer
Protocol).  Mail through the Internet can reach Usenet, Compuserve, MCI Mail,
and many research and corporate organizations throughout the world.

It assumes you have a mail reader and composer program with its own
documentation, on a computer which can connect to Usenet or the Internet.  The
mail address is what you will put or receive on the message line that begins
with the literal string: "To:".

************************
Sending Worldwide E-mail
************************

Here is how you mail to someone else.  (Items within <> or in all capitals are
field names for which you must give literal values.  Items in [] are optional
fields, which are only included in certain electronic mail addresses. An |
symbol means choose one from the set of alternatives separated by the symbol. A
host is a computer)


From an Internet Host - To an Internet Host
-------------------------------------------

If a user's organizational address is registered on the Internet, he will
have an address of the form: 

	        <user>@<hostname>.<domain>[.<org>][.<country>]

for example:      bert@ladder.princeton.edu

where <hostname> is a computer name and <domain> is a recursive specification
of a logical location, that is, it may contain subdomains as in:

	  <domain> = DOMAIN_IDENTIFIER | SUBDOMAIN_IDENTIFIER.<domain>

Organization should always be one of the following:

	     net	   for network gateways, e.g.  uu.net
	     edu	   for educational institutions, e.g. brown.edu
	     org	   for non-profit organization,  e.g. osf.org
	     com	   for commercial firms, e.g. hp.com
	     gov	   for government entities, e.g. nasa.gov
	     mil	   for war gamers, e.g. army.mil
	     uucp	   for non-interneters, Usenet hosts, e.g. novavax.uucp
	     arpa	   obsolete, refers to the Arpanet that evolved into
			     the Internet.

Country is typically a two letter country code for mail outside of the US:

	     ca	     	   Canada
	     fr		   France
	     se		   Sweden
	     de		   Denmark
	     ch		   Switzerland

One example of a self-deprecating Internet mail address might be:

	  nerdy@wimpy.eecs.berkeley.edu

This addresses a message to the <user>, nerdy, at the <host>, wimpy, in the
EE Computer Science department <subdomain>, eecs, at UC Berkeley, berkeley,
which is obviously an educational institution, edu.

To send, simply place the user's address in the 'To:' field of your mail
message.

From a Usenet Host - To a Usenet Host
-------------------------------------

Now consider that you are a user whose computer is registered on the UUCP
Usenet, who has only a dialup connection to the network and you want to mail to
another such user.  Let's say you actually wanted to communicate with someone
earning a lot of money, call him smiley@bucks.  His machine bucks communicates
directly with a registered machine, cash.  So you could send to him with the
following address:

     uunet!cash!bucks!smiley

The host 'uunet' is a very important one; it serves as a mail gateway between
Usenet and the Internet, so it knows how to properly address mail for
practically every Internet domain and registered UUCP host in the world.  This
is why your mail must go through it, because locally your mail host will never
be as smart as uunet.  If your host computer can't send directly to uunet, you
will have to precede the above path with one that starts with a machine that
your's communicates directly with and ends with a machine name that
communicates with uunet, plus another '!', e.g.

     nearby!farther!uunet!cash!bucks!smiley


From an Internet Host - To a Usenet Host
----------------------------------------

If your machine is on the Internet and the other is on Usenet, you can
use something like:

	      bucks!smiley@uunet.uu.net


From a Usenet Host - To an Internet Host
----------------------------------------

If your machine is on Usenet only and the other is on the Internet, you can
use something like either of the following:

	      nearby!farther!uunet!ladder.princeton.edu!bert
	      nearby!farther!uunet!bert@ladder.princeton.edu


From an Internet Host - To a Compuserve User
--------------------------------------------

To mail to a Compuserve user with an ID of  aaaaa,bbbb:

	      aaaaa.bbbb@compuserve.com

Note that the comma in the ID becomes a period in the Internet address.


From an Internet Host - To an MCI Mail Customer
-----------------------------------------------

	      <user>@mcimail.com


***********************************
Why me?  Can't I just lick a stamp?
***********************************

Once you realize that you can get a message from across the country in under 2
hours depending on how frequently you poll a dial-up computer or within a few
minutes on the Internet, you'll learn to enjoy the convenience of this
facility.

The main benefits of electronic mail are that:

       it always sits and waits until the addressee has time for it;

       it decreases work interruptions, allowing more time and thoughtful
       responses to other people's thoughts and questions;

       it provides data that you can work with and modify, unlike
       facsimiles and voice mail;

       it is the backbone of many large organizations wide-area
       communications strategies for the 90's and thus a safe investment of
       time and money;

       logical, non-location dependent addressing is much simpler and
       reliable than postal addressing; automatic mail forwarding is also
       available;

       e-mail is a very cost effective means of messaging.


By the way, UUCP mail is a 1970's technology, although it has advanced a great
deal.  (UUCP mail addresses use the '!', which is called a 'bang' rather than
an exclamation point because networking people don't have much time to read and
because they love to save syllables.  Internet mail dates back even farther
than UUCP mail.  Domain-based mail addressing became a phenomenon in the
mid-1980's.
==============================================================================

			  Bob Weiner
			  rsw@cs.brown.edu
			  --  Explaining Real Computers to Real People

--
Bob Weiner				   rsw@cs.brown.edu
	     I speak only of my own views.

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 10:49:19 GMT
From:      simon@liasun2.epfl.ch (Simon Leinen)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk,comp.mail.uucp,comp.mail.sendmail
Subject:   Re: On the need to develop Internet user services

In article <RSW.91Jul8035637@reverb.cs.brown.EDU> rsw@cs.brown.EDU
(Bob Weiner) writes:

   Country is typically a two letter country code for mail outside of
   the US:

                ...
                de                 Denmark
                ...

Small correction: DE is the ISO country code for Germany
(DEutschland).  Denmark is `DK'.
-- 
Simon.

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 12:30:49 GMT
From:      mjw@wasp.eng.ufl.edu (Michael J. Wohlgemuth)
To:        comp.protocols.tcp-ip
Subject:   Re: On the need to develop Internet user services

In article <1991Jul5.231746.18529@Think.COM> barmar@think.com writes:
>In article <64986@bbn.BBN.COM> jcurran@BBN.COM (John Curran) writes:
>>  It's hard to imagine what the Internet would
>>  be like today if there were a charge to use most services.. I'd wager 
>>  that many sites would disconnect. (Imagine trying to budget for it..) 
>
>As for budgeting, why should budgeting for Internet-accessible information
>services be any different from other online information services, or other
>services in general?

Well, I'm not sure that it is because of budgetary restrictions, but I
don't know of one instance on campus where the University has paid for
a subscription to Compuserve.  The only possible reason I can think of
is that someone is afraid that nobody will be accountable for its use.
I imagine that it would be the same for any Internet accessible services.

Mike

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 13:14:46 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Ftp, Tcp/Ip


    >....  Can someone provide for me the names of vendors that make a
    > version of tcp-ip (that includes ftp and telnet) for dos and windows.
    
    Many dos pc's use ftp's pc/tcp. They have an ftp server at ftp.vax.com.

Ours isn't available as shareware.  At the moment, our Windows support is
only for 386 Extended mode: a VxD/DLL which allows use of our applications
in multiple DOS boxes, and developement of WinApps.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 13:28:16 GMT
From:      blknowle@frodo.jdssc.dca.mil (Brad L. Knowles)
To:        comp.protocols.tcp-ip
Subject:   Commercialization of the Internet...

Fellow Net-Landers,

    I've been sitting on the side lines, watching the discussion between
Peter, Ed, and various other folks, and had a thought (I know, I know,
what a concept :-).

    Someone mentioned that there might be a problem commercializing a
service like archie -- something to to the effect of ``how do you bill
your users for the service, and how can you do this over a very
non-cooperative NSFnet?''

    Well, what about selling a client/server tool for accessing a service
like Archie?  You sell the tool itself (I think I heard a tool called
Propero mentioned, but know *zero* about it), but the service is free.
You could even make the encrypted software available via anonymous ftp,
and it can only be unlocked for permanent use by calling a 1-800 number,
and supplying all sorts of info on yourself and your hardware, after which
they give you a password to unlock the software.  Up to that point in
time, the software you have is a demo-only copy, which may have certain
very useful features disabled (like, only a small subset of the actual
responses are retrieved, or maybe only one or two retrievals before the
software disables itself, or whatever).  Alternatively, the software that
is available via anonymous ftp has no documentation, and may not have very
many features.  When users register their copy, they get a high-quality
manual, and a boatload of features that they can play with.

    Thus, you get around the very pushy and uncooperative NSF, while still
providing a good service at a reasonable fee.  If done well, you can even
protect your investment in the software, and eliminate piracy (or at
least, reduce it until it is almost non-existant).

    Peter, Ed -- it looks like this would be a perfect oppurtunity for you
to go into private business and make some cash for yourself, all the while
providing services that we can all use!
 ________________________________________________________________________ 
| Brad Knowles                 | Internet: blknowle@frodo.jdssc.dca.mil  |
| DISA/DSSO/JNSL               | Ph: (703) 693-5849  Fax: (703) 693-7329 |
| The Pentagon, Room BE685     |-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-|
| Washington, D.C.  20301-7010 | Speaking from, *not* for DISA (nee DCA) |
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 13:31:27 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   OSPF Information

Several people have asked me where to find the papers written about the
OSPF interoperability testing that was recently conducted, but I couldn't
remember the source.

The papers are Internet Drafts available from DDN NIC.  The filenames are:

	"Experience with the OSPF Protocol" by John Moy
	draft-ietf-ospf-experience-00.txt or -00.ps

	"OSPF Protocol Analysis" by John Moy
	draft-ietf-ospf-analysis-00.txt or -00.ps

Good reading if you're contemplating a change to OSPF!

----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		        (800) 388-7076
500 N. Wakefield Drive			Fax:    (302) 451-5321      
Newark, DE  19714-6066	                Email:  scoggin@delmarva.com
----------------------------------------------------------------------

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 14:17:11 GMT
From:      morvai@CRC.SOFKIN.CA (Steve Morvai)
To:        comp.protocols.tcp-ip
Subject:   INETD Source


    Does anyone know where I may find the source for "inetd" with
Access Control List (ACL) modifications.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~       ####       ######       ##   ## ~ Software Kinetics Ltd. ~ PHONE:(613) ~
~     ##  ##       ##  ##      ### ###  ~ 65 Iber Road           ~  831-0888   ~
~    ###          ##  ##      #######   ~ POB 680                ~              ~
~    ###         #####       #######    ~ Stittsville, Ontario   ~ FAX:(613)   ~
~     ###       ## ##       ## # ##     ~ K2S 1E7                ~  831-1836   ~
~ ##  ##       ##  ## ##   ##   ##      ~ CANADA                 ~             ~
~ ####  teve ###  ## ##   ##   ## orvai ~       INTERNET: morvai@sofkin.ca     ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 14:32:59 GMT
From:      lowell@pluto.dss.com (Lowell Gilbert)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk
Subject:   Re: On the need to develop Internet user services


>Well, there was once a time when you looked at your
>neighbor's horseless carriage and said "hey, that's neat.
>Can you tell me in simple terms how to run one of those
>thing-a-me-bobs?" and the answer was "Sorry, but you need
>to know about cylinders and compression and double-clutching the
>non-synchronized transmission, and what to do if
>the crankcase leaks, and oh, yeah the magneto for the
>ignition system is a flakey item and should be rewound and
>don't forget to strain your fuel, and no, kerosene wont
>work and this model uses a tiller and that one a wheel,
>and..."
 
>You get the idea. Now you can jump in your Japanes
>econobox and, without any knowledge of the wonderful advances
>in metallurgy and automotive engineering, go buy a pint of
>milk. The cars are infinitely more complex, but infinitely
>easier to use (they also come in more colours... :-)
 
>If we can't present the information distribution paradigm
>in a relatively simple manner, maybe it's _NOT_ just that
>we're so smart and they're so dumb.  Maybe our paradigm
>isn't finished yet?  Just my own opinion, but the basic
>_services_ we could offer here (as opposed to the
>technology to deliver thoses services) are actually rather
>straight-forward. We just haven't figured out how to
>package and describe them yet. My original thesis can be
>reworded to be "I think it time we focus on this part, folks".

The basic argument here is quite correct, but I think this
presentation trivializes the problem.  In particular, I have problems
with the automotive analogy.  The analogy breaks down in the
flexibility -- essentially unprecedented -- of a computer.  Even when
you needed to know every little detail of a car to operate one, its
purpose was essentially to provide transportation.  If you want to
limit a given computer to that simple a purpose (say, using e-mail)
then you can make the analogy stick.  However, short of limiting the
computer's strength as a tool -- its flexibility -- you cannot avoid
the fact that number of different things you can do with it is so
vastly greater.  In short, I disagree with the statement that the
"basic services ... are actually rather straight-forward."  They're
certainly so much more complicated than what we expect from a car (in
terms of applied functionality) that it's really a difference of kind,
not merely extent.

That said, it is still true that user interfaces can be improved a
great deal.  I also think that they *are* being improved, at a
reasonable rate.  It's not just a matter of "better programming," it's
a matter of improving the basic technology (yes, user interfaces are a
technology).  Let's just avoid the trap of thinking that we can just
decide to stop being obtuse and make this stuff accessible to all.
That's the right goal, but it's not that easy and we shouldn't imply
that it is.

Be well.

-- 
-------------------------------------------------------------------------
Lowell Gilbert          Datability Corp.
Lowell@Doc.DSS.Com      NY, NY  (Carlstadt, NJ in a couple of days)
"Programming is not a spectator sport."

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 16:13:23 GMT
From:      cmf851@anu.oz.au (Albert Langer)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk,comp.mail.uucp,comp.mail.sendmail
Subject:   Re: On the need to develop Internet user services

In article <RSW.91Jul8035637@reverb.cs.brown.EDU> rsw@cs.brown.EDU 
(Bob Weiner) writes:

>[I don't profess that this will work for those who know nothing about
>computers, but I do think it is a good, short example of how to explain a
>problem like e-mail addressing to a novice computer user.

Sorry to pick on you (nothing personal, I don't even know you :-) but
I'm going to take your short example apart item by item to show how
much more needs to be done for a "novice computer user".

By "novice computer user" I mean somebody who can handle a simple
wordprocessor/text editor on their Mac or IBM clone but has no interest
in "programming" and would like to know as little as possible about any
"operating system".

The problem is not lack of skill in explaining how it works for the
novice user, but that the system simply is NOT intended to work for
the novice user, but rather for people interested in programming.

For novice computer users (let alone people who know nothing about
computers) to gain easy access the FIRST requirement is that we
understand this was NOT intended in the current design and that
therefore a re-design is required to achieve it - not just a
brochure, however well written.

>This document discusses how to address mail to or from both Usenet (via UUCP =
>UNIX to UNIX Copy Protocol) and the Internet (via SMTP = Simple Mail Transfer
>Protocol).  Mail through the Internet can reach Usenet, Compuserve, MCI Mail,
>and many research and corporate organizations throughout the world.

Every one of these names is ENTIRELY meaningless to a "novice computer user"
and spelling them out to throw in terms like "Copy Protocol" and "Transfer
Protocol" merely heightens the confusion. Why bother? Does one list the
history of postal organizations from the days of the Royal couriers through
Reuters carrier pigeon services in order to explain how to send a letter
or make a phone call?

>It assumes you have a mail reader and composer program with its own
>documentation, on a computer which can connect to Usenet or the Internet.  The
>mail address is what you will put or receive on the message line that begins
>with the literal string: "To:".

What is a "mail reader and composer program"? How do I tell if this
computer is connected to "Usenet" or the "Internet" (I see only connections
to a power socket and another cable that goes through a hole in the wall...)?

I know what a "mail address" USUALLY means, but what does it have to do
with a "message line"? What is a "literal string"? Does one wrap it 
around the message like an elastic band?

>Here is how you mail to someone else.  (Items within <> or in all capitals are
>field names for which you must give literal values.  Items in [] are optional
>fields, which are only included in certain electronic mail addresses. An |
>symbol means choose one from the set of alternatives separated by the symbol. A
>host is a computer)

What is a "field name" and what is a "literal value" and why should I give
one to the other? What are "optional fields"?  Hey this stuff looks like
that "Backus Normal Form" they were using to convince me I wouldn't be
interested in programming - I'm convinced already! What happened to the
promise that I could use the mail system without learning programming?

If a host is a computer, why don't you just call it a computer?

>If a user's organizational address is registered on the Internet, he will
>have an address of the form: 

What do you mean "registered on the Internet" and why should I care?

>	        <user>@<hostname>.<domain>[.<org>][.<country>]

You're kidding. I want to go home. Take me away from all this!

>for example:      bert@ladder.princeton.edu

Example of WHAT? The only thing it has in common with the "form" you
showed is an @ sign and two dots (though the "form" had three). What
happened to all the other weird symbols "<>[]" and funny words 
("hostname", "domain", "org"). I know what a "user" and a "country"
are but I can't see any examples there.

>where <hostname> is a computer name and <domain> is a recursive specification
>of a logical location,

Ok, I can follow that if you insist on calling a computer a "host" then
it's natural you should call a computer name a "hostname" (and run the
two words together just in case I found that bit too easy). But why does
a computer have a name? My computer is just called a Mac and it doesn't
have any other name that I know of. Sometimes I think it is conspiring
against me, but I know it isn't really alive.

As for "recursive specification of a logical location", I know you are
clever at these things, but I happen to be good at quite different things
and I DO NOT want to know about "recursive specifications of a logical
location" in order to discuss MY interests with other people by mail.

> that is, it may contain subdomains as in:
>
>	  <domain> = DOMAIN_IDENTIFIER | SUBDOMAIN_IDENTIFIER.<domain>

Good for it. I'm not even going to ASK what THAT gobbledegook means.
It plainly has no CONCEIVABLE relation to anything that I understand
as "mail". I was NEVER any good at Chemistry and I see no reason why
I should have to learn these obviously chemical formulae in order to
use mail.

>Organization should always be one of the following:
>
>	     net	   for network gateways, e.g.  uu.net
>	     edu	   for educational institutions, e.g. brown.edu
>	     org	   for non-profit organization,  e.g. osf.org
>	     com	   for commercial firms, e.g. hp.com
>	     gov	   for government entities, e.g. nasa.gov
>	     mil	   for war gamers, e.g. army.mil
>	     uucp	   for non-interneters, Usenet hosts, e.g. novavax.uucp
>	     arpa	   obsolete, refers to the Arpanet that evolved into
>			     the Internet.

Huh? What "organization" should always be one of those. This is the first
time you've mentioned any "organization". Anyway, I've no idea what you
are talking about. Remember I just want to know HOW TO SEND MAIL.

>Country is typically a two letter country code for mail outside of the US:
>
>	     ca	     	   Canada
>	     fr		   France
>	     se		   Sweden
>	     de		   Denmark
>	     ch		   Switzerland

Sheesh! How STUPID. With ordinary mail you can just write down the
country and you don't have to memorize any silly two letter codes.
Aren't computers supposed to do things like that FOR you?

>One example of a self-deprecating Internet mail address might be:
>
>	  nerdy@wimpy.eecs.berkeley.edu
>
>This addresses a message to the <user>, nerdy, at the <host>, wimpy, in the
>EE Computer Science department <subdomain>, eecs, at UC Berkeley, berkeley,
>which is obviously an educational institution, edu.

Uh, yep. (Nodding enthusiastically with a blank look, having lost interest
long ago.)

>To send, simply place the user's address in the 'To:' field of your mail
>message.

Great! But where do I find this "'To:' field" and how do I place things
in it?

[further incomprehensible computer jargon instructions deleted]

>The host 'uunet' is a very important one; it serves as a mail gateway between
>Usenet and the Internet, so it knows how to properly address mail for
>practically every Internet domain and registered UUCP host in the world.  This
>is why your mail must go through it, because locally your mail host will never
>be as smart as uunet.  If your host computer can't send directly to uunet, you
>will have to precede the above path with one that starts with a machine that
>your's communicates directly with and ends with a machine name that
>communicates with uunet, plus another '!', e.g.
>
>     nearby!farther!uunet!cash!bucks!smiley

Wow! If this "uunet" is so smart, perhaps I should get an account on it,
amd maybe it would just let me send mail without all this CRAP?

I know my local post office isn't "smart" enough to properly address
mail for practically every postal address in the world. But they ARE
smart enough not to bother ME with their troubles. I just pass the
mail to them and they figure out what to do with it from there - I
don't have to tell them where to find a smarter post office.

> [...]
 
>To mail to a Compuserve user with an ID of  aaaaa,bbbb:
>
>	      aaaaa.bbbb@compuserve.com
>
>Note that the comma in the ID becomes a period in the Internet address.

Yeah, OF COURSE. But how come you don't change the lower case letters
to UPPER CASE and reverse the order while you are at it? (Oh, the
aaaaa and bbbb aren't letters at all, they are numbers, so why did
you show me letters... ah forget it).

> [...]
>
>***********************************
>Why me?  Can't I just lick a stamp?
>***********************************

EXCELLENT question!

>Once you realize that you can get a message from across the country in under 2
>hours depending on how frequently you poll a dial-up computer or within a few
>minutes on the Internet, you'll learn to enjoy the convenience of this
>facility.

The point you are missing is that I don't spend 2 hours delivering mail
and neither does the postie on my behalf. I want email to take ME less
time and I don't want to know anything about "how frequently you poll a
dial-up computer" any more than I want to know how the post office
schedules their delivery runs.

You are asking me to spend hours learning a whole technical culture just to 
use a mail service. If my wordprocessor was like that I would NOT use it.
You must be the kind of person that puts up with "vi" as a text editor -
or maybe you use ed?

>[...]
>
>By the way, UUCP mail is a 1970's technology, although it has advanced a great
>deal.  (UUCP mail addresses use the '!', which is called a 'bang' rather than
>an exclamation point because networking people don't have much time to read and
>because they love to save syllables.  Internet mail dates back even farther
>than UUCP mail.  Domain-based mail addressing became a phenomenon in the
>mid-1980's. [...]

1970s you say? They stopped writing a ROUTE for mail delivery
at least a century ago. Have you ever seen an envelope with instructions
like:

Take this to Canberra, then hop across to New York, on to whatever
City, turn whichway from the main post office there, then left then right
then left again until you come to "Brown University", then right, then
left, then right again to "Computer Science", up three flights of stairs,
past 3 doors and give it to Bob Weiner at the door marked "rsw".

>			  --  Explaining Real Computers to Real People

Hmmph :-)

--
Opinions disclaimed (Authoritative answer from opinion server)
Header reply address wrong. Use cmf851@csc2.anu.edu.au

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 16:39:33 GMT
From:      wessling@algol.cs.umbc.edu (michael wessling)
To:        comp.protocols.tcp-ip
Subject:   Looking for info on netstat protocol

Does anyone have information on the netstat protocol, or knows where I can
get information. Is there an "offical" specification ?

	-Michael

	  wessling@algol.cs.umbc.edu

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 16:48:34 GMT
From:      rickert@mp.cs.niu.edu (Neil Rickert)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk,comp.mail.uucp,comp.mail.sendmail
Subject:   Re: On the need to develop Internet user services


  Why is this discussion going on in comp.mail.sendmail (or for that matter
in most of the other groups above).

  Please move it to /dev/null where it belongs.

-- 
 <rickert@cs.niu.edu>  |  METROPOLITAN LIFE!  The roach motel of insurance.
     Neil Rickert      |  Premiums check in, but benefits don't check out.
   Computer Science    |
 Northern Illinois U.  |  ---> 7 months of harrassment and deception <---

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 17:28:14 GMT
From:      mmorse@NSF.GOV (Michael Morse)
To:        comp.protocols.tcp-ip
Subject:   Re: Commercialization of the Internet...

> ... the software you have is a demo-only copy, which may have certain
> very useful features disabled (like, only a small subset of the actual
> responses are retrieved, or maybe only one or two retrievals before the
> software disables itself, or whatever).  Alternatively, the software that
> is available via anonymous ftp has no documentation, and may not have very
> many features.  When users register their copy, they get a high-quality
> manual, and a boatload of features that they can play with.

You might be able to swipe a page from the PC guys, and distribute the
whole package but simply include a statement to the effect of "If you
find this software useful, please sent $nn to xxxx," or the harder
version "If you find this software useful you must send $nn to xxx or
STOP USING IT."

While the percentage of people using shareware that register it is
fairly low, enough do that people keep writing pretty good stuff.
Also, large organizations typically do register stuff before putting
it out where their users can get to it in a general way.  In the
network environment you'd have an advantage over the PC guys, in that
you'd know everytime someone used your service and could at least
check to see how many were registering software.

I think it's a great idea!  The only possible problem I see is that
some of these services we're discussing are in some ways derivative
works, in that they depend on other services for input.  Some one might
say that the *real* value is in the ftp-able archive, so why is archie
getting all the money?  I think for derivative works you might want to
provide a free access method that might not have all the bells and
whistles of your fantastic shareware product.

I've always wondered why Internet/Unix people give away such good
software.  I look at the case of mush vs cc:Mail.  Both are credible,
complete, robust mail user interfaces.  In the first case, it is given
away to anyone who wants to use it, in the second it is built into a
best-selling PC product bringing in millions of dollars in revenue.
Probably the answer is that the author of mush was not interested in
all the non-software tasks that go into building a business.  The
shareware route offers a middle ground.  You can get rewarded for your
labor, but you have to maintain some responsibility for support.

--Mike

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 18:04:44 GMT
From:      08071TCP@MSU.EDU (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: NIC.NSF.NET

>I can ping it by number but by name it seems as if it has lost its nameserver.
>Is anyone else having problems getting to nic.nsf.net (35.1.1.48)?

I think you mean NIS.NSF.NET - doing a PTR lookup on the address yields
that name, and that host name has the same A entry.

Doug Nelson
Michigan State University

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 18:49:08 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: ARP Question

In article <1991Jul7.152818.19584@berlioz.nsc.com> my@berlioz.nsc.com (Michael Yip) writes:
>Hi,
>	I was reading The Simple Book by Marshall T. Rose. 
>In section 2.3.1 (pg.35) of the book, he talks about ARP.
>He states that ARP alogrithm checks the ARP_OPERATION_CODE
>field last.  He goes on saying that it is very clever to do
>so, but I don't understand the reasoning.
>
>	Can anyone tell me why the code should check the 
>	ARP_OPERATION_CODE foeld last?
>
>-- Mike Yip
>   my@berlioz.nsc.com

Probably because the remote IP-address/MAC-address pair is valid for EITHER
a Request OR a Response.  Therefore the remote address information should be
processed first (new info, or update of cached info), then the request type
checked to continue the ARP packet processing.

Art

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 19:00:00 GMT
From:      mmorse@NSF.GOV
To:        comp.protocols.tcp-ip
Subject:   RFC 1001 Implementations


Does anyone know of a P node implementation of RFC 1001 (Netbios over
TCP/IP)?  I'd be interested in hearing from vendors or users.

--Mike

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 19:46:19 GMT
From:      rsw@cs.brown.EDU (Bob Weiner)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk,comp.mail.uucp,comp.mail.sendmail
Subject:   Re: On the need to develop Internet user services

A number of people pointed out that the country code 'de' 
is used by Germany and that Denmark uses the code 'dk'.  I regret the
error and hope people will correct their copies of the addressing guide.

Michael Morse (mmorse@nsf.gov) noted that UUnet is not a
general-purpose gateway for Usenet to Internet mail.  It is a commercial
facility which provides this service mainly for the benefit of its
subscribers.  So, although UUnet will forward mail for non-subscribers,
I hope people recognize their function and do not overload them with
mail forwarding requests.  Anyone who saved the main posting should add
a note to this effect.

To avoid complexity, I did not mentioned the Smart UUCP software which
is freely available, which when combined with Usenet map routes, allows
one to address Usenet hosts directly, without the need to know an actual
routing path to reach it.  I don't have any more information on this
software, so if you want some, find a host which runs it and inquire
there.

Don Wells (dwells@fits.CX.NRAO.EDU) noted the omission of a number of
popular subnets such as 'bitnet'.  My feeling is that there are too many
to mention.  If someone writes a good, short summary of major subnets
and how to address them, it could be included.

Finally, Albert Langer (cmf851@anu.oz.au) made one or two good points
about the complexity of some of the language in the document.  His
thesis, however, that the document is totally useless to novice computer
users is false.  The document assumes that some source of
intelligence is available to which a user can go to obtain a conceptual
or operational background on electronic mail use.  Virtually everyone
has some access to such intelligence, whether it be through co-workers,
suppliers, other literature, consultants, or friends.  With such
intelligence where needed, the guide can help people properly address
mail for worldwide delivery.
--
Bob Weiner				   rsw@cs.brown.edu
	     I speak only of my own views.

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 20:21:12 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Commercialization of the Internet...

In article <9107081328.AA07039@frodo.jdssc.dca.mil>
blknowle@frodo.jdssc.dca.mil (Brad L. Knowles) writes:
>    Thus, you get around the very pushy and uncooperative NSF, while still
>providing a good service at a reasonable fee.  If done well, you can even
>protect your investment in the software, and eliminate piracy (or at
>least, reduce it until it is almost non-existant).

I'd like to point out an example where this theory doesn't work in
practice.  In the alt.sex.pictures newsgroup a few months back someone
said that JPEG files were the way to go and the whole world should
convert from GIF.  Some company came out with a program called Alchemy
that would do lots of stuff that isn't really relevant right now.
However, the "free" version of this program only did files upto a
certain size.  Anything larger would say something like "this image is
too big for the demo version of this program."  However, within a few
days of the Alchemy (binary only) posting, there were a couple of
other postings that had adb commands that removed this restruction (or
made the restriction several orders of manitude larger, I can't recall
which).  I don't know how this effect the sales of Alchemy, but it
does show that some people on the net don't like "crippleware".  In
addition, the whole stink left a really bad taste in a lot of people's
mouths.  There is a free version of the JPEG stuff now.  It did start
before things flared up, but got a BIG push from the stink.

So, if you provide the service for free, but charge for the tools, you
can bet money that someone, somewhere is going to write a "free"
version of your program.  It might not have all the bells and whistles
that the one you sell has, but it would allow people to access the
service for free.  How much this cuts into your bottom line is a
source for debate.

There is a lot of techinical talent on the net.  Some of it may go
towards cracking whatever scheme you have developed.  Some people do
it so they say they've done it.  Others want to save $20.00, so they
spend 10 or 20 hours cracking what you provided.  Others may just want
to learn how networking is done and write a program that accesses your
server to learn how to do it.  Others will want to do it because they
are used to getting things for free (or what they consider free) and
want to "punish" those people who want to use the net to turn a
profit.

Warner
-- 
Warner Losh		imp@Solbourne.COM
But it was our hill.  And they were our beans.

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 20:45:55 GMT
From:      fks@FTP.COM (Frances Selkirk)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP under OS2



kanvik@casbah.acns.nwu.edu (Joel W Kanvik) writes:
	
>Try TCP/IP that was developed for OS/2.  I've used it for a while (before
>someone crashed my machine).  Works very well.  Comes with LaMail, ftp, and


Actually, there are several TCP/IP packages that were developed for OS/2.
Ours and IBMs have all the features you'd expect: telnet (client and server)
ftp (client and server), NFS (client) and more. I'm not sure what's in 
Ungermann-Bass's or 3Com's implementation; I've heard they are largely 
intended as transport for other applications, and don't include many standard
TCP/IP applications. They do include NetBIOS, as do we.


	

Frances Kirk Selkirk		 fks@ftp.com	           (617) 246-0900
FTP Software, Inc.		 26 Princess Street, Wakefield, MA  01880

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 21:21:12 GMT
From:      moraes@cs.toronto.edu (Mark Moraes)
To:        comp.protocols.tcp-ip,comp.mail.uucp,comp.mail.sendmail,comp.org.eff.talk,comp.archives.admin
Subject:   Re: On the need to develop Internet user services

cmf851@anu.oz.au (Albert Langer) writes:
...
>Header reply address wrong. Use cmf851@csc2.anu.edu.au

An interesting point.  The Matrix would be a much nicer place if we
could rely on header reply addresses.  Perhaps this is the first line
of user services we need...

	Mark.

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 21:33:21 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: On the need to develop Internet user services

In article <RSW.91Jul8154619@tahiti.cs.brown.EDU> rsw@cs.brown.EDU (Bob Weiner) writes:
>
>Finally, Albert Langer (cmf851@anu.oz.au) made one or two good points
>about the complexity of some of the language in the document.  His
>thesis, however, that the document is totally useless to novice computer
>users is false.  The document assumes that some source of
>intelligence is available to which a user can go to obtain a conceptual
>or operational background on electronic mail use.  Virtually everyone
>has some access to such intelligence, whether it be through co-workers,
>suppliers, other literature, consultants, or friends.  With such
>intelligence where needed, the guide can help people properly address
>mail for worldwide delivery.

I think one of Mr. Langer's points, which is somewhat obscured in his
article, is that when you are explaining "how to use X" to a novice user,
you should tell them *what* will work, but whenever possible avoid
explaining *why* or *how*.
The explanation of E-mail addresses is a good example of this -
I don't see how a novice could use all this information to construct a
valid domain-style address for Joe Blow in Denmark.
Yes, he would probably be able to guess the last domain (.dk, that is!),
but that by itself is not really useful.
Inevitably, the novice will find out the adressee's E-mail address the same
way that I do: Joe will tell it to me, or I'll see it written down somewhere,
so there is probably no benefit in explaining it in any detail.

That said, it is apparent that Mr. Weiner's document is not intended for
the casual user.  It seems more appropriate for someone with an
interest in computers, who wants or needs to know more than just how to
make them go.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 22:51:04 GMT
From:      peter@ficc.ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk,comp.mail.uucp,comp.mail.sendmail
Subject:   Re: On the need to develop Internet user services

From bad to worse... first, some guy who thinks the whole world consists of
second year (at least) CS and EE students. Then another guy who thinks that
the first guy was doing a good job. How about this:

"To send mail to someone through the Internet mail system (called the Domain
Name System or DNS for reasons we shan't go into here) you need to know two
things: the full name of the computer the user is on, and their name on
that system.

"The full name of the computer is usually some sort of short, easy to remember
name, combined with the name of the company, university, or other institution
it's situated at, for example "intro.cs.miskatonic.edu". The person's name
on that computer is usually part of their name, initials, or a nickname. For
example, it might be "hpl" for "H. P. Lovecraft".

"You now join these with an atsign (@) to produce the user's address, like
this: "hpl@intro.cs.miskatonic.edu". To send them mail, you need to log in
to your own computer account and type "mail hpl@intro.cs.miskatonic.edu", or
some similar command (if you're using a commercial mail system like MCI Mail
you will need to go through some sort of menu system, check with your local
system administration."

There, that was easier. There's no reason you have to explain what the DNS
is, or how domains work, or any of that stuff... any more than you have to
explain that Australian postcodes are 4 digits, US Zip codes are 5 or 9, and
in Britain they use 6 letters and numbers. Or that "Bellevue Hill" is named
for the beautiful view of Sydney Harbour, while "FM 1960" in Houston used
to be an old farm to market road.
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      8 Jul 91 23:37:18 GMT
From:      mark@spectrum.CMC.COM (Mark Galbraith)
To:        comp.protocols.tcp-ip
Subject:   CMC TranServer (Was Re: CMC)

DISCLAIMER: I am the product manager for the CMC TranServer. So:

In article <1991Jul2.100441.27338@news.stolaf.edu> holdenm@grendel2.acc.stolaf.edu (Mark Holden) writes:
>
>	My CMC experience is limited to their TranServer Terminal Servers.
>I found their hardware to be buggy, nad it tended to die occasionally for
>inexplicaple reasons.  

We found and fixed a fairly rare proplem over six months ago, a memory leak
that would leave the box needing a reset. We very rarely had a customer
experience the problem and never saw the event here in test, but responding to 
a call to our Tech Support hotline, our software engineer found the leak.

>The product was diffucult to configure, cryptic, and poorly documented.

Well, I've had a number of customers tell me the opposite, that our
documentation is pretty complete and the TranServer is easy to set up and
configure. We have certainly tried to get the unit and the manual so that it is
easy for the end user to install. If anyone has a opinion otherwise, we are
very open to hear about it and improve the product. 
  
>Their support was almost non-existant, and in general it seemed that 
>they were jerking us around.  

CMC has a Tech Support person for the TranServer from 8AM to 5PM Monday-Friday,
at the hotline: 800-262-2290. Please, if ever you feel you're getting jerked
around by Tech Support, Email me with the details. 

>However, at the price, the units worked well enough once we got them 
>configured, only needing to be rebooted occasionally.  Most of my 
>dealings with these CMC products were ~6 months ago, and since I'm no 
>longer working at that job, for all I know, they've set everything right 
>and the machines work beautifully, but I doubt it.

Beautifully? Well, I'm not sure any terminal server can be described as
beautiful, but the TranServer works well/lasts a long time, is easy to use, and
runs a pretty repectable set of features (see disclaimer above :^). And the
price is certainly right. As I said, the TranServer does not need rebooting 
with the latest code. BTW, this version of software is available as an upgrade 
by calling the above 800 Tech Support number.

>Now don't get me wrong, I don't have it in for CMC, and I don't even hate that
>product, but I *am* deeply frustrated with both.
>
>						Mark Holden

I regret any difficulty Mark may have experienced with the TranServer or 
with CMC. If ever anyone has a problem along these lines, we want to hear 
about it. It's the only way we can continue to sell product--by making sure 
the customer (YOU) is satisfied. That means Emailing me or calling
the Tech Support hotline, or our regular number: 800-CMC-802.3. We will do our
best to make things right, up to and including our General Manager.

Mark Galbraith
CMC
mark@cmc.com

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 01:49:55 GMT
From:      postel@ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   DNS, EGP, and BGP


See RFCs 1035, 1035, 1163, 1164, 904.

--jon.


----- Begin Included Message -----

From tcp-ip-RELAY@NIC.DDN.MIL Fri Jul  5 08:09:31 1991
Date: 2 Jul 91 14:59:08 GMT
From: viusys!uxui!unislc!cas@uunet.uu.net  (Charles Stephens)
Subject: Correction, not GOSIP
Sender: tcp-ip-relay@nic.ddn.mil
To: tcp-ip@nic.ddn.mil


Hello,

	I have been roundly chastised for referencing DNS, EGP, and BGP
	as "GOSIP compliant protocols". Please accept my apologies.

	I am still looking for leads to source code for the three
	protocols. (Are they called "Internet Protocols", "DARPA
	Protocols", what???)

			Thnx for your patience, CAS
-- 
-------------------------------------------------------------
C. A. Stephens


----- End Included Message -----

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 03:40:40 GMT
From:      rjc@cstr.ed.ac.uk (Richard Caley)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk,comp.mail.uucp,comp.mail.sendmail
Subject:   Re: On the need to develop Internet user services

In article <RSW.91Jul8035637@reverb.cs.brown.EDU>, Bob Weiner (bw) writes:

bw> [example users guide].

I think there is a problem with trying to introduce these ideas in an
abstract manner. Giving a pseudo-BNF for internet addresses, for
example, is not going to work without lots more explanation.

I'd think a better aproach would be to work from the concrete upwards.
If someone has gotten to the point where they might be sending mail,
they must already know what a user name is (asume a multi-user system
for now). It is a fairly small step to the idea that Fred Bloggs'
login name is fbloggs so

	mail fbloggs

gets mail to him. From there it is a small step to the idea that if
Mary Smith uses the machine junkvax (cars have names, why not
machines) you should do

	mail p96qs9@junkvax

[ junkvax is, of course, run by a fascist computer unit :-) ]

As for the structure of domain names, if normal people can get the
hang of international direct dialing, domain nameing is no problem. A
domain name is just a telephone number with a bigger character set
because computers have more buttons than telephones.

Obviously someone with a (spit) PC at the end of a wet string link
will have bigger problems, but someone who gets such a link setup is
probably not completely naive in the way that a first year History
undergraduate is.

We don't expect people to totally understand snail mail addresses, I
regularly send mail to addresses in north Wales which are much more
incomprehensible than the worst UUCP nightmare. 

The bigest problem I had when starting out with mail was working out
what _my_ address was. 

--
rjc@cstr.ed.ac.uk		_O_
				 |<

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 08:41:03 GMT
From:      ccfj@hippo.ru.ac.za (F. Jacot Guillarmod)
To:        comp.protocols.tcp-ip
Subject:   Re: On the need to develop Internet user services

In <1991Jul8.173036.15629@eng.ufl.edu> mjw@wasp.eng.ufl.edu (Michael J. Wohlgemuth) writes:

>In article <1991Jul8.143814.5510@murdoch.acc.Virginia.EDU> randall@Virginia.EDU (Ran Atkinson) writes:
>>In article <1991Jul8.123049.23819@eng.ufl.edu> mjw@wasp.eng.ufl.edu (Michael J. Wohlgemuth) writes:
>>
>>>Well, I'm not sure that it is because of budgetary restrictions, but I
>>>don't know of one instance on campus where the University has paid for
>>>a subscription to Compuserve.  The only possible reason I can think of
>>>is that someone is afraid that nobody will be accountable for its use.
>>>I imagine that it would be the same for any Internet accessible services.

Another example is on the pure carrier level - we have an X.25 PAD here,
and it was an accounting nightmare keeping control of who accessed the
outgoing ports.  The solution was to make the facility less accessible
by taking it off the network, and get users to plug into it via a
patchboard, purely to associate a body with usage.

Other examples that spring to mind on a local level are access to a
networked laser printer or to a fax<->email gateway.

If it is difficult to control (or account for) use of facilities within
an institution, what hope is there of stopping a lab full of second year
Comp Sci students from running up megabills on facilities that are just
a 'telnet' away?  The recent fiasco involving BITFTP is a case in point
- it wasn't a hassle if you were running on dedicated lines, but add
the cost of a long distance dialup and the same room full of enquiring
minds and you had problems.

--
  F.F. Jacot Guillarmod     PO  Box 94     \        |     ccfj@hippo.ru.ac.za
  Computing Centre       Grahamstown 6140   \      /     +27 461 22023 xt 284
  Rhodes University        South Africa      ;___*/   33 18 30 S | 26 31 45 E

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 09:46:38 GMT
From:      jason@cs.utexas.edu (Jason Martin Levitt)
To:        comp.windows.ms,comp.misc,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.protocols.nfs
Subject:   Implementations of TCP/IP and NFS for DOS/Windows (Was:Re: Ftp, Tcp/Ip)

In article <7900@cactus.org>, fmill@cactus.org (Frederick Milling) writes:
> If anyone can help me I'd greatly appreciate it.  Can someone provide for me
> the names of vendors that make a version of tcp-ip (that includes ftp and
> telnet) for dos and windows.  I'd also would like to know if there is a
> shareware version of it, and where can I find it.

   The July 8th, 1991 issue of "Unix Today!" (pages 46 and 54) has a
review of NFS/TCP-IP implementations for DOS and Windows. 

   Reviewed:
   
     Beame&Whiteside  (416) 648-6556
     FTP              (617) 246-0900
     Network Research (800) 541-9508
     Sun              (800) USA-4SUN
     Wollongong       (800) 872-8649

   Mentioned but not reviewed:

     Frontier         (414) 241-4555

   Note: Other companies may appear to sell their own TCP/IP for DOS, but, in
         fact, just resell one of the listed implementations.     

   Freely available NFS server for DOS:

     SOSS (Son of Stan's Server), anonymous FTP from grape.ecs.clarkson.edu
                                  anonymous UUCP or BBS download from
                                  sir-alan.uucp  (812) 333-0450.

   >>>  There are no freely available NFS clients for DOS.  <<<

  Freely available TCP/IP for DOS:

     pcip,  anonymous FTP or UUCP from uunet.uu.net in /networking/pcip
     
"Unix Today!" is a twice-a-month tabloid available from CMP
Publications (516) 562-5000.

-----
   Jason Martin Levitt                          email: jason@cs.utexas.edu
  "Since there are virtually no rules, the catalog of information includes
   voluminous pornography, along with advice on recreational drugs,
   satanism, paganism, and sex slaves."
   --the Houston Chronicle describing the "internet" to its readers.
                                            Sunday, June 10th, 1990

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 13:27:11 GMT
From:      daniel@nstn.ns.ca (Daniel MacKay)
To:        comp.protocols.tcp-ip
Subject:   Re: On the need to develop Internet user services

1.17226@jarvis.csri.toronto.edu>

Peter Deutsch writes:
[automotive analogy, e.g. not many dozen years ago you had to know
everything about the car in order to use it]

Lowell Gilbert indicates that it may trivialize the problem.  I don't think
so at all.  To say that the sole function of the car is "transportation" is
an a lot like saying the sole purpose of the computer/network is
"information."

Peter's analogy of an electronic "bookstore" is interesting- I think most
people would have chosen the idea of an electronic "library." But staff in
a good bookstore are just as good at finding things as library staff are.
The difference is that you don't *pay* for things in a library.  Peter- I
hope I've caught your intent properly here.

Librarians have made a science out of all the things we're quibbling about.
Their whole raison d'etre is to help users find information.  We can help
the process of making WorldNet a place for users, by helping the librarians
learn about it, and helping them develop the tools they need to navigate.
We shouldn't expect to do the right thing the first time, either!  We may
have to build a sketch of a worldwide, all-singing, all-dancing information
system, then start from scratch again.  It's a big problem, and it won't be
easy to solve- but it is one of the most exciting things to happen in
networking in a while!

Don Wells writes:

> Yes. Librarians need to view themselves as managers of archives of
> _information_, not as managers of archives of cellulose fiber and
> carbon particles. Some (many?) librarians do see themselves this way
> today.  Computer people who specialize in information retrieval
> technology should feel a natural affinity with such librarians, and
> should cooperate with them and pay attention to what they know about
> providing information access services.

What he said.  More than that, I think, Donald.  I think we should feel
deference to such people!  It's their vocation, their specialty, and their
science.

The only reservations that I have are that librarians have had lots of
experience making printed information available.  We have built a far more
complex problem for them to solve.  There are resources on the Internet for
the most bizarre things you can imagine-
 - an archive of human chromosomes, 
 - source for a program that creates a travesty of its input, 
 - a collection of pictures of ladies doing unusual things with vegetables, 
 - the sound of a guy in England saying "Meep," 
 - a computer that connects you to other computers which provide access to
   library catalogs
 - a way for people to interactively broadcast naughty propositions to each
   other
 - the weather
 - the status of a Coke machine somewhere in the world.

This is current stuff.  There's going to be some really interesting
resources out there in a few years' time, and making them available on the
WorldNet -- our job -- is going to be the easy part.  The job of building a
system of indexing, a system that will encompass all the kinds of resources
we're going to see and make them findable, is going to be the real work
here- and the Unix Weenies aren't the guys to do it!

-dan
--
	Daniel MacKay				daniel@nstn.ns.ca
	NOC Manager, NSTN Operations Centre	902-494-NSTN
	Dalhousie University, Halifax, Nova Scotia, Canada

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 13:48:10 GMT
From:      rs@sun09.com (Rick Silterra)
To:        comp.protocols.tcp-ip
Subject:   ftp file type extenstion



I am adding to ftp the capability to write to a non-standard file
type ("contiguous").  I would like this capability in my non-standard 
ftp server to be available to standard ftp clients.

Should I
1) rely on some peculiar encoding of the path to signal creation of a contiguous
file?
2) implement a new file structure?


If I implement 2), can I count on the "quote" command being available on
the client to do "quote stru continguous" on my server?

I am interested in people's opinions on this, and experiences with similar
extensions.

Thanks.

Rick Silterra

--
Rick Silterra Usenet: rs@cci.com or uu.psi.com!cci632!rs or uunet!ccicpg!cci632!ccird2!rs or rs@ccird2
Mail: Rick Silterra                   <<Being a BALD HERO is almost as FESTIVE as a TATTOED KNOCKWURST.>>
      Computer Consoles Inc           << ESC-52 M-X yow >>
      97 Humboldt St.                 Any opinions expressed above are my own,
      Rochester NY 14609-7493         and not those of Computer Consoles,Inc.

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 13:48:39 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: On paying for the Internet (was: Re: On the need to develop . . . )


I'd like to add two comments to this discussion.

1) Several people have observed that its easy for organizations to
budget for fixed costs, but virtually impossible for them to budget for
variable costs.  I disagree.  Almost every organization I know of,
universities, non-profits, and commercial, budgets at some level for use
of telephone services, use of postal services, use of package services,
 ...  All of these are variable cost services based on usage.  Of course
the more users who are grouped together in the budget, the more the
costs take on the appearance (via statistical properties) of being fixed
costs.  I don't see any intrinsic reason why budgeting for information
services should be different.  In fact, I'll bet that most organizations
already budget for access to some kinds of information services (e.g.,
the company library has access to some information providers, the
marketing department gets D&B financial reports on current or
prospective customers).

2) I have heard (I can't vouch for the accuracy of the story) that when
the Boston-area rapid transit system was considering a fare increase
several years ago, a study was commissioned to determine the "optimal"
fare (in terms of minimizing transit system's annual loss).  The alleged
conclusion of the study was that the cost to the taxpayers would be
minimized if the fare-collectors were fired and the fare was free (this
analysis may have included savings in road maintenace due to reduced
highway traffic; I don't know).  But, goes the story, this approach was
rejected by the decision makers, who felt that the taxpayers would rebel
against the idea of giving free transportation to people who could
afford to pay something for it.  Is this relevant to government
decisions about allowing commercial use of the Internet?  To support for
information providers?  To the NREN issue? 

Alex McKenzie
 

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 13:59:07 GMT
From:      marc@marcal.uucp (Marc Veeneman)
To:        comp.protocols.tcp-ip
Subject:   Re: On the need to develop Internet user services

simon@liasun2.epfl.ch (Simon Leinen) writes:

>In article <RSW.91Jul8035637@reverb.cs.brown.EDU> rsw@cs.brown.EDU
>(Bob Weiner) writes:
 
>   Country is typically a two letter country code for mail outside of
>   the US:
 
>                ...
>                de                 Denmark
>                ...
 
>Small correction: DE is the ISO country code for Germany
>(DEutschland).  Denmark is `DK'.

Could someone email me the entire ISO country code list?  I don't
have ftp privileges.

Thanks.
-- 
Marc Veeneman 		Marcal Systems Corporation    voice:	1 708 516 4555
marcal.uucp!marc	 Custom Financial Service	fax:    1 708 516 4411

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 13:59:28 GMT
From:      daniel@nstn.ns.ca (Daniel MacKay)
To:        comp.protocols.tcp-ip
Subject:   Re: On the need to develop Internet user services

1.17226@jarvis.csri.toronto.edu>

thomson@hub.toronto.edu (Brian Thomson) writes:

>I think one of Mr. Langer's points, which is somewhat obscured in his
>article, is that when you are explaining "how to use X" to a novice user,
>you should tell them *what* will work, but whenever possible avoid
>explaining *why* or *how*.

This is how I handle it, too.  For new users, there are a few very simple
rules regarding email addresses:
 - Right now, there isn't any way to look up someone's email address.  You
   have to get it from them or someone else, or see it somewhere.
 - Get it exactly right, including Os vs 0s, ls versus 1s, the funny
   characters, and all.  Getting it close won't work, guessing won't
   work, and trying to memorize them doesn't work (for me.)
 - Your system manager can help you with email addresses.

I also think we're worrying about email addresses too much.  So what if you
can't look up someone's email address just because you know their name and
where they work?  Can you look up their snail-mail address using the same
information?  Can you guess at their snail-mail address?  How do you find 
someone's snail-mail address, anyway?  Why, 
 - you give them a call, or
 - you look at a piece of correspondence from them.

The main difference is that our postal system can cope with small mistrakes
in an address, and our email system can't.  Otherwise, I think people have
very little to complain about.  Furthermore, most WorldNet users have a
resource person who they can ask for help.  It would be great if those
resource people could progress from repeatedly answering questions like
"Why does mail to 'mikey@brownvm' bounce?" some time in the next few years,
but for now, that's what we're here for!

-dan
--
	Daniel MacKay				daniel@nstn.ns.ca
	NOC Manager, NSTN Operations Centre	902-494-NSTN
	Dalhousie University, Halifax, Nova Scotia, Canada

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 14:08:00 GMT
From:      peter@ficc.ferranti.com (peter da silva)
To:        comp.protocols.tcp-ip,comp.mail.uucp,comp.mail.sendmail,comp.org.eff.talk,comp.archives.admin
Subject:   Re: On the need to develop Internet user services

In article <91Jul8.172106edt.936@smoke.cs.toronto.edu>, moraes@cs.toronto.edu (Mark Moraes) writes:
> cmf851@anu.oz.au (Albert Langer) writes:
> >Header reply address wrong. Use cmf851@csc2.anu.edu.au
 
> An interesting point.  The Matrix would be a much nicer place if we
> could rely on header reply addresses.

Perhaps Albert needs to co-ordinate with his local mail/news folks. He should
be able to put "Reply-to: cmf851@csc2.anu.edu.au" in his headers no matter
what his "From:" line says.

> Perhaps this is the first line of user services we need...

It's the job of the administrators to make this sort of thing work correctly.
If they can't do that, it doesn't matter what services are available nobody
will be able to find them.
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 14:37:14 GMT
From:      galvin@TIS.COM (James M Galvin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Security Options status


	I'm looking for information regarding the status of the IP Security
	Option.  An update to MIL-STD-1777 or release of rfc1108 was
	planned.  If information is available regarding the changes which
	will occur to the draft security option as described in rfc1038,
	this would also be useful.

There is an internet-draft that is the revision to RFC 1038, in effect the
RFC 1108 that was never released.  It is located in the usual places with
the filename "draft-ietf-ahwgipso-ipso-00.txt".

In addition there is a Commercial IP Security Option working document
circulating within its working group.  I believe it will be available as an
internet-draft soon, but no later than immediately after the next IETF I
would expect.

Jim

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 14:45:53 GMT
From:      coates@uc780.umd.edu
To:        comp.protocols.tcp-ip
Subject:   Latest on IBM and TCP/IP

I reread the Communications Week article and here is a paraphrase of what they
say about IBM's latest announcements on non-IBM including tcp/ip protocol
support.
-------------
The enet adaptor IBM is putting out is for the 3745 Comm Controller and its
model number is 375. The price of the card is between $8,030 and $21,420.
No mention of how capacity or capability. (Better be a lot (-:)
IBM will transport TCP/IP through SNA networks by encapsulating it in SNA
frames. 
-------------
The 3745 is "pegged" for ISDN support in the future.
-------------
The two new models of the 3745 family are "faster high-end versions". They are
the 310 and the 610, priced from $189,550 to $249,550.
------------- 
IBM actually rolled out a network management system for monitoring Unix and AIX
based systems. It will run on RS/6000's and Sun Sparcstations. It costs $3,150.
-------------
IBM co-develped with Network Equipment Technologies Inc a board called the LWX
which plugs into NET's Integrated Digital Network Exchange T1 multiplexor. The
board provides multi-protocol routing and bridging based on Cisco routing code.
"Unlike a stand-alone bridge-router, the LWX acts as a 'bandwidth manager,'
said Jeffrey Held, a partner with Ernst & Young, Vienna, Va. 'The problem with
routers is that they are not as robust' as T1 multiplexors, he added."
-------------
"For years, we thought customers would tend toward OSI over TCP/IP. But we are
not seeing that." 
		Ellen Hancock, IBM VP and Gen. Mgr


**************************************************************************
*                     Elliott Coates, washington dc                      *
*                         coates@uc780.umd.edu                           *
*                             coates@uc780.bitnet                        *
**************************************************************************

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 14:51:44 GMT
From:      barrett@Daisy.EE.UND.AC.ZA (Alan P Barrett)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk,comp.mail.uucp,comp.mail.sendmail
Subject:   Re: On the need to develop Internet user services

In article <RSW.91Jul8035637@reverb.cs.brown.EDU>,
rsw@cs.brown.EDU (Bob Weiner) writes:
  
> This document discusses how to address mail to or from both Usenet (via UUCP =
> UNIX to UNIX Copy Protocol) and the Internet (via SMTP = Simple Mail Transfer
> Protocol).  Mail through the Internet can reach Usenet, Compuserve, MCI Mail,
> and many research and corporate organizations throughout the world.

Pet Peeve #17:  Usenet is not UUCP.  UUCP is not Usenet.  Usenet is not Mail.

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za             Bang: m2xenix!quagga!undeed!barrett

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 14:53:24 GMT
From:      cas@unislc.uucp (Charles Stephens)
To:        comp.protocols.tcp-ip
Subject:   Source code request: DNS EGP BGP

Hello,

	This exchange has been very educational and I thank everyone
	for their responses. However, I'm still in the dark about
	where I might obtain SOURCE code for the TCP-IP protocols
	listed below.

		Domain Name Server - RFCs 882, 973, 974, 1035, and 1101

		Exterior Gateway Protocol - RFCs 888 and 904

		Border Gateway Protocol - RFC 1163

	One of the responses noted that:

	"Somewhere, there is an implementation of gated, a UNIX daemon
	that supports Interior and exterior gateway protocols, that
	supports both BGP and EGP.  It will be available from some U.S.
	university - hopefully you'll get a reply from someone."

		(Thank you IAN HEAVENS.)

	To BOB STRINGFIELD,

		No, I'm not working on the nameserver for the Sperry 5000.

	**********************************************************
	* I no longer need documents or references to documents. *
	**********************************************************

						Thnx, CAS
-- 
-------------------------------------------------------------
C. A. Stephens

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 15:27:00 GMT
From:      kdb@intercon.com (Kurt Baumann)
To:        comp.protocols.tcp-ip
Subject:   Re: On paying for the Internet (was: Re: On the need to develop . . . )

In article <1991Jul6.075622.16265@cs.mcgill.ca>, peterd@cs.mcgill.ca (Peter 
Deutsch) writes:
> So let's continue to beat this poor simile for a while.
> If the Internet is like a highway system, then are service
> providers like trucking companies? Or are they more like
> traditional merchants, shipping goods over the highway
> system? I think the later, perhaps with an emphasis on

Actually they are the gas and food stations along the way.  You know next 
service is 25 miles?  Or, stop at Luray Caverns... :-)  All of these charge for 
services, but wouldn't exsist if the highway system wasn't in place.

I don't see why there shouldn't be certain services on the network that are 
directly billed.  Say for example Lexus.  There are several Lawyers that I know 
of on the net, I am sure that they would find it useful to do a search online 
while they take a look at their mail.  (think of the wars that would go on in 
misc.legal :-))  All of these services could be billed directly to the 
institution based on use, or for a flat fee.  I don't see why there is a 
problem here.  The highway system doesn't charge Luray Caverns for the benifit 
it recieves from the highway.  Certain services that are directly on the 
highway, like those enumerable rest/services stops that you find in New Jersey 
do pay, but ninth or more percent do not.

Think about the US without it's highway system.  Not a pretty sight.

Hmm, I could go on about this, but unfortunatly I have work to do :-)


Kurt Baumann                  703.709.9890
InterCon Systems Corp.   Creators of fine TCP/IP products for
                                       the Macintosh

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 15:58:38 GMT
From:      lawrence@nvanbc.UUCP (Lawrence Harris)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   Re: INETD Source (looking for internet wrapper)

In article <9107081417.AA05936@crc.sofkin.ca> morvai@CRC.SOFKIN.CA (Steve Morvai) writes:
>
>    Does anyone know where I may find the source for "inetd" with
>Access Control List (ACL) modifications.
>
>Software Kinetics Ltd.
>PHONE:(613) 831-0888
>FAX:  (613) 831-1836
>MAIL: 65 Iber Road,POB 680,Stittsville, Ontario,K2S 1E7,CANADA
>INTERNET: morvai@sofkin.ca

I too am looking for something link this.  There was a posting about 2
months back for a program that could "wrap" an internet daemon and filter
incoming requests so you could control what machines and nets a new request
was allowed to come from.  The multinet package by TVG for VAX/VMS has this
ability and for the sequrity concious system administrator it is a dream come
true.

If any one knows where I could get this, ftp or otherwise, please drop me
a line.  I'll post a summary if I hear anything.

Thanks much in advance.
------
UUCP: {uunet | ubc-cs}!van-bc!nvanbc!lawrence
INET: lharris@hcs.ca
MAIL: 8506 Woodtrail Place, Burnaby, B.C., Canada V5A 4A9
-- 

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 16:32:36 GMT
From:      postel@ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Looking for info on netstat protocol


Michael:

"netstat" is a dead letter.  

It was useful in the olden days of the ARPANET, 
when there were about 15 hosts.

--jon.


   Date: 8 Jul 91 16:39:33 GMT
   From: haven.umd.edu!umbc3.umbc.edu!juno.cs.umbc.edu!wessling@louie.udel.edu           (michael wessling)
   Subject: Looking for info on netstat protocol
   Sender: tcp-ip-relay@nic.ddn.mil
   To: tcp-ip@nic.ddn.mil
   
   Does anyone have information on the netstat protocol, or knows where I can
   get information. Is there an "offical" specification ?
   
   	-Michael
   
   	  wessling@algol.cs.umbc.edu
   

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 17:48:48 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: On the need to develop Internet user services

In article <ccfj.679048863@hippo.ru.ac.za> ccfj@hippo.ru.ac.za (F. Jacot Guillarmod) writes:
>If it is difficult to control (or account for) use of facilities within
>an institution, what hope is there of stopping a lab full of second year
>Comp Sci students from running up megabills on facilities that are just
>a 'telnet' away?

They will be more than "just a 'telnet' away".  For instance, if Compuserve
were on the Internet, you'd still have to have a Compuserve account, and
enter your user name and password in order to login.  Telnetting would just
get you to the login prompt, just as dialing up currently does.

There seems to be an assumption among some people that commercial services
would operate the same way as the current free services, but that's silly.
A commercial file archive service wouldn't allow anonymous FTP; it would
probably require a regular login with a real password.  

Of course, if everyone in the CS lab finds out the password, they could run
up huge bills.  But this isn't a new problem, nor is it specific to
networking.

Something like Kerberos could be used in new versions of protocols to
eliminate the need for entering passwords when accessing services.  But it
would still have to be the case that the user has an account with the
service, so that it knows that payment is authorized.  Maybe someday the
infrastructure will support secure transmission of billing information
(e.g. credit/debit card info) so that it will not be necessary to
prearrange billing, but this isn't a necessary precondition to commercial
services.  Another possibility would be for the network providers to
provide the billing services, much as the PSTN does for 900 numbers; this
could be what Jacot was concerned about, so I suspect this wouldn't be
accepted unless a reasonable "blocking" mechanism were made available.
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 19:28:13 GMT
From:      gts@brillig.berkeley.edu (Greg Small)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1001 Implementations

In article <9107081407.aa24659@Note2.nsf.gov> mmorse@NSF.GOV writes:
>Does anyone know of a P node implementation of RFC 1001 (Netbios over
>TCP/IP)?  I'd be interested in hearing from vendors or users. --Mike

The Ungermann-Bass TCPBIOS is B mode but has a small table of Netbios name
to IP address bindings which allow Netbios connections off of the local wire.

Gregory T Small                                      (415)642-5979
Personal Computer Networking & Communications        gts@violet.Berkeley.EDU
Workstation Support Services - Software Group        ucbvax!jade!gts
267 Evans Hall                                       SPGGTS@UCBCMSA.BITNET
University of California, Berkeley, Ca 94720

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 20:02:34 GMT
From:      brian@ka.excelan.com (Brian Meek)
To:        comp.protocols.tcp-ip,comp.sys.novell
Subject:   Re: Is there a PC or NLM RARP server?

In article <29448@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson drilex1) writes:
>We're thinking of getting into Novell's LAN Workplace for DOS
>in a big way.  I'd like to avoid putting config info on each
>workstation.  LWP does not support BOOTP, but it does support RARP.
>Unfortunately, the projected configuration doesn't have any
>RARP-capable machines on the PC subnets--just PCs, a Netware 
>3.11 server, and a cisco router.
>
>Does anyone have an RARP server which can live in a PC, or even
>better can run as an NLM?  I know one shouldn't be too hard to write,
>especially for the PC, but it would be even easier to find one.
>
>Craig Jackson
>dricejb@drilex.dri.mgh.com
>{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}

I like your idea about "getting into Novell's LAN WorkPlace for DOS in
a big way" :-).  In support of this mind-set, and in response to your
query, an engineer here at Novell has developed a nifty little RARP
server for DOS over the holiday.  

The RARP server is a TSR that runs over the TCP/IP stack found in v4.0 of
LAN WorkPlace for DOS.  RARPD.EXE reads a %EXCELAN%\tcp\ethers file at
startup and responds to RARP requests.  It's resident size is quite small
(800 bytes + 10 bytes per record), and it is unloadable and "loadhi(gh)able".

Those of you wishing to try it out may retrieve it via anonymous FTP from
sjf-lwp.novell.com (130.57.11.140): ~lwp4dos/rarpd/*.*  Please email any
bug reports to me.

BOOTP will take a bit more time :-). 

-- brian
____________________________________________________________________________
         Brian Meek       Novell, Inc. - 2180 Fortune Dr. San Jose, CA 95131
Internet mail: brian@novell.COM                        Phone: (408) 473-8375

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 20:15:55 GMT
From:      coates@uc780.umd.edu
To:        comp.protocols.tcp-ip
Subject:   RE: MAC Source Routing for TCP/IP/Token-Ring: Need Info

Please 'reply' or e-mail me also.


**************************************************************************
*                     Elliott Coates, washington dc                      *
*                         coates@uc780.umd.edu                           *
*                             coates@uc780.bitnet                        *
**************************************************************************

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 20:27:00 GMT
From:      coates@uc780.umd.edu
To:        comp.protocols.tcp-ip
Subject:   What is an archie?

Is it an archive, nameserver or combo?
Please post.
Thanks--
BTW ( <-- whatever that literally means) Forgive my questions, I'll answer
all questions I can when I can. 


**************************************************************************
*                     Elliott Coates, washington dc                      *
*                         coates@uc780.umd.edu                           *
*                             coates@uc780.bitnet                        *
**************************************************************************

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      9 Jul 91 23:09:55 GMT
From:      emv@msen.com (Ed Vielmetti)
To:        comp.archives.admin,comp.org.eff.talk,comp.protocols.tcp-ip
Subject:   OCLC Internet Research grant


forwarded from com-priv, comments intact.  

CNIDIR-L is a potentially quite interesting list, though it's not yet
gatewayed into Usenet so it has perhaps less wide of a readership than
it might otherwise get.  I'd recommend further net.discussion go to
comp.archives.admin.

I spoke with Erik Jul <ekj@RSCH.OCLC.ORG> this afternoon w/regard to
how comp.archives fits into this kind of research.  The apparent focus
of this production is *not* to produce some kind of all-encompassing
catalog of materials, but rather to work out an understanding of what
all kinds of materials are on the internet and what sort of data
elements are needed to adequately describe and catalog them.  Since
the volume of stuff is already currently in the tens of gigabytes
range (very conservative) and might be inching up into the terabyte
arena, they have a substantial job ahead of them, wish them luck and
lend them a hand.

-- 
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
       MSEN, Inc. 628 Brooks Ann Arbor MI 48103 +1 313 741 1120
 for information on MSEN products and services contact info@msen.com

From: Bob Sutterfield <bob@morningstar.com>
Message-Id: <9107092023.AA04029@volitans.morningstar.com>
To: com-priv@uu.psi.com
Subject: library research at OCLC

I saw this on a newsgroup down at the local university, and thought it
might tie in nicely with some of the recent discussions here.  (The
fact that such a Coalition is homed on a Listserver ties in nicely
with some less-recent discussions here too, but I won't bring that up
again :-)

Newsgroups: osu.network,osu.general
From: Bob_Dixon@osu.edu
Subject: Internet Research Funded

This announcement is important and relevant to the Internet information
projects under way at OSU and many other places.

                                    Bob
                ---------------

Date: Tue, 9 Jul 1991 08:56:21 EDT
>From: Erik Jul <ekj%RSCH.OCLC.ORG@CUNYVM.CUNY.EDU>
Subject: Internet Research Funded
Sender: CNIDIR-L - Coalition for Networked Information Working Group
 <CNIDIR-L@UNMVM.BITNET>

FOR IMMEDIATE RELEASE                           FOR MORE INFORMATION CALL:
                                                Erik Jul (614) 764-4364
                                                Nita Dean (614) 761-5002

    U.S. DEPARTMENT OF EDUCATION PROVIDES GRANT FOR INTERNET RESEARCH

     DUBLIN, Ohio, July 3, 1991--The U.S. Department of Education has awarded
a $48,675 Library Research and Demonstration Program grant to support an
investigation and analysis of Internet resources to be conducted by the OCLC
Office of Research.  The grant funds 76 percent of the $63,694 project; OCLC
is contributing the balance of the project costs.  The one-year project is
funded from Oct. 1, 1991, through Sept. 30, 1992, through the federal Higher
Education Act of 1965, Title II-D.
     The project, "Assessing Information on the Internet: Toward Providing
Library Services for Computer-Mediated Communication," will investigate the
nature of electronic information available on the Internet--a high-speed,
global network of networks--and the problems associated with providing
systematic access and traditional library services.  The study, managed by
Martin Dillon, Director, OCLC Office of Research, is expected to provide a
detailed analysis of textual information on the Internet.
     "Computers and high-speed communication networks are changing the ways
in which knowledge is created, stored, distributed, and used, and this
requires a rethinking of traditional library services that have evolved over
centuries: locating, acquiring, cataloging, indexing, storing, retrieving,
accessing, and disseminating information and providing reference services,"
Dr. Dillon said.  "This project is an exciting step toward systematically
providing these value-adding library services for electronic information."
     Using published printed resources, known electronic resources, and
online investigation, project staff will conduct an extensive search on the
Internet to locate and sample electronic information resources.  Based on
data collected, project staff will develop and test a descriptive taxonomy
of Internet resources and compile a list of data types or fields present in
electronic information.  This work will complement related efforts undertaken
by the Coalition for Networked Information and others who are developing
Internet resource lists and directories.
     Analysis of this information is expected to lead to a description of
the nature of text resources on the Internet and recommendations toward the
establishment, extension, or implementation of cataloging or other descriptive
standards and methods to facilitate the discovery and use of electronic
resources in a network environment.
     The findings of this study are expected to help libraries, information
providers, and standards organizations move closer to the goal of providing
library services for computer-mediated communication on the Internet.
     OCLC is a nonprofit computer library service and research organization
whose computer network and products link more than 11,000 libraries in 41
countries and territories.

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 91 00:45:03 GMT
From:      peterd@cs.mcgill.ca (Peter Deutsch)
To:        comp.protocols.tcp-ip
Subject:   Re: Commercialization of the Internet...

In article <9107081328.aa26594@Note.nsf.gov> mmorse@NSF.GOV (Michael Morse) writes:
.  .  .
>I think it's a great idea!  The only possible problem I see is that
>some of these services we're discussing are in some ways derivative
>works, in that they depend on other services for input.  Some one might
>say that the *real* value is in the ftp-able archive, so why is archie
>getting all the money?  I think for derivative works you might want to
>provide a free access method that might not have all the bells and
>whistles of your fantastic shareware product.

We do! You can:

ftp site1
ls      hmmm, nope...

ftp site2
ls      hmmm, nope...

ftp site3
ls      hmmm, nope...

etc.etc.etc

;-)


Seriously, I wouldn't argue that archie is a derivative
work. I would argue that it is a value added service. What
we give you is not information, but information about
information. Sort of like paying someone for a title
search on your house. Of course you could do it yourself,
but still most people pay to have it done. We're doing
something similar.

My views on this are now pretty well known. I'd like to
see people paid to provide such services. The current
Internet infrastructure	means pay per view is hard
technically and maybe impossible culturally. That's why I
suggested regionals as a suitable source. They're
receiving funds from users and in contact or capable of
being information providers.

>
>I've always wondered why Internet/Unix people give away such good
>software.  I look at the case of mush vs cc:Mail.  Both are credible,
>complete, robust mail user interfaces.  In the first case, it is given
>away to anyone who wants to use it, in the second it is built into a
>best-selling PC product bringing in millions of dollars in revenue.

I understand that the creator of mush has announced plans
to _sell_ an X version of this program and is
discouraging/preventing others from working on an X port.

>Probably the answer is that the author of mush was not interested in
>all the non-software tasks that go into building a business.  The
>shareware route offers a middle ground.  You can get rewarded for your
>labor, but you have to maintain some responsibility for support.

Well, without going into too much detail we are not blind
to the potential commercial possbilities of archie and its
ilk, but we've really been trying to "play the game" and
make it available through a model along the lines of FSF.
I have asked my regional to form a not-for-profit group to
sponsor further development. This was not endorsed, at
least not yet and we are still exploring other avenues.

Suffice to say, we'd like to see this kind of service
available, we're not averse to making money, but would
also just like to give something back to the net. We've
actually had conversations much like this thread
internally and have no intentions of trying to hold archie
for ransom. Whatever happens, we expect the existing
service will continue in some form at some site or sites.
I just can't say what the follow-ons will look like or how
they will be funded.

				- peterd

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

Zen Master to hot dog vendor:  "Make me one with everything."

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

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 91 05:32:58 GMT
From:      Murray_RJ@CC.CURTIN.EDU.AU
To:        comp.protocols.tcp-ip
Subject:   tcp/ip mailing list

Please delete me from this group, thanks. It's not quite what I wanted.
(note that it's being sent to nmurrayr@ccc.curtin.edu.au instead of
...@cc.curtin.edu.au -- this is causing my postmaster some headaches.
Thanks,
.....Ron

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 91 08:20:27 GMT
From:      TAYBENGH@NUSDISCS.BITNET (THE AGEIS)
To:        comp.protocols.tcp-ip
Subject:   Question in the timer management in delta-t protoco...


Hi,
        I have read the paper by Flecther and Watson on delta-t protocol.
I am puzzled by the amount of time that the protocol need to keep connection
information. It state that the receiver must wait for 2MPL+R+A, and sender
must wait for 3MPL+R+A before they can discard INACTIVE connection record.
Since a packet cannot live longer than its MPL, then why must receiver waits
for 2MPL+R+A as in delta-t, but NOT MPL+R? The same question appears for the
receiver too. Is it a purely engineering decision to keep longer than MRL+R,
or I miss sth?
        Anybody who understands delta-t protocol please shed some light on
me. I am quite urgent to know the question.
        Thanks alot.

p/s: A - time to generate a acknowledgement
     MRL - maximum packet life time
     MRR - maximum retransmission interval
      ^
      |
      R (Op! should be R!)


- Beng Hang (email: taybengh@nusdiscs.bitnet)

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 91 11:58:00 GMT
From:      SCOTT@SKLIB.USASK.CA (Peter Scott/Order Unit/U of Saskatchewan Library)
To:        comp.protocols.tcp-ip
Subject:   Re: What is an archie?

Elliott Coates writes

>Is it an archive, nameserver or combo?

        Archie: The McGill School of Computer Science Archive Server
 
To access type telnet quiche.cs.mcgill.ca or 132.206.2.3
login: archie
 
 Archie: the McGill School of Computer Science Archive Server Listing Service
 ----------------------------------------------------------------------------
 
Given the number of hosts being used as archive sites nowadays, there can
be great difficulty in finding needed software in a distributed
environment. You may know that the software that you need is out there, but
it can sometimes be difficult to find.  The School of Computer Science at
McGill University has one solution to the problem - "archie".
 
Archie is a pair of software tools: the first maintains a list of about 600
Internet ftp archive sites.  Each night software executes an anonymous ftp
to a subset of these sites and fetches a recursive directory listing of
each, which it stores in a database.  We hit about 1/30th of the list each
time, so each site gets updated about once a month, hopefully balancing
timely updates against unnecessary network load.  The "raw" listings are
stored in compressed form on quiche.cs.mcgill.ca (132.206.2.3), where they
are made available via anonymous ftp in the directory ~ftp/archie/listings.
 
The second tool is the interesting one as far as the users are concerned.
It consists of a program running on a dummy user code that allows outsiders
to log onto the archive server host to query the database. This is in fact
the program we call Archie.
 
 
Users can ask archie to search for specific name strings.  For example,
"prog kcl" would find all occurences of the string "kcl" and tell you which
hosts have entries with this string, the size of the program, its last
modification date and where it can be found on the host along with some
other useful information. In this example, you could thus find those
archive sites that are storing Kyoto Common Lisp. With one central database
for all the archive sites we know about, archie greatly speeds the task of
finding a specific program on the net.
 
Complete anonymous ftp listings of the various sites that we keep in the
database may be obtained via the 'site' command and for a list of the sites
which we keep track of, see the 'list' command.
 
Archie also maintains a 'Software Description Database' which consists of
the names and descriptions of various software packages, documents and
datasets that are kept on anonymous ftp archive sites all around the
Internet. The 'whatis' command allows you to search this database.
 
Send comments, bug reports etc to
 
                        archie-l@cs.mcgill.ca
 
If you have a favourite anonymous ftp site that archie doesn't seem to
maintain, or if you have additions or corrections to the Software
Description database, send mail to
 
                        archie-admin@cs.mcgill.ca
 
Archie was written and is maintained by Alan Emtage (bajan@cs.mcgill.ca)
and Bill Heelan (wheelan@cs.mcgill.ca). Peter Deutsch (peterd@cc.mcgill.ca)
provided (and continues to provide) ideas and inspiration.

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 91 14:05:54 GMT
From:      dgale@NOTE2.NSF.GOV (Douglas Gale)
To:        comp.protocols.tcp-ip
Subject:   NIS Mailing 3


Minutes of an Open Hearing on
Network Information Services
held at the National Science Foundation on
10 June 1991


NSF Panel: Doug Gale, Don Mitchell, and Steve Wolff.

Attendees:


Ed Albrigo, COS
Aaron Asrael, DGC
Jeffrey Bavy, New York University
Brendan Becker, JVNCNet
Lynn Behnke, Federal Networking Council
Laura Breeden, FARNet
George Brett, University of North Carolina
David Bridge, Smithsonian Institution
Bob Bryer, Wollongong
George Clapp, Ameritech
John Dale, COS
Everett Dowd, Extension Services-USDA
Robert Enger, CONTEL
Mike Fidler, Mitre
Jack Hahn, SURANet
John Hankins, CICNet
Sergio Heker, JVNCNet
Al Hoover, ANS
Rick Huber, AT&T
Laura Kellcher, Merit
Barbara Kurshan, EDUCOM
Brian Lev, NASA
E. Paul Love Jr., GA/CERFNet
Jose-Garcia Luna, SRI
Altie Metcalf, NSF
Butch Mills, Martin Marietta
Gregory Parham, Extension Services-USDA
Chris Peterson, SRI
Don Preuss, NIH
Ken Rossen, Interactive Systems
Karen Roubiecek, BBN
Bill Russell, New York University
Marvin Schoffstall, PSI
William Schrader, PSI
Dana Sitzler, Merit
Sprakash, ATLT
George Strawn, Iowa State University
Ron Toth, AT&T
Taylor Walsh, Research and Education 
Networking Newsletter
Russ Wright, LBL
Wengyik Yeong, PSI
Biu Youcik, NASA-GSFC

Introduction 

D. Gale opened the hearing by welcoming everyone and went on to 
describe the purpose of the hearing, which was to answer questions 
regarding the NSF's anticipated solicitation for Network Information 
Services for the domestic portion of the Internet and to invite 
comments and opinions regarding the needs that an information 
services architecture should address.  He then quoted from a report 
submitted to the NSF by EDUCOM in May of 1991 titled "Interim NREN 
Network Information Services, Report of a Workshop and 
Interviews":

"In cooperation with the Internet community, the agencies that are 
part of the Federal Networking Council (FNC) are developing an open 
and competitive solicitation for Network Information Center (NIC) 
services to include Internet Registration Services, Directory 
Services, and Information Services.  These NIC services will provide 
support for the domestic portion of the Internet and its component 
NICs.  The services are intended to continue as the Internet evolves 
to the Interim NREN."

"The development for a solicitation for NIC services is occurring 
under unusual time pressure because of the nearly simultaneous 
expiration of contracts for NIC services at the NSFNET Network 
Support Center (NNSC), (provided by Bolt, Beranek, and Newman), 
and for NIC services for the Defense Data Network (DDN) and related 
Internet NIC services (provided by SRI International)."

D. Gale stated that while the meeting would be taped, those tapes 
would not be transcribed.  Notes would be taken and used to prepare 
a detailed record of questions and answers as well at to prepare 
brief minutes that would be distributed to those in attendance and 
over the Internet.  Substantive questions raised in the hearing which 
are not answered in the specific content of the Project Solicitation 
will be contained in an addendum to the Project Solicitation.

Comment and Question/Answer Session

A wide variety of opinions were expressed regarding the user 
services required by the various components of the national research 
and education community (K-12, individual users, small institutions, 
etc), the responsibilities of the different network levels (campuses, 
mid-level networks and the national NIC), and the mechanisms for 
providing the necessary services.

D. Gale stated that the development of a solicitation was an ongoing 
process and that  at least one more draft would be circulated on the 
Internet and comments invited before a final draft was submitted to 
the Federal Networking Council.  He said that he anticipated that the 
final draft be completed by late summer, that the solicitation be 
issued in the Fall of 1991, and an award be made in the Spring, 1992.

Before concluding the hearing, Doug Gale introduced George Strawn 
of Iowa State University who will become the Program Director for 
NSFNET on July 1, 1991, and will assume responsibility for 
continuing the development of a Project Solicitation.  Dr. Strawn 
can be reached at (202)357-9717 or gstrawn@nsf.gov.

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 91 14:58:57 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   growing pains...








UCL.CS                                                      J. Crowcroft
Request for Comments:  ????                                          UCL
                                                               July 1991



                     address Revolution protocol
                                or
              Converting 32 bit internet addresses into
                     32 Bit Internet Addresses.

Status of this Memo

   This memo suggests an Experimental Protocol for the Internet
   communities.  Distribution of this memo is inexcusable.

Table of Contents

   1. Introduction...........................................    1
   1.1 Motivation............................................    2
   2. Protocol Overview......................................    2
   3. Operation of the Protocol..............................    3
   4. Network Considerations.................................    3
   5. Implementation Model...................................    4
   6. Constructing aRp Data Fields...........................    4
   7. Discussion.............................................    4
   8. Prototype Experience...................................    5
   9. References.............................................    5
   10. Acknowledgements......................................    6
   11. Authors' Addresses....................................    6
   12. Whitespace............................................    7

1.  Introduction

   This document describes the Address Revolution Protocol (aRp)
   and its operation over the Internet. 

Crowcroft                                                       [Page 1]
 
RFC ????                              aRp                     June 1990

1.1  Motivation

   The motivation behind the implementation of an aRp 
   implementation is fourfold:


      1.  The Internet is running out of address space.

      2.  Network Management staff at campus and regionals
          networks would revolt if they have to reassign all
          host addresses.

      3.  THe backbone management would revolt if all routers
          had to change addresses.

      4.  Very few people have connections off site at anyone time
          compared with onsite [CrowINET91, USC-SIGCOMM91, PaxBER91]

   The need for address re-use is clear. 

2. Protocol Overview

Once the Internet Address Space has become exhausted, the line of
least resistance is to start allocating addresses from the beginning
again. The question then arises:

How may a host on net A talk to a host on net A, when it is a
different net A?

The answer is to reuse an address on the network next to net A that is
different (e.g. Net B), and not currently in use to leave net B.

The aRp protocol is used to query the hosts on net B as to who has a
net B address not currently in use for non-net-B access. (If there is
no net B host, this procedure can be recursed from net B to net C, or
else iterated by a designated Net B aRp server reporting to the Net A
host which net C might be queried fruitfully [In CCITT terminology,
recursion and iteration are known as "chaining and referral"
respectively].

Now, like ARP, aRp uses caching. Unlike ARP, all aRp messages are
broadcast.

aRp messages are either requests or responses. When a host on net A
needs a non-net A address to communicate, it sends a broadcast aRp
request. Routers attached to net A, and net C forward this broadcast.

Any host that is participating in aRp on net C, and is not currently
part of a conversation off net C may send an aRp response, with their
C address. This is sent as a directed broadcast to net  (via the
appropriate router).

Hosts on net A now cache all the net C addresses they glean from
these responses.

Cache timeouts should be sufficiently long to bound the number of
broadcasts, but sufficiently short to allow the borrowed host
addresses to revert to their real owner if they need to re-enter the
Internet. A cache invalidation scheme is for future study.

Crowcroft                                                       [Page 2]
 
RFC ????                              aRp                     June 1990

3. Operation of the Protocol

The aRp packet is a similar format to the ARP packet (see  section 6),
but is encapsulated in an IP packet. For example, on an ethernet, a
request packet would look like this:

ar$hrd) = ares_hrd$Ethernet
(ar$pro) = ET(IP)
(ar$hln) = length(EA(X))
(ar$pln) = length(IPA(X))
(ar$op)  = ares_op$REQUEST
(ar$sha) = EA(X)
(ar$spa) = IPA(X)
(ar$tha) = don't care
(ar$tpa) = IPA(Y)

The inclusion of the hardware addresses makes possible the complete
obfuscation of bridging and routing functionality in so called
brouters.

4.  Network Considerations

Broadcasts are usually considered a BAD THING. But it is hard to find out 
an address when you dont know who to ask, and harder still, when you dont
know how to reach this unknown host.

Sufficiently ingenious caching should provide a large help - it is
certinasy the case that most networks are hierarchically ordered both
topologically, and in terms of the traffic patterns.

Crowcroft                                                       [Page 3]
 
RFC ????                              aRp                     June 1990

5.  Implementation Model

Routers may have to be changed to accommodate a hiatus of chaos just
after the introduction of aRp.

6.  Constructing aRp Data Fields

These are filled in very much as in ARP.


7.  Discussion

Basically, the idea is that there is a pool of globally unique
addresses already allocated. All new addresses are duplicates. Hosts
wishing to communicate on the Internet in the "new" address space
borrow from the old one.

Although this is not an entirely serious article (:-), there may be
something in this. A not dissimilar system was in use in the Universe
project for interconnecting Cambridge Rings, where bridges performed
a port mapping function.

One possible implementation choice must be made for hosts on net C
that have todecide when to reploy to an aRp request. The name address
Revolution protocol suggests a mechanism itself: 

A round roster/robin mechanism could be made starting at the lowest
host address and moving up through the address space (modulo Hubble's
constant).

Crowcroft                                                       [Page 4]
 
RFC ????                              aRp                     June 1990



8.  Prototype Experience

This has been hard to gain, as we have yet to convince anyone of the
soundness of this scheme.


9.  References

RFC 826   Plummer, D.C.  Ethernet Address Resolution Protocol: Or converting
      network protocol addresses to 48.bit Ethernet address for transmission
      on Ethernet hardware.  1982 November; 10 p. (Format: TXT=22026 bytes)

INET91 Wakeman/Crowcroft, Some traffic analysis of UK-US data., INET
91 conference, June 1991

SIGCOMM 91, USC/BNSD paper on traffic

PAX91, Vern Paxson, "Traffic models of Widea area TCP/IP", available
anonymous ftp.

Cambridge Distributed Systems, Needham et al.




Crowcroft                                                       [Page 5]
 
RFC ????                              aRp                     June 1990


10.  Acknowledgements

       The Author would like to thank his parents for their valuable
       contribution.


11. Authors' Addresses

   Jon Crowcroft
   Subliminal Science Department
   University College London
   Gower Street
   London WC1E 6BT GB

   EMail:  jOn@CS.uCl.AC.UK





Crowcroft                                                       [Page 6]
 
RFC ????                              aRp                     June 1990





















































Crowcroft                                                      [Page 7]
 

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 91 15:29:22 GMT
From:      SSJACK%ECUVM1@NCSUVM.CC.NCSU.EDU
To:        comp.protocols.tcp-ip
Subject:   PRODIGY email

Can Internet email be sent to PRODIGY users?

======================================================================
Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
Systems Programmer                                 (919) 757 - 6401
East Carolina University                          Greenville, NC 27858
======================================================================

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 91 22:05:57 GMT
From:      ddl@husc6.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   Re: Source code request: DNS EGP BGP

In article <1991Jul9.145324.20247@unislc.uucp>, cas@unislc.uucp (Charles Stephens) writes:
| 	"Somewhere, there is an implementation of gated, a UNIX daemon
| 	that supports Interior and exterior gateway protocols, that
| 	supports both BGP and EGP.  It will be available from some U.S.
| 	university - hopefully you'll get a reply from someone."
| 
| 		(Thank you IAN HEAVENS.)

	Gated is available from devvax.tn.cornell.edu in pub/gated.
Unfortunately, the "Copyright" file indicates that a license (royalty-free)
to redistribute must be obtained by writing to Cornell and they don't seem
to respond to such requests...

				Dan Lanciani
				ddl@harvard.*

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      10 Jul 91 22:57:01 GMT
From:      brian@telebit.com (Brian Lloyd)
To:        comp.dcom.lans,comp.protocols.tcp-ip,biz.comp.telebit,biz.comp.telebit.netblazer
Subject:   NetBlazer mailing list

There is a new mailing list (netblazer-users@telebit.com) for people
interested in exchanging information about using using the Telebit
NetBlazer.  If you are interested please send a subscription request
to netblazer-users-request@telebit.com.

Telebit hosts, maintains, and monitors this mailing list but the
purpose is for users to exchange applications and configuration
information as well as hints and kinks.


-- 
Brian Lloyd, WB6RQN                              Telebit Corporation
Network Systems Architect                        1315 Chesapeake Terrace 
brian@telebit.com                                Sunnyvale, CA 94089-1100
voice (408) 745-3103                             FAX (408) 734-3333

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 91 00:43:25 GMT
From:      palmer@interlink.com (Howard Palmer)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   DECnet Phase IV over TCP/IP

Followup-To: comp.os.vms
Subject: DECnet IV applications over TCP
Newsgroups: comp.os.vms,comp.protocols.tcp-ip
Keywords: DECnet,TCP/IP,protocols

Along with its recent announcements about DECnet Phase V
(or "Advantage Networking"), DEC seems to be trying to
breathe new life into DECnet Phase IV by licensing it to
third parties.  At the same time DEC seems to be creeping
towards the use of TCP/IP as an intermediate step between
Phase IV and the OSI transport protocols of Phase V.
However, this seems to be a direction DEC is taking only
reluctantly.

I see no technical problem with running DECnet Phase IV
application protocols over TCP/IP, given some mechanism
on top of TCP to preserve the DECnet message boundaries
and to map DECnet interrupt messages into some kind of
TCP urgent data sequence.  However, I do wonder whether
the current IP address space would suffice if a large
percentage of DECnet nodes in the world were converted
to a TCP/IP-based transport.  Are there enough Class B
and C addresses to go around?

If the IP address space is not a problem, then why would
DEC not move more aggressively on TCP?  If DECnet
applications ran over TCP/IP, it seems to me that VMS
could provide DECnet IV, TCP, and OSI applications (via
ISODE) using a single transport protocol.  (Yes, I can
see short-sighted marketing arguments for loading VMS up
with as many protocols as the market will bear, but are
there any good engineering reasons not to encourage
TCP/IP as a single-protocol solution for VMS?)
-- 
Howard Palmer		Interlink Computer Sciences, (415) 657-9800
palmer@interlink.com	47370 Fremont Blvd,  Fremont, CA.  94538
	    "So many standards, so little time..."
Disclaimer: I speak for me - why would you think otherwise?

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 91 01:52:03 GMT
From:      daniel@world.std.com (Daniel Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: On the need to develop Internet user services

In <4405@pluto.dss.com> lowell@pluto.dss.com (Lowell Gilbert) writes:


>> [from earlier...]
> >You get the idea. Now you can jump in your Japanes
> >econobox and, without any knowledge of the wonderful advances
> >in metallurgy and automotive engineering, go buy a pint of
> >milk. The cars are infinitely more complex, but infinitely
> >easier to use (they also come in more colours... :-)
 
> >If we can't present the information distribution paradigm
> >in a relatively simple manner, maybe it's _NOT_ just that
> >we're so smart and they're so dumb.  Maybe our paradigm
> >isn't finished yet?  Just my own opinion, but the basic
 
> The basic argument here is quite correct, but I think this
> presentation trivializes the problem.  In particular, I have problems
> with the automotive analogy.  The analogy breaks down in the
> flexibility -- essentially unprecedented -- of a computer.  Even when
> ....If you want to
> limit a given computer to that simple a purpose (say, using e-mail)
> then you can make the analogy stick.  

	Right.  There seems to be a tendency on the part of some people
that computers should be as easy to use as toasters.  Maybe someday.  I
have a little story about this:

	At a West Coast Computer Faire about 4 years ago, Jef Raskin,
formerly of Apple, was going on and on about how he felt that computers
were so complex that you actually had to have User Groups where people
could band together to figure out their machines.  He pointed out that
there weren't any Maytag User Groups, or Blender User Groups, so, why
should there be ones for computers?

	He missed a big point, and I wished I had gone to the microphone
during the Q & A session in that conference to call him on it.  The
point is:  Computers are (often) used for cerebral activities.  When
was the last time you did your taxes with your washing machine?  Have
you ever sent mail with your electric can opener?

	Computers, and to be specific, email, can be simplified in many
ways from the present state of the art.  But, at some point, you have
to let up on the spoon-feeding of the user, and they have to take over and
learn a thing or two.  I believe strongly in user-friendly interfaces,
and have had something to do with IslandPaint, and wrote almost
everything to do with IslandInstall, but where does it all end?  (or
does it?)  Do you have an animated little character walk out on the screen
and push the mouse pointer to where you want it?

	Computers are used for cerebral tasks, and short of a brain/cpu
link, there's going to be some definite limits on what can be done to
make things easy or more palatable for some time to come.  There aren't
any electronic magic wands yet.  I would say (politely) to new users of
email and other applications, "hey, it's not the same as a car yet...yes,
there's been a lot of progress in the last 20-15-10-5 years, and there's
still a lot that needs to be done, but in the meantime, a little educational
effort on your part will pay back daily".  Learning email is not that
hard, if you can compare domain addressing to postal.  It's a lot easier
to route something than it was 10 years ago.  I do like the idea that someone
else mentioned in this discussion, of just saying "mail H.P. Lovecraft",
and having the Right Thing happen.  Sounds like something that could be done
right now with a perl script that prompts for an address when it encounters
something new.

	Perhaps some of the problem is the educational system (not enough
focus on problem solving skills), and American need for instant
gratification (why should I read a help screen, or a manual?).  It's
not heredity, it's environment :-)

				Daniel
-- 
daniel@island.com  .....Daniel Smith, Island Graphics, (415) 491 0765 x 250(w)
daniel@world.std.com ...4000 CivicCenterDrive SanRafael MarinCounty CA 94903
dansmith@well.sf.ca.us .I must write this, or Island will take away my coffee.
Could we continue with the petty bickering? I find it most intriguing-Data:TNG

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 91 02:17:59 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip,comp.dcom.lans,comp.terminals
Subject:   PPP terminal server?

If you are (or know of) a vendor of a terminal server that talks PPP
on its serial ports, please contact me.

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 91 07:47:49 GMT
From:      larry@saruman.it.lut.fi (Lauri Toropainen)
To:        comp.protocols.tcp-ip
Subject:   Re: OSPF Information

scoggin@delmarva.delmarva.COM (John Scoggin) writes:

>Several people have asked me where to find the papers written about the
>OSPF interoperability testing that was recently conducted, but I couldn't
>remember the source.
 
>The papers are Internet Drafts available from DDN NIC.  The filenames are:
 
>	"Experience with the OSPF Protocol" by John Moy
>	draft-ietf-ospf-experience-00.txt or -00.ps
 
>	"OSPF Protocol Analysis" by John Moy
>	draft-ietf-ospf-analysis-00.txt or -00.ps

Can you tell me what's the directory?

Another silly question: how to change directory during a ftp session at
NIC.DDN.MIL? The CD command only results to an error message. DDN NIC
seems to be a VMS host, so this may be the reason.

Lauri

Signature?  What signature?  Let me read the small print first!

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 91 14:17:48 GMT
From:      jch@mitchell.cit.cornell.edu (Jeffrey C Honig)
To:        comp.protocols.tcp-ip
Subject:   Gated  was: Source code request: DNS EGP BGP

In article <7215@husc6.harvard.edu>, ddl@husc6.harvard.edu (Dan Lanciani) writes:
> 	Gated is available from devvax.tn.cornell.edu in pub/gated.

The proper host to retrieve gated from is gated.cornell.edu not
devvax.tn.cornell.edu.  Devvax is retiring this month.

> Unfortunately, the "Copyright" file indicates that a license (royalty-free)
> to redistribute must be obtained by writing to Cornell and they don't seem
> to respond to such requests...

The gated project switched departments this year and written requests
may have gotten lost in the shuffle.  It would be best to submit your
requests via e-mail to gated@gated.cornell.edu, or in writing to:

	Gated Project
	Information Technologies/Network Resources
	143 Caldwell Hall
	Cornell University
	Ithaca, NY  14853-2602

Least prefered is via phone to me at +1 607.255.6460.

Jeff

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 91 15:11:17 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: OSPF Information

In article <1991Jul11.074749.22990@lut.fi>, larry@saruman.it.lut.fi (Lauri Toropainen) writes:
> scoggin@delmarva.delmarva.COM (John Scoggin) writes:
 
> Can you tell me what's the directory?

internet-drafts: (The colon is required!)
 
> Another silly question: how to change directory during a ftp session at
> NIC.DDN.MIL? The CD command only results to an error message. DDN NIC
> seems to be a VMS host, so this may be the reason.

cd works fine, but you do get that odd message. Just ignore it. It's an
artifact of the anonymous implementation on that system. And it's NOT a VMS
system. Much older than that, it's a TOPS system. (Remember 36 bit systems?
Guess I'm showing my age.)

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.

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 91 15:45:19 GMT
From:      jim@crom2.uucp (James P. H. Fuller)
To:        comp.protocols.tcp-ip,comp.windows.x,comp.unix.sysv386
Subject:   alternative TCP/IP useable with X386?


  
     Lucky people who get TCP/IP free along with the rest of the system.
I'm running Interactive SysV (ISC 2.2) and TCP/IP is an expensive optional
extra.  But the docs for Thomas Roell's X386 say it has to run over TCP/IP.

     Is there an alternative to buying TCP/IP from Interactive?  Would 
something like ka9q compiled under Unix do the job?  With all the free
TCP/IP implementations for DOS there are in the world, has anybody written
one for SysV Unix?  If there is one, I'd greatly appreciate a pointer to
where it could be obtained.
                                           Thanks very much,
 
 
crom2 Athens GA Public Access Unix   |  i486 AT, 16mb RAM, 600mb online
   Molecular Biology                 |  AT&T Unix System V release 3.2
   Population Biology                |  Tbit PEP 19200bps  V.32  V.42/V.42bis
   Ecological Modeling               |    admin: James P. H. Fuller
   Bionet/Usenet/cnews/nn            |    {jim,root}%crom2@nstar.rn.com

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 91 16:42:05 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: OSPF Information

In article <1991Jul11.074749.22990@lut.fi> larry@saruman.it.lut.fi (Lauri Toropainen) writes:
>>The papers are Internet Drafts available from DDN NIC.  The filenames are:
 
>>	"Experience with the OSPF Protocol" by John Moy
>>	draft-ietf-ospf-experience-00.txt or -00.ps
 
>>	"OSPF Protocol Analysis" by John Moy
>>	draft-ietf-ospf-analysis-00.txt or -00.ps

It should be noted that these papers were written to satisfy the standards
advancement process and predate the most recent testing.

>Can you tell me what's the directory?

internet-drafts
(these are also available at nnsc.nsf.net)

>Another silly question: how to change directory during a ftp session at
>NIC.DDN.MIL? The CD command only results to an error message. DDN NIC
>seems to be a VMS host, so this may be the reason.

cd internet-drafts:<cr>

I believe that the NIC is still a DECSYSTEM-10 (or -20).

>Lauri

Art

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 91 17:31:33 GMT
From:      donp@na.excelan.com (don provan)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Re: DECnet Phase IV over TCP/IP

In article <18248@ntrlink.interlink.com> palmer@interlink.com (Howard Palmer) writes:
>I see no technical problem with running DECnet Phase IV
>application protocols over TCP/IP...
>...
>If the IP address space is not a problem, then why would
>DEC not move more aggressively on TCP?

There's a great deal more to putting a product in the field than the
solution being "no technical problem".  It's taken Digital over five
years to line up themselves, their products, and their customers for
the OSI migration.  Do you expect them to start now on another five
year campaign to switch to TCP/IP instead?
						don provan
						donp@novell.com

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 91 18:06:16 GMT
From:      bill@banana.fedex.com (bill daniels)
To:        comp.protocols.tcp-ip,comp.unix.ultrix
Subject:   DEC Athena Net Manager Product??

Has anyone heard or tried or bought the DEC Athena Lan Manager software
for their Ultrix environment?  I only recently heard of its existence
and was wondering if anyone has any more info.

bill daniels
-- 
these ravings are in no way sanctioned by federal express corp
bill daniels			| voice:  (901)797-6328
federal express corp		| fax:    (901)797-6388
box 727-2891, memphis, tn 38194 | email:  bill@banana.fedex.com

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 91 19:19:40 GMT
From:      rbp@sutro.SFSU.EDU (Robert B. Pasker)
To:        comp.protocols.tcp-ip,comp.dcom.modems
Subject:   SLIP modem recommendations

I'm about to install a 9600 baud SLIP connection between a SUN/3 and
PSI.  Does anyone have a recommendation for a high-speed modem which
will work well in this application and be useful in the future if we
decide to upgrade to a faster link. 

comments, suggestions, and flames welcome.


-- 
- bob pasker
  halfdome!bob@cs.sfsu.edu | rbp@sutro.sfsu.edu | rbp@well.sf.ca.us

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 91 20:36:00 GMT
From:      debby@ora.ora.com (Deborah Russell)
To:        comp.protocols.tcp-ip
Subject:   Security Books



In response to:

From NIC.DDN.MIL!NIC Fri Jun 28 11:07:04 1991
Return-Path: <NIC@NIC.DDN.MIL>
Received: by ora.ora.com (/\=-/\ Smail3.1.18.1 #18.76)
	id <m0jtKPW-00000NC@ora.ora.com>; Fri, 28 Jun 91 11:07 EDT
Date: Fri, 28 Jun 91 08:09:36 PDT
From: DDN Reference <NIC@NIC.DDN.MIL>
Subject: Re: Computer Security Books
To: debby@ora.ora.com
cc: NIC@NIC.DDN.MIL
In-Reply-To: <m0jsxWi-00008bC@ora.ora.com>
Message-ID: <12697110229.25.NIC@NIC.DDN.MIL>
Status: ORp

This topic is of continuing concern in the internet environment.
It would be appropriate to send your message to the TCP-IP
mailing list here at the NIC host. You can send an email
message to TCP-IP@NIC.DDN.MIL to reach the list.

Steven
...for the DDN NIC

_________________________________________________________________

Steven, I hope the following posting is acceptable.  Thank you for your help.

Debby Russell
_________________________________________________________________

COMPUTER SECURITY BOOKS

Two computer security books are now available from O'Reilly &
Associates, publishers of the X Window System series and the UNIX
Nutshell Handbook series:

Computer Security Basics
by Deborah Russell and G.T. Gangemi Sr.
464 pages, $29.95

Audience:  Users and managers who need to become security-literate.

This book provides an easy-to-understand introduction to the many
topics encompassed by the term "computer security"--passwords, access
controls, cryptography, trusted operating systems, network security, 
biometric devices, smart cards, and TEMPEST shielding.  It provides 
detailed information on the Orange Book, the government's standard 
for the development of trusted systems.  It also contains 
quick-reference material, including a security glossary and a summary 
of government programs, contacts, and legislation.

Practical UNIX Security
by Simson Garfinkel and Gene Spafford
512 pages, $29.95

Audience:  UNIX users and system administrators.

This book spells out the many security options for systems running
either System V or Berkeley UNIX.  It tells how to keep intruders out,
how to tell if they've gotten in, how to clean up after them, and even
how to prosecute them. It provides numerous scripts, detailed
information on defending against network and communications breaches 
using modems, NFS, Secure NFS, Kerberos, and firewall machines,
and a list of other security sources (books, organizations, etc.).


To order these books or to discuss corporate discounts, contact
O'Reilly & Associates at 632 Petaluma Avenue, Sebastopol, CA, 95472.
In the US and Canada, call 1-800-338-6887.  
Overseas or California, call 707-829-0515.  
To send a FAX, call 707-829-0104."

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 91 21:51:47 GMT
From:      lstowell@pyrnova.pyramid.com (Lon Stowell)
To:        comp.protocols.tcp-ip
Subject:   Re: PRODIGY email


In article <9107111414.AA03558@ucbvax.berkeley.edu> SSJACK%ECUVM1@NCSUVM.CC.NCSU.EDU writes:
>Can Internet email be sent to PRODIGY users?
   
   Possibly, but if it has two-syllable words in it, they won't
   be able to understand it.... >:-)

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 91 22:28:00 GMT
From:      DFOO@VAXC.STEVENS-TECH.EDU
To:        comp.protocols.tcp-ip
Subject:   Modify telnetd8(c)


Hi there,

Does anyone knows how to modify SUN/3 TELENT ot TELNETD time out flag from 
default  set up to  30 seconds.
I will appreciate the help if someone can reponse my E-mail.


David Foo
Computer Center
Stevens Institute of Technology
(O)201-420-5736

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      11 Jul 91 22:55:31 GMT
From:      schoff@uu.psi.com (Martin Schoffstall)
To:        comp.protocols.tcp-ip
Subject:   Re: snmp for Macs


The WatchTower from Intercon Systems in Herndon, VA

info@intercon.com

Marty
------------

In article <1976@vtserf.cc.vt.edu> jcrowder@groupw.cns.vt.edu (Jeff Crowder) writes:
>
>Can anyone recommend an SNMP monitor for an Apple environment?  We have
>a user who wants to manage his soon-to-be-installed 10BaseT network
>using one of his existing Macs.  Public domain would be preferable but
>any pointers would be appreciated (marketing reps welcome).    
>
>Thanks,		
>
>Jeff Crowder
>jcrowder@GroupW.cns.vt.edu

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 91 00:47:37 GMT
From:      rogue@eris.berkeley.edu (Brett Glass)
To:        comp.sys.mac.misc,comp.protocols.iso,comp.protocols.tcp-ip,comp.protocols.nfs,comp.protocols.appletalk
Subject:   Non-Proprietary Protocols for Macintosh

I'm interested in compiling a list of vendors who offer products that let
a Mac use non-proprietary networking protocols, such as TCP/IP (also NFS,
Telnet, FTP, and others in the Internet suite) and OSI (including FTAM,
VTAM, and the equivalents in the ISO world). Both hardware and software
products would be useful.... Also, I *am* interested in products that
merely allow AppleTalk to "tunnel" through a TCP/IP or OSI network.

Any pointers to vendors or sources of information would be MUCH appreciated.
Please respond to this mailbox....

--Brett Glass

-- 
"Beware when the great God lets loose a thinker on this planet.
 Then all things are at risk. It is as when a conflagration has
 broken out in a great city, and no man knows what is safe, or
 where it will end."                   -- Ralph Waldo Emerson

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 91 00:52:00 GMT
From:      CSYSMAS@MVS.OAC.UCLA.EDU (Michael Stein)
To:        comp.protocols.tcp-ip
Subject:   Re: On the need to develop Internet user services


The following is an extract/abstract of an E-mail conversation,
the names/addresses have been changed...)

Does any of this make sense?

#  An intelligent person would do the "obvious" and send themself a
#  message.
#  Why doesn't this work on most systems (for obtaining ones own
#  E-mail address)?

$  This only gives you your address as seen from a local machine.
$  What address people on the other side of the world should use
$  is anybody's guess.

#  Ah, but the whole point of the Internet domain name system is
#  that the name of a place doesn't depend on where you are only
#  where it (the target) is.  Thus the name I see at my site
#  *should* be my Internet name (the whole thing...)

$  No, one of the important reasons for domains is that they a
$  hierachical.  My address from here is just xyz. From upstairs
$  (another department) it is xyz@abcd. From some other university
$  it is xyz@abcd.gh and so on.

#  How else do you find out your own E-mail address?

$  Ask a guru, same way you find out anything else.

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 91 00:52:48 GMT
From:      schoff@PSI.COM ("Martin Lee Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: On paying for the Internet (was: Re: On the need to develop . . . )



Alex,

I think your missing some critical principals

(a) once a service becomes part of accepted business practice they will
accept variable prices.  Introduce something new and it is a MUCH harder
initial sell to get people to accept variable over fixed.  There are only
a few examples of really new services that were successfully introduced,
the one that comes to mind is "xeroxgraphy" in the 50's.  How much faster
would it have penetrated if you could have walked in and simply bought the
"duplicator".

It might be interesting to note that Xerox very effectively marketed/seduced
this "pay as you go" methodology to the point where they were an effective
monopoly that took a Court Decision to breakup.

That might be an interesting data point to keep in mind in the current Internet
and NREN environment.  Does something look so attractive in its short term
affect that the long term is something approaching a worse case scenario.

(b) Just because people will pay for certain services on a variable basis
doesn't mean that they want to, that it is a good thing, or that we can't
do better.

(c) For the retail providers like PSI/Alternet/Nearnet/Cerfnet etc our costs
are in a very effective manner fixed, and in some realatively easy manner
budgetable.  So why not pass that model on to the customers, and amortize
the costs over the installed base with periodic corrections to either
lower cost, add functionality, improve service quality, or expand in some
manner
 

I see an enormous "sell" going on at various levels in the US government,
various oversight and policy makeing organizations, the IETF, etc, to
do accounting, variable pricing, etc...  The sell is very smooth, it is
done by very powerful people and organizations, and in some cases it
is even devoutly believed in (vs cynically desired with the hope of
making ever increasing $'s as the addiction grows).

Fundamentally, I believe that there is zero market support for it, and that
if applied will result in a serious revolt.

I apologize for my generalizations in advance, but this needs many kilobytes
of ascii to really develop.  I am not even touching the issue of impact of
the market, utility, technology improvements, r&d, etc which would ALL be
affected negatively by variable pricing.

Marty
---------
 
 1) Several people have observed that its easy for organizations to
 budget for fixed costs, but virtually impossible for them to budget for
 variable costs.  I disagree.  Almost every organization I know of,
 universities, non-profits, and commercial, budgets at some level for use
 of telephone services, use of postal services, use of package services,
  ...  All of these are variable cost services based on usage.  Of course
 the more users who are grouped together in the budget, the more the
 costs take on the appearance (via statistical properties) of being fixed
 costs.  I don't see any intrinsic reason why budgeting for information
 services should be different.  In fact, I'll bet that most organizations
 already budget for access to some kinds of information services (e.g.,
 the company library has access to some information providers, the
 marketing department gets D&B financial reports on current or
 prospective customers).
 
 2) I have heard (I can't vouch for the accuracy of the story) that when
 the Boston-area rapid transit system was considering a fare increase
 several years ago, a study was commissioned to determine the "optimal"
 fare (in terms of minimizing transit system's annual loss).  The alleged
 conclusion of the study was that the cost to the taxpayers would be
 minimized if the fare-collectors were fired and the fare was free (this
 analysis may have included savings in road maintenace due to reduced
 highway traffic; I don't know).  But, goes the story, this approach was
 rejected by the decision makers, who felt that the taxpayers would rebel
 against the idea of giving free transportation to people who could
 afford to pay something for it.  Is this relevant to government
 decisions about allowing commercial use of the Internet?  To support for
 information providers?  To the NREN issue? 
 
 Alex McKenzie
  

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 91 01:23:24 GMT
From:      hubert@CAC.WASHINGTON.EDU (Steve Hubert)
To:        comp.protocols.tcp-ip
Subject:   simple network debugging writeups?

Does anyone have an IP debugging guide that they would be willing to share?  I
am thinking of something that would be a helpful guide when trying to isolate
the cause of a problem, something like:

    Try ping to a host on the same subnet, if that works try pinging the
router, if that works, try telnet to a numeric IP address, etc.

Thanks,
Steve Hubert
Networks and Distributed Computing, Univ. of Washington, Seattle
hubert@cac.washington.edu

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 91 02:22:00 GMT
From:      randall@Virginia.EDU (Ran Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: snmp

Let me just mention that the newsgroup  comp.protocols.snmp  was just
created as an "inet" newsgroup.   Now that it has been created, postings
about SNMP are best sent there.   The contents of the SNMP Mailing List
appear there as well (for now a one-way gate) so there should be some
useful material there.  

Thanks go to Erik Fair for supporting the newsgroup's creation and to
the good folks at PSI.COM for actually getting the gateway and newsgroup
setup and running.

If your site doesn't carry comp.protocols.snmp, ask your news administrator.

Ran
randall@Virginia.EDU

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 91 04:32:56 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Addressing Assignments

In article <21188095@macs.UUCP> mdg@macs.UUCP (Mark Griffith) writes:
   I realize that registering our addresses and getting these people
   involved is not necessary as long as we are not connected to a
   wider net than our own physical plant.  

You will be connected someday, probably sooner than you now think.
And it's a very good thing that you plan to begin using your own chunk
of the address space right now, because it will save you agony and
heartache down the road.  Perhaps not too far down the road.  Probably
a lot of agony.  Write to hostmaster@nic.ddn.mil to start the process.

   However, as I mentioned above, we would like to do this for local
   "political" reasons.

(How to say this delicately?)  If your understanding of the issues
focuses on the politics, then perhaps you need to study those issues
some more, and listen more closely to those whose positions you now
see as in only political opposition to yours.

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 91 08:11:03 GMT
From:      mottram@viper.uk.tele.nokia.fi (Peter Mottram)
To:        comp.protocols.tcp-ip
Subject:   Re: PRODIGY email

In article <9107111414.AA03558@ucbvax.berkeley.edu> SSJACK%ECUVM1@NCSUVM.CC.NCSU.EDU writes:

>   Can Internet email be sent to PRODIGY users?


In one word, NO.


>   ======================================================================
>   Jack E. McCoy                                     SSJACK@ECUVM1.BITNET
>   Systems Programmer                                 (919) 757 - 6401
>   East Carolina University                          Greenville, NC 27858
>   ======================================================================


If you're interested, there has been a thread going on in alt.bbs.internet
about this for quite some time.

Peter

---------------------------------------------------------------------
Peter Mottram				mottram@ntl02.decnet.nokia.fi
---------------------------------------------------------------------

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 91 14:57:15 GMT
From:      fab@MD.INTERLINK.COM (Fred Bohle)
To:        comp.protocols.tcp-ip
Subject:   Re:  ftp file type extenstion

What about using the SITE command? Isn't this precisely what it is for?
An extension to the file system not represented in UNIX (like MVS)
is supported via the SITE command to supply filesystem information.
SNS/TCPaccess uses the SITE command to specify all kinds of MVS-specific
filesystem information.  If you are implementing some new filesystem
options, pass them via the SITE command.

My 2 bits.
Fred
------------------------------------------------------------------------
Fred Bohle			EMAIL: fab@leo.md.interlink.com
Interlink Computer Sciences	AT&T : 301-317-6600 
9145 Guilford Road, Suite 175
Columbia, MD 21046
------------------------------------------------------------------------

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 91 17:34:23 GMT
From:      peterd@cs.mcgill.ca (Peter Deutsch)
To:        comp.protocols.tcp-ip
Subject:   Re: On the need to develop Internet user services


In article <1991Jul11.015203.21425@world.std.com> daniel@world.std.com (Daniel Smith) writes:
>In <4405@pluto.dss.com> lowell@pluto.dss.com (Lowell Gilbert) writes:
>
>
>>> [from earlier...]
>> >You get the idea. Now you can jump in your Japanes
>> >econobox and, without any knowledge of the wonderful advances
>> >in metallurgy and automotive engineering, go buy a pint of
>> >milk. The cars are infinitely more complex, but infinitely
>> >easier to use (they also come in more colours... :-)
 
>> >If we can't present the information distribution paradigm
>> >in a relatively simple manner, maybe it's _NOT_ just that
>> >we're so smart and they're so dumb.  Maybe our paradigm
>> >isn't finished yet?  Just my own opinion, but the basic
 
>> The basic argument here is quite correct, but I think this
>> presentation trivializes the problem.  In particular, I have problems
>> with the automotive analogy.  The analogy breaks down in the
>> flexibility -- essentially unprecedented -- of a computer.  Even when
>> ....If you want to
>> limit a given computer to that simple a purpose (say, using e-mail)
>> then you can make the analogy stick.  
>
>	Right.  There seems to be a tendency on the part of some people
>that computers should be as easy to use as toasters.  Maybe someday.  I
>have a little story about this:
>
>	At a West Coast Computer Faire about 4 years ago, Jef Raskin,
>formerly of Apple, was going on and on about how he felt that computers
>were so complex that you actually had to have User Groups where people
>could band together to figure out their machines.  He pointed out that
>there weren't any Maytag User Groups, or Blender User Groups, so, why
>should there be ones for computers?
>
>	He missed a big point, and I wished I had gone to the microphone
>during the Q & A session in that conference to call him on it.  The
>point is:  Computers are (often) used for cerebral activities.  When
>was the last time you did your taxes with your washing machine?  Have
>you ever sent mail with your electric can opener?
>
>	Computers, and to be specific, email, can be simplified in many
>ways from the present state of the art.  But, at some point, you have
>to let up on the spoon-feeding of the user, and they have to take over and
>learn a thing or two.  I believe strongly in user-friendly interfaces,
>and have had something to do with IslandPaint, and wrote almost
>everything to do with IslandInstall, but where does it all end?  (or
>does it?)  Do you have an animated little character walk out on the screen
>and push the mouse pointer to where you want it?
>
>	Computers are used for cerebral tasks, and short of a brain/cpu
>link, there's going to be some definite limits on what can be done to
>make things easy or more palatable for some time to come.  There aren't
>any electronic magic wands yet.  I would say (politely) to new users of
>email and other applications, "hey, it's not the same as a car yet...yes,
>there's been a lot of progress in the last 20-15-10-5 years, and there's
>still a lot that needs to be done, but in the meantime, a little educational
>effort on your part will pay back daily".  Learning email is not that
>hard, if you can compare domain addressing to postal.  It's a lot easier
>to route something than it was 10 years ago.  I do like the idea that someone
>else mentioned in this discussion, of just saying "mail H.P. Lovecraft",
>and having the Right Thing happen.  Sounds like something that could be done
>right now with a perl script that prompts for an address when it encounters
>something new.
>
>	Perhaps some of the problem is the educational system (not enough
>focus on problem solving skills), and American need for instant
>gratification (why should I read a help screen, or a manual?).  It's
>not heredity, it's environment :-)
>
>				Daniel
>-- 
>daniel@island.com  .....Daniel Smith, Island Graphics, (415) 491 0765 x 250(w)
>daniel@world.std.com ...4000 CivicCenterDrive SanRafael MarinCounty CA 94903
>dansmith@well.sf.ca.us .I must write this, or Island will take away my coffee.
>Could we continue with the petty bickering? I find it most intriguing-Data:TNG

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 91 18:37:41 GMT
From:      eli@bart.UUCP (Eli Blumenthal)
To:        comp.protocols.tcp-ip
Subject:   RE: OSPF Information



uunet!mcsun!news.funet.fi!kannel!saruman.it.lut.fi!larry  (Lauri
Toropainen) writes:

> Another silly question: how to change directory during a ftp session at
> NIC.DDN.MIL? The CD command only results to an error message. DDN NIC
> seems to be a VMS host, so this may be the reason.

Directories in VMS are specified as follows:

 	disk:[dir1.dir2.dir3]filename.ext

In VMS, the command

	set default <file-path>

is used to change directories.  The command 

	show default/directory

should tell you what directory you are currently in, and the command 

	set default [..]

will move you up one directory.  If you are changing directories on
the same disk that you're currently on, the "disk:" may be omitted.

All this assumes that VMS-type commands can be executed while in FTP.
If that's true, the above should work.  If not, FTP may still use the
"cd" command to change directories, but it needs a VMS-style file-name
to do its thing.  

Hope this helps!!

Eli Blumenthal
Penril DataComm Networks	(301) 921-8600 x8869 (Voice)
1300 Quince Orchard Boulevard	(301) 921-8376 (FAX)
Gaithersburg, Maryland  20878	uunet!penril!eli

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 91 19:12:18 GMT
From:      JIM@UCF1VM.BITNET (Jim Ennis)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   David Systems Ether-T MC Adapter



Hello,
        Please forward info about where one might find a packet
driver for the David Systems Ether-T MC Adapter so we can
utilize the CUTCP software pkg with that card.
        Any help with this would greatly be appreciated and I
would like to thank YOU in advance.

Jim Ennis
University of Central Florida
JIM@UCF1VM.CC.UCF.EDU

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 91 19:20:17 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   simple network debugging writeups?


   Date: Thu, 11 Jul 1991 18:23:24 -0700 (PDT)
   From: Steve Hubert <hubert@cac.washington.edu>

   Does anyone have an IP debugging guide ...

There is a good description of the process in RFC1147 (the NOC Tools
Catalogue), which also appears in Connexions.  Of course, as one of
the authors, my view isn't completely unbiased.

            __
  /|  /|  /|  \         Michael A. Patton, Network Manager
 / | / | /_|__/         Laboratory for Computer Science
/  |/  |/  |atton       Massachusetts Institute of Technology

Disclaimer: The opinions expressed above are a figment of the phosphor
on your screen and do not represent the views of MIT, LCS, or MAP. :-)

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 91 19:59:41 GMT
From:      werme@Alliant.COM (Ric Werme)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Throughput over E-net


In article <1991Jul5.153302.17217@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <3313@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes:
>>I'm sorry, but my mind just boggles when I see some of the transfer stats
>>that people post for host-host file transfers.  EVen using some acknowledged
>>fast machines, I cannot approach those posted numbers (and this includes
>>systems from Sun, H-P, etc.)
>>
>>I refer to the "ftp" transfer stats; is there some OTHER method to measure
>>"disk -> net -> disk" transfer speed?
>
>You don't want to use FTP for benchmarking; it is a fairly complex protocol,
>especially if you're transferring text (which is *not* transferred by just
>copying the bytes to the network), and it's not terribly well implemented
>in 4BSD.

It's not *that* awful:

ftp> recv /unix /dev/null
200 PORT command successful.
150 Opening data connection for /unix (binary mode) (1359872 bytes).
226 Transfer complete.
local: /dev/null remote: /unix
1359872 bytes received in 1.9 seconds (720 Kbytes/s)

This was after a first copy that loaded /unix into the buffer cache.  I've
seen better throughput, but there are other people using the Ethernet too.

(This was between two Alliant FX/2800s.)


-- 

| A pride of lions              | Eric J Werme                   |
| A gaggle of geese             | uucp: mit-eddie!alliant!werme  |
| An odd lot of programmers     | Phone: 508-486-1214            |

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 91 20:25:27 GMT
From:      vivian@NISC.SRI.COM (Vivian Neou)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP list change


The TCP-IP list has been moved from NIC.DDN.MIL to NISC.SRI.COM.  This
change should provide better delivery and response times.  The new
addresses are listed below, although the old ones will continue to
work.

 tcp-ip@NISC.SRI.COM           The mailing list for submissions.
 tcp-ip-request@NISC.SRI.COM   The list maintainer (add/delete requests)

If you notice any problems with the new mail system, send a message to
the tcp-ip-request address.

Vivian Neou

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 91 20:28:09 GMT
From:      eddjp@edi386.UUCP ( Dewey Paciaffi )
To:        comp.protocols.tcp-ip
Subject:   NIS and Sendmail

I have recently set up NIS on my network. Every thing works as expected
except for the mail aliases. Sendmail responds to locally set aliases,
but not those handled by NIS. 'ypcat aliases' shows the aliases.

My NIS master is an IBM box running AIX 3.1.5, and the clients are 
Suns running SUN/OS 4.1.1. 

Is there something I have to tweek in sendmail to get this to work?

-- 
Dewey Paciaffi           ...!uunet!edi386!eddjp

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      12 Jul 91 23:33:52 GMT
From:      yeh@NETIX.COM (Shannon Yeh)
To:        comp.protocols.tcp-ip
Subject:   follow up [Re: unsolicited unclassified FYI]



Since we did drive faster than 55mph, I apologize for our people's speeding.  
However, we obviously did not drive too fast, therefore, "economic sanction" 
("don't buy") is not acceptable.

If I receive unusual messages, I would contact the sender's postmaster
or system administrator first, then, contact other police stations if the
sender's postmaster/administrator is not cooperative.  Particularly, please
be noted that our YFI message was addressed in "point-to-point" mode; in
contrast, the attached message was addressed in "multicasting" mode.

If you like to continue to make comments on this specific issue, please 
direct them to me instead of addressing to thousands of people.  If there
are inertesting discussions/points coming out, I will summerize a digest and 
forward it to this working group.  Thanks for the cooperation.

Sincerely,
Shannon Tao Yeh
Postmaster


   From tcp-ip-RELAY@NIC.DDN.MIL Fri Jul  5 05:57:24 1991
   From: scoggin@delmarva.delmarva.COM (John Scoggin)
   To: tcp-ip@nic.ddn.mil, torben@foralie.ics.hawaii.edu
   Date: Fri, 5 Jul 91 7:26:58 EDT
   
   Subject: Re: Unsolicited advertisement.....
   To: torben@foralie.ics.hawaii.edu (Torben Nielsen)
   Date: Fri, 5 Jul 91 7:26:58 EDT
   From: John Scoggin <scoggin@delmarva.delmarva.com>
   Cc: tcp-ip@nic.ddn.mil
   In-Reply-To: <91Jul4.144425hst.50@foralie.ics.Hawaii.Edu>; from "Torben Nielsen" at Jul 4, 91 2:44 pm
   X-Mailer: ELM [version 2.3 PL11]
   
   > 
   > I just received this long and totally unsolicited advertisement from a company
   > called Netix. It's an ad for a new piece of PC software.
   > 
   > Now, I have no idea where they got my name and mail address from (not that
   > it's difficult to do that...). Not that it really matters. What I'd really like
   > to know is if a) this is legitimate use of the network (I believe it isn't
   > since it's an unsolicited advertisement for a commercial product) and b) how
   > many others out there received the same thing.
   > 
   > Assuming it's indeed inappropriate use, what's the currently accepted way of
   > dealing with such things?
   > 
   > 						Cheers, Torben
   
   I've had the same experience, but with another vendor.  I think that
   vendors have a valuable role to play on the net.  For example, IBM has been
   very active in solving problems on the BITNET IBMTCP-L - more helpful than
   their own support centers, because you are dealing with the developers.
   
   I recently posted a requirement to the TCP-IP group which several vendors
   answered with brief lists of applicable products, which were followed up with
   phone calls.
   
   Unsolicited advertising is another thing altogether.  There is probably
   not much you can do about the posting, the way the nets are tied together.
   But you certainly have the same right as any consumer - don't buy their
   product and tell them why!  It's been my experience that hitting them in the
   wallet is very effective.  They can shrug off our network flames, but they
   can't ignore their profit/loss statement.
   
   ----------------------------------------------------------------------
   John K. Scoggin, Jr.	
   Supervisor, Network Operations		Phone:  (302) 451-5200
   Delmarva Power & Light Company		Fax:	(302) 451-5321
   500 N. Wakefield Drive			Email:	scoggin@delmarva.com
   Newark, DE  19714-6066	
   ----------------------------------------------------------------------
   

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 91 07:43:12 GMT
From:      erik@sra.co.jp (Erik M. van der Poel)
To:        comp.protocols.ibm,comp.protocols.iso,comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: SOS: C Routines for ASCII to EBCDIC Conversion and Vice-versa

Paul Smee writes:
> For a real real definitive answer, you'll have to get friendly with
> someone in IBM.  I know THEY are trying to come up with a definitive
> ASCII<->EBCDIC mapping as part of their SAA project; to dig themselves
> out of the hole caused by the fact that IBM/PCs speak ASCII, while IBM
> mainframes speak EBCDIC.

I believe this is correct. There is some work going on (maybe not only
within IBM) to define mappings between the various versions and
national variants of EBCDIC and the ASCII and ISO 646 based codesets
including Latin-1, etc.


Dave Andrews writes:
> I believe the IBM effort is leading toward Unicode, a double-byte set.   

It wouldn't be very wise for a large company like IBM to place all
their bets on Unicode, when a similar encoding (10646) is still being
developed. Also, IBM cannot simply ignore the existing data encoded in
old codesets.


> As I recall, a recent SHARE-wide survey indicated that SHARE members
> were not happy with the Unicode idea (which will STILL be unusable in
> parts of the world).

It is impossible to create an encoding that is both immediately usable
and sufficient in all parts of the world.


> I don't think the ASCII/EBCDIC dichotomy will ever be resolved.

That depends on what you mean by "resolved". If you mean converting
all data that is in one codeset to the other codeset so that we end up
with files in one codeset only, of course this will never happen.

But higher level protocols have been and will be defined that allow
interchange between ASCII and EBCDIC users, as they do today, e.g. 
email between the Internet and BITNET.
-
-- 
EvdP

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      13 Jul 91 11:49:27 GMT
From:      iversen@vsfys1.fi.uib.no (Per Steinar Iversen)
To:        comp.protocols.tcp-ip
Subject:   NDIS driver for Acer 5220A?

Does anybody know if there exists an NDIS driver for the Acer 5220A?
This is wanted for DEC Pathworks. There is a packet-driver for this 
card, but DEC uses NDIS drivers.

P.S.Iversen

+------------------------------------------------------------------------------+
! Per Steinar Iversen    ! Internet:     iversen@vsfys1.fi.uib.no              !
! Fysisk Institutt       ! BITnet:       iversen@cernvm.bitnet                 !
! Universitetet i Bergen ! HEPnet:       VSFYS::IVERSEN (VSFYS=21.341=21845)   !
! Allegaten 55           ! Phone:       +47 5 212770                           !
! N-5007 Bergen          ! Fax:         +47 5 318334                           !
! NORWAY                 !                                                     !
+------------------------------------------------------------------------------+
! X400 RFC address: iversen@physics.uib.no                                     !
! X400 OR  address: C=no;ADMD=" ";PRMD=uninett;O=uib;OU=physics;S=iversen      !
+------------------------------------------------------------------------------+

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 91 00:01:04 GMT
From:      neufeld@cs.ubc.ca (Gerald Neufeld)
To:        comp.mail.multi-media,comp.protocols.iso,comp.protocols.iso.dev-environ,comp.protocols.tcp-ip,news.announce.conferences
Subject:   CFP: IFIP Conf on Protocols/Arch/Appl


                         CALL FOR PAPERS

               1992  IFIP International Conference

                               on

      UPPER LAYER PROTOCOLS, ARCHITECTURES AND APPLICATIONS

                       May 20 to 22, 1992

                 University of British Columbia
                        Vancouver, Canada

                          Sponsored by:
                     IFIP Working Group 6.5

                           Hosted by:
        University of British Columbia, Vancouver, Canada
                               and
                 OSIWARE Inc., Vancouver, Canada

Conference outline

The purpose of the conference is to provide an international forum for
the exchange of information on the technical, economic, and social
impacts and experiences with upper layer protocols, architectures and
distributed applications. The conference format will be two and a half
days of conference paper presentations combined with one half a day of
workshops.

Papers are desired in - but not restricted to - the following topic
areas:

* Design, implementation, and experience with distributed applications
* Application layer user agent models and designs
* Application layer architectures
* Application layer programming environments
* Application communication protocols such as RPC, RO, RTS and multicast
* Group communication models and services
* Multimedia applications and communications
* Interconnection of upper layer and application entities
* Upper layer conformance and interoperability testing activities
* Security and privacy
* Management and operation of distributed services
* Mobile communications and the application layer protocols
* Upper layer network management and naming
* Presentation and session layer issues
* Abstract syntax notations and transfer syntaxes
* The impact of very high-speed networking on the upper layers protocols

Instructions to Authors

Prospective authors are invited to submit for review, unpublished
original contributions (not exceeding 5000 words) which describe recent
research results or developments on any design or service aspect of upper
layer protocols, architectures or distributed applications.

Publication

Papers that are accepted will be published by North-Holland. A preprint
of the proceedings will be provided to attendees.

Deadlines

Today: Send a message, letter or phone any of the contacts below stating
your intention to submit a paper, or stating your general interest in the
conference.

December 1, 1991: Full version of papers due for review.
March 1, 1992:    Notification of acceptance/rejection.
April 15, 1992:   Camera-ready papers required for publication.

Please submit five copies of your paper to:

Dr. Gerald Neufeld
Department of Computer Science
University of British Columbia
Vancouver, B.C, Canada, V6T 1W5

Telephone: +1 604 228 4806
Facsimile: +1 604 228 5485
Internet:  neufeld@cs.ubc.ca
X.400:     S=Neufeld; OU=CS; O=UBC; P=cdn; A=telecom.canada; C=ca

or to:

Prof. Dr. Bernhard Plattner
Laboratory of Computer Engineering and Networks
Swiss Federal Institute of Technology (ETH)
ETH-Zentrum CH-8092
Zurich, Switzerland

Telephone: +41 1 254 7000
Facsimile: +41 1 262 3973
Internet:  plattner@komsys.tik.ethz.ch
X.400:     S=Plattner; OU=komsys; OU=tik; O=ethz; P=switch; A=arcom; C=ch

Program Committee Co-Chairs

Gerald Neufeld (CA)     North American CoChair
Bernhard Plattner (CH)  European CoChair

Program Committee (provisional list)

Jun Adachi (JP)         <adachi@nacsis.ac.jp>
Raj Ananthanpillai (US) <raja@att.com>
Gregor Bochmann (CA)    <bochmann@iro.umontreal.ca>
David Chappell (US)     <chappell@sierra.cray.com>
Frank Ferrante (US)     <ferrante@mitre.org>
James M. Galvin (US)    <galvin@tis.com>
Ruediger Grimm (DE)     <grimm@darmstadt.gmd.dbp.de>
Christian Huitema (FR)  <huitema@mirsa.inria.fr>
Erik Huizer (NL)        <huizer@surfnet.nl>
Neil Koorland (CA)      <koorland@vancouver.osiware.bc.ca>
Hannes Lubich (CH)      <lubich@komsys.tik.ethz.ch>
James McHugh (US)       <jmchugh@orion.oac.uci.edu>
Manuel Medina (ES)      <medina@ac.upc.es>
Barbara Nelson (US)     <barbara@retix.retix.com>
Juan Saras (ES)         <saras@dit.upm.es>
Peter Schicker (CH)     <schicker@clients.switch.ch>
Einar Stefferud (US)    <stef@ics.uci.edu>
Mike Schwartz (US)      <schwartz@latour.colorado.edu>
Marshall Rose (US)      <mrose@psi.com>
Douglas Terry (US)      <Douglas_B._Terry.PARC@xerox.com>
Pedro Veiga (PT)        <pmv@inesc.ctt.pt>
Brian Wideen (CA)       <wideen@vancouver.osiware.bc.ca>

Organizing Committee

Neil Koorland (Chair)

Network Mail Contacts

Gerald Neufeld          <neufeld@cs.ubc.ca>
Bernhard Plattner       <plattner@komsys.tik.ethz.ch>
Program Committee
(distribution list)     <ifip65-prog@ics.uci.edu>

Conference General Co-Chairs

Einar Stefferud         IFIP Working Group 6.5 Chair
Christian Huitema       IFIP Working Group 6.5 Vice-Chair

Tutorials

On May 18 and 19, 1992, time and space is reserved for a number of
tutorials. The following topics are being considered:

* Upper Layer/Application Layer Architecture
* Security Models, Mechanisms and Systems
* Message Handling X.400 (1992)
* Directory Services X.500 (1992)
* Network Management
* ASN.1
* Coexistence and Transition to OSI Applications
* Distributed Application Programming Environments

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 91 00:01:55 GMT
From:      rcbarn@rwa.urc.tue.nl (Raymond Nijssen)
To:        comp.protocols.tcp-ip,comp.windows.x,comp.unix.sysv386
Subject:   Re: alternative TCP/IP useable with X386?

jim@crom2.uucp (James P. H. Fuller) writes:
>     Lucky people who get TCP/IP free along with the rest of the system.
>I'm running Interactive SysV (ISC 2.2) and TCP/IP is an expensive optional
>extra.  But the docs for Thomas Roell's X386 say it has to run over TCP/IP.

Really? I admit I didn't read all of the docs, but there must be some
mistake, as I'm running Roell's X386 (his binary, to be precise) as I type, 
and I don't have any TCP/IP package.

>     Is there an alternative to buying TCP/IP from Interactive?

You don't need it. One of the great features of X386 is this little, 
well-hidden file called inetemul.o which solves your problem; if your
system lacks the TCP/IP libraries, simply add 
`-l /usr/lib/X11/X386/etc/inetemul.o' to the library definitions
when compiling an X application.

>Would something like ka9q compiled under Unix do the job?  With all the free
>TCP/IP implementations for DOS there are in the world, has anybody written
>one for SysV Unix?

I pretty sure that ka9q is not PD, but someone told me it has already
been ported to run under some flavour of unix. But why bother if it
ain't needed?

-Raymond

-- 
| Raymond X.T. Nijssen  | Eindhoven Univ. of Technology                       |
| raymond@es.ele.tue.nl | EH 7.13, PO 513, 5600 MB Eindhoven, The Netherlands |
| "Don't put that on the wall in a tax-payer supported museum!"  Pat Buchanan |

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 91 01:48:35 GMT
From:      rehmi@MILK.FTP.COM (rehmi post)
To:        comp.protocols.tcp-ip
Subject:   htonl() patented


this is ludicrous. see IEN 137, _On Holy Wars and a Plea for Peace_, by
Danny Cohen, 1 April 1980.

Date: Sat, 13 Jul 91 12:07:45 -0400
Sender: <tcp-ip-relay@nisc.sri.com>
From: rms@gnu.ai.mit.edu (Richard Stallman)
To: info-gnu@prep.ai.mit.edu, info-gnu-emacs@prep.ai.mit.edu
Subject: Patent on a standard-byte order for intermachine communication

US patent number 4,956,809 covers using a single standard byte
ordering for transfer of data between machines whose normal byte
ordering is different.

Unless invalidated (by prior art from mid-1982 or earlier), this patent
prohibits the principal means for transfering data between disparate
types of computer systems.  For example, Sun is now being faced with
demands to pay royalties for NFS, which uses this method.  This
directly threatens the GNU operating system, since we were planning to
support NFS.  (It also threatens BSD.)

Here is an explanation of the communication problem, and of the
solution which this patent covers.

The memory of today's computers is divided into units called bytes.
Each byte holds a single text character, or a number from 0 to 255.
Each byte of storage has a unique address.  These addresses start at 0
and range upward.

When you need to represent a number in a range bigger than 0 to 255,
you need more than one byte.  For example, two bytes can hold a number
in the range from 0 to 65535.  Four bytes can hold a number in the
range from 0 to 4294967295.  This four-byte number might be held in
bytes 72, 73, 74 and 75--four consecutive bytes.

There are various options for distributing the value of the number
among the bytes.  In practice, most of today's computers use one of
two methods.  The "little endian" method is to put the less
significant figures in the low-numbered bytes.  The "big endian"
method is to put the most significant figures in the low numbered
bytes.  (These names come from "Gulliver's Travels".)

If you transfer a block of data from a big-endian computer to a
little-endian computer, preserving the order of the bytes, all the
multi-byte numbers will be scrambled.

The simplest way to communicate data between different computers is to
set up a convention for the ordering of the bytes in any multi-byte
number.  If the big-endian ordering convention is chosen, then
little-endian computers must reverse the byte order when they read and
write network messages.

This is exactly what is covered by US patent 4,956,809.

If you find prior art dated 1982 or earlier, please inform
league@prep.ai.mit.edu.

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 91 02:17:28 GMT
From:      davidd@CS.WASHINGTON.EDU
To:        comp.protocols.tcp-ip
Subject:   (none)



Hello, Since this has probility been asked a millon times could you please
email me directly, thanks for your time and help: I have a friend in private
industry who is interested in getting his firm onto the net, i.e. internet
access. Any info on how to do this would be helpfull, thanks.

David

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 91 03:26:25 GMT
From:      smoot@cs.utexas.edu (Smoot Carl-Mitchell)
To:        comp.protocols.tcp-ip
Subject:   Re: simple network debugging writeups?


In article <MailManager.679281804.6685.hubert@kamba.cac.washington.edu> hubert@CAC.WASHINGTON.EDU (Steve Hubert) writes:
>Does anyone have an IP debugging guide that they would be willing to share?  I
>am thinking of something that would be a helpful guide when trying to isolate
>the cause of a problem, something like:
>
>    Try ping to a host on the same subnet, if that works try pinging the
>router, if that works, try telnet to a numeric IP address, etc.

I'm in the process of writing a book about TCP/IP and UNIX.  It will include
a chapter on network debugging using all the usual tools and tricks I've
learned over the past 8 years working with TCP/IP and UNIX systems.

Addison Wesley is the publisher and it will be out sometime next spring.  I'd
be happy to share drafts of the network debugging chapter to be sure I got
everything right and if there are some things I've missed.  Reply by mail
if you would like to review the chapter drafts.
-- 
Smoot Carl-Mitchell, Texas Internet Consulting
smoot@tic.com, smoot@cs.utexas.edu

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 91 04:00:15 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: On the need to develop Internet user services

In article <9107140101.AA00693@ucbvax.berkeley.edu> CSYSMAS@MVS.OAC.UCLA.EDU (Michael Stein) writes:
>#  An intelligent person would do the "obvious" and send themself a
>#  message.
>#  Why doesn't this work on most systems (for obtaining ones own
>#  E-mail address)?

I don't see how this could ever be used to find out one's address (either
snail or email).  It can only be used to *verify* an address.  And failure
to receive the message doesn't mean that the address is wrong; the mail
could have been lost.

>$  No, one of the important reasons for domains is that they a
>$  hierachical.  My address from here is just xyz. From upstairs
>$  (another department) it is xyz@abcd. From some other university
>$  it is xyz@abcd.gh and so on.

Snail mail addresses and telephone numbers are also hierarchical in the
same sense.  For someone sending me paper mail in my office, they only need
to put my name on it and it goes to my mail folder.  From somewhere in the
US they can put my address up to the state.  From some other country they
must add "USA".  Phone numbers are similar: within the company, it's just
an extension; within the area code, it's seven digits; within the US add
the area code; and elsewhere add the country code.

However, all these are just shortcuts.  Yes, within our company someone can
send me email as "barmar", but they can also say "barmar@think.com" and it
will still work.  You wouldn't give someone outside your company just your
extension number, would you?
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 91 05:37:38 GMT
From:      skl@wimsey.bc.ca (Samuel Lam)
To:        comp.protocols.tcp-ip,comp.sources.wanted
Subject:   Re: INETD Source (looking for internet wrapper)

In article <109@nvanbc.UUCP>, lharris@hcs.ca (Lawrence Harris) wrote:
>There was a posting about 2 months back for a program that could
>"wrap" an internet daemon and filter incoming requests so you
>could control what machines and nets a new request was allowed
>to come from.

Check out comp.sources.misc volume 20 issue 8 - log_tcp.

ftp.uu.net, among many other places, has comp.sources.misc
available for anonymous FTP.

...Sam
-- 
<skl@wimsey.bc.ca>

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 91 06:07:51 GMT
From:      zane@ddsw1.MCS.COM (Sameer Parekh)
To:        comp.protocols.tcp-ip,comp.archives.admin,comp.org.eff.talk,comp.mail.uucp,comp.mail.sendmail
Subject:   Re: On the need to develop Internet user services


	I like your method.  Especially considering that you KNOW all these
things, the fact that you are able to forget that something you know is
second-nature is very good.
-- 
The Ravings of the Insane Maniac Sameer Parekh -- zane@ddsw1.MCS.COM
More used address:	zane@infopls.mcs.com
	kill all overthrow government kill kill bomb bomb hi NSA
	

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 91 07:24:39 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: On paying for the Internet (was: Re: On the need to develop . . . )


In article <65015@bbn.BBN.COM> mckenzie@bbn.com (Alex McKenzie) writes:

   2) I have heard (I can't vouch for the accuracy of the story) that when
   the Boston-area rapid transit system was considering a fare increase
   several years ago, a study was commissioned to determine the "optimal"
   fare (in terms of minimizing transit system's annual loss).  The alleged
   conclusion of the study was that the cost to the taxpayers would be
   minimized if the fare-collectors were fired and the fare was free (this
   analysis may have included savings in road maintenace due to reduced
   highway traffic; I don't know).  But, goes the story, this approach was
   rejected by the decision makers, who felt that the taxpayers would rebel
   against the idea of giving free transportation to people who could
   afford to pay something for it.  Is this relevant to government
   decisions about allowing commercial use of the Internet?  To support for
   information providers?  To the NREN issue? 

The problem with making the fare free is that you might end up with a commons.
In any resource-allocation problem, when the resource is scarce, and there
is no means for restricting the use of the resource, the resource will
not be used efficiently.

Consider a modem pool.  When there are enough modems, people freely sign
on and off.  But when there aren't enough, people speed-dial, and then
they don't relinquish the modems when they don't need it.  And if you try
to establish an idle-logout procedure, people find ways to fake being
busy.

E.g. a certain company who shall remain nameless had a dial-up connection
to the internet.  This call would only be made once an hour (that's what
made the resource scarce).  Well, certain users (who shall also remain
nameless) would ping off-site hosts in order to keep the link busy.

I realize that this sounds like an argument for pay-per-use, but it
isn't really.  The Internet is only a commons when resources become
scarce, like they were back before some time around 1988.  If the
resources aren't scarce, and the costs of them can be passed on by a
fixed cost, then they *should* be a fixed cost.  Fixed costing
encourages use, and variable costing discourages use.

Right now, I think we want to encourage use of the Internet...


--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 91 08:56:53 GMT
From:      TAYBENGH@NUSDISCS.BITNET (THE AGEIS)
To:        comp.protocols.tcp-ip
Subject:   looking for papers on parallel make



Hi,
        I am looking for a paper on parallel make. I cannot get it in the
Library and it takes a lot time to requisite it. I hope who has the paper
can kindly send it to me. The particular of the paper is as follows:
        "Design and Implementation of Parallel Make"
        By Baalbergen, E.H.,
        Computing Systems, Vol. 1, No. 2, pp. 135-158, Spring 1988.
        Any body who has other papers related to parallel make, please
kindly send it to me too. I need them quite urgently since we are interesting
paprallel make.  I do not know which discussion group should I post to.  IF
I am abusing the net, please forgive me.  Thanks a lot.

- Beng Hang Tay (email: taybengh@nusdiscs.bitnet)
  Address:
        Beng-Hang Tay
        Department of Information Systems and Computer Science
        Naitonal University of Singapore
        Kent Ridge Crescent
        Singapore 0511
        Republic of Singapore

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 91 14:54:12 GMT
From:      root@mcinix.UUCP (Superuser)
To:        comp.protocols.tcp-ip
Subject:   Subnet Addresses & SLIP


If you have a system running SLIP and using say a subnet of 255.255.255.240
and you want to add another SLIP connection using the subnet of 255.255.255.0,
is this possible, or do you have to go through a router.

I have one SLIP up and running using the subnet of 255.255.255.240, things seem
fine, if I change the ifconfig to the different IP address and different
submask that works, I was wondering if I could have them both at the same time?

SCO Unix is the system I am using.

I do know that on another machine that is on the 255.255.255.240 with an
ethernet card I can't get a slip out of that machine running 255.255.255.0,
am I doing something wrong, or am I just ignorant of the facts?

Please email me at sfrazier@mcinix.vlink.com.

Thanks in advance


-- 
MCI Telecommunications, Inc.            | MCINIX System Administrator
485 Metro Place South, Suite 201        |---------------------------------------
Dublin, OH   43017                      | Local : postmaster
(614) 761-6612                          | Remote: postmaster@mcinix.vlink.com

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 91 16:42:35 GMT
From:      ddl@husc6.harvard.edu (Dan Lanciani)
To:        comp.protocols.tcp-ip
Subject:   gated usage


	I would be interested in hearing from anyone who is distributing
gated as part of, or in conjunction with, a commercial offering.

				Thanks,
				Dan Lanciani
				ddl@harvard.*

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 91 18:04:58 GMT
From:      jim@crom2.uucp (James P. H. Fuller)
To:        comp.protocols.tcp-ip
Subject:   Re: alternative TCP/IP useable with X386?


rcbarn@rwa.urc.tue.nl (Raymond Nijssen) writes:

> >     Lucky people who get TCP/IP free along with the rest of the system.
> > I'm running Interactive SysV (ISC 2.2) and TCP/IP is an expensive optional
> > extra.  But the docs for Thomas Roell's X386 say it has to run over TCP/IP.
>
> Really? I admit I didn't read all of the docs, but there must be some
> mistake, as I'm running Roell's X386 (his binary, to be precise) as I type, 
> and I don't have any TCP/IP package.


     I got the notion that you had to have TCP/IP from the r.1.1 release an-
nouncement:
     
     >       Announcing Release 1.1 of the X386 SYSTEM V/386 X11R4 server.
     >
     > REQUIREMENTS:
     > --------------------------------------------------------------------
     > 
     > X386 will run on following Unix operating systems:
     >
     >  	Interactive 386/ix, 2.0.2 or later
     >  	ESIX
     >  	SCO Unix (planned)
     >
     > You must have installed the STREAMS facility and optional TCP/IP. 

The way I read that, it says you have to have streams and your vendor's op-
tional TCP/IP package.  But I suppose it might mean that streams is required
but TCP/IP is optional.


> >     Is there an alternative to buying TCP/IP from Interactive?
>
> You don't need it. One of the great features of X386 is this little, 
> well-hidden file called inetemul.o which solves your problem; if your
> system lacks the TCP/IP libraries, simply add 
> `-l /usr/lib/X11/X386/etc/inetemul.o' to the library definitions
> when compiling an X application.

     Aha!  I'll give it a try!  Thanks very much.


crom2 Athens GA Public Access Unix   |  i486 AT, 16mb RAM, 600mb online
   Molecular Biology                 |  AT&T Unix System V release 3.2
   Population Biology                |  Tbit PEP 19200bps  V.32  V.42/V.42bis
   Ecological Modeling               |    admin: James P. H. Fuller
   Bionet/Usenet/cnews/nn            |    {jim,root}@crom2.rn.com

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 91 18:33:32 GMT
From:      fdm@WLV.IMSD.CONTEL.COM (Frank D. Malczewski)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented




Wouldn't this be something that Digital would have had to do in order for
DECnet to work between PDPs and VAXen ?  I recall in an R&D project I was
involved with (I didn't become involved with it until mid-83 though) that 
we were using routines to swap bytes so that traffic could be sent between
the two machines.

I find it really hard to believe that there aren't multiple cases of prior
art in existence...

Who does this patent belong to, anyhow?

--Frank Malczewski                        (fdm@wlv.imsd.contel.com)

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      14 Jul 91 20:48:44 GMT
From:      dan@gacvx2.gac.edu
To:        comp.protocols.tcp-ip
Subject:   Re: On paying for the Internet (was: Re: On the need to develop . . . )


In article <9107120052.AA12029@psi.com>, schoff@PSI.COM ("Martin Lee Schoffstall") writes:
>  1) Several people have observed that its easy for organizations to
>  budget for fixed costs, but virtually impossible for them to budget for
>  variable costs.  I disagree.  Almost every organization I know of,
>  universities, non-profits, and commercial, budgets at some level for use
>  of telephone services, use of postal services, use of package services,
>   ...  All of these are variable cost services based on usage.  Of course
>  the more users who are grouped together in the budget, the more the
>  costs take on the appearance (via statistical properties) of being fixed
>  costs.  I don't see any intrinsic reason why budgeting for information
>  services should be different.  In fact, I'll bet that most organizations
>  already budget for access to some kinds of information services (e.g.,
>  the company library has access to some information providers, the
>  marketing department gets D&B financial reports on current or
>  prospective customers).

Yes, variable costs are budgeted.  This is generally done by estimation, and
trating the estimate as a fixed cost.  Almost always when the estimate is
wrong, the use of the service is stoped, or slowed when funds run low.

-- 
Dan Boehlke                    Internet:  dan@gac.edu
Campus Network Manager         BITNET:    dan@gacvax1.bitnet
Gustavus Adolphus College
St. Peter, MN 56082 USA        Phone:     (507)933-7596

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 91 00:59:36 GMT
From:      stevenf@m2xenix.psg.com (Steven Frazier)
To:        comp.protocols.tcp-ip
Subject:   nslookup


How do you use nslookup and how do you set it up.  What is it actually used
for?

thanks.

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 91 07:16:26 GMT
From:      ant@brolga.cc.uq.oz.au (Anthony Murdoch)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   What does NDIS do for me ???

Hi netters,

I know this is going to make me sound really niave, but I've never
concentrated on the world of networking and I really need some answers to
the questions below.  BTW, do these groups have FAQ postings - I've been
looking for then for the past few weeks, but to no avail.

First some history - We are planning to make our Sun 4/470 here a Lan
Manager server (using LMserver).  I will be receiving an OS/2 workstation
(386 clone) to do testing/maint etc.  We also have a lot of VMS machines
around here offering PCSA sevices.

OK, so NDIS stands for Network Driver Interface Specification and is a
joint spec produced by Microsoft and 3com (for use with Lan Manager I take
it).  What I want to be sure on is, as the subject states, what does it do.

I have heard that it is some kind of translation layer, that allows
multiple protocols to be used at the same time.  This being the case, I
imagine that you would have a NDIS driver for your card and then drivers
for each of the protocols you wish to use, all of which talk to the NDIS
driver ???  Is this a valid imagination ???

This being the case, you would be able to set up a PC LM client with say
tcp/ip and decnet so that you could simultainiously use services from a
Lan Manager server using tcp/ip (say LMserver for Suns) and with PCSA
(or Pathworks - whatever they want to call it) on a VAX, all while using
telnet or ftp or something.  Is this reasonable to expect or is my head in
the clouds ???

The next question relates to NCSA telnet.  I've been using this package
for quite some time and I am fairly happy with it.  For the past few weeks
I have been using the latest version (2.3 ?) along with version 9 of the
clarkson drivers.  Can NCSA telnet work with ndis drivers ??  Are the
clarkson drivers compatible (I feel that's a silly question) ??

Basically, I want to be able to tie everything together.  I would like to
be able to connect to PCSA services, Lan Manager services and use telnet
and ftp etc.  Can it be done ????

Thanx in advance
ant

  V   ant                       "I killed Laura Palmer"
 \o/  ant@brolga.cc.uq.oz.au
 -O-  Anthony Murdoch           Prentice Centre
 /0\  Phone (07) 36 54078       University of Qld

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 91 12:00:34 GMT
From:      tinker@libai.UUCP (Don Tinker)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented


>>
>>Subject: Patent on a standard-byte order for intermachine communication
>>
>>US patent number 4,956,809 covers using a single standard byte
>>ordering for transfer of data between machines whose normal byte
>>ordering is different.
>>

I just read that US patent number 2,345,678 covers using written
symbols (called "numbers") to represent quantities -- I think we're
all in trouble now... 

Don Tinker				tinker@ultra.com
Senior Field Support Engineer		{core}!ames!ultra!tinker
UltraNetwork Technologies Inc. 		(703) 821-8393

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 91 12:33:28 GMT
From:      stevenf@m2xenix.psg.com (Steven Frazier)
To:        comp.protocols.tcp-ip
Subject:   backup over tcp/ip

s it possible to backup over tcp-ip using tar or ctar?  If so, how would you
do it?

Thanks inadvance.

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 91 15:50:04 GMT
From:      zumbachl@norand.UUCP (lyle zumbach)
To:        comp.protocols.tcp-ip
Subject:   Valid subnetwork numbers


A question about subnetting. Is it considered a no-no to use a subnetwork
number of 0 ? Here's my situation.: 
 
A class B address of 137.179 
A subnet mask of 255.255.240.0 
  
I have several hosts with IP addresses that start with 136.179.2.??? 
When I AND this with my subnet mask I get 136.179.0.0 
	
My next subnet start with hosts with IP addresses that start at 136.179.16.1 
When I AND this with my subnet mask I get 136.179.16.1 
	 
Can I assign an IP addresses in the range of 136.179.0.1 to 136.179.15.254
using my current network mask of 255.255.240.0 ? 
	  
This seems to be working OK all over my network. But, when I tried to
enter this subnet mask into my HP Ethertwist hub, the hub said that it
was an invalid subnet mask for the IP address 136.179.2.138. The HP tech.
support guy said that I shouldn't be using the addresses in the range
136.179.0.1 to 136.179.15.254. 

The problem is that I have about 100 PCs with such addresses and changing
them would be a real pain. 
		
I would really appreciate any advice. 
		 
Thanks, 
Lyle Zumbach 
Norand Corporation 
uunet!norand!zumbachl

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 91 16:12:53 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: nslookup

In article <1991Jul15.005936.19378@m2xenix.psg.com>, stevenf@m2xenix.psg.com (Steven Frazier) writes:
> How do you use nslookup and how do you set it up.  What is it actually used
> for?

You just type nslookup FQDN server, where FQDN is the fully qualified domain
name in question and server is the name or IP address of a DNS name server.
Minor details vary with the OS you are running.

There are many options available, but the man pages are the best place to look
for all of these. Also a reading of the RFCs for DNS will help you understand
just what these options really mean. 1032-1035 will tell you more than you
probably ever wanted to know about it.

There is no real "setup" needed.

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.

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 91 17:32:16 GMT
From:      hsw@COLUMBIA.SPARTA.COM (Howard Weiss)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented


If I recall correctly, all of the TCP/IP implementations for the PDP-11
also had to do byte swapping on data in and out of the network.  The
"standard" byte format as set by the RFCs was opposite that of the
PDP-11 series - which necessitated the byte swapping routines.  In fact,
I seem to recall a great debate over which routine took longer - the
checksum or the byte swapping.  Since the "great" ARPANET conversion
to TCP/IP occurred in 1983 and most of the implementations were written
in the preceeding years, this would clearly imply that this was going
on before 1982.

Howard Weiss

SPARTA, Inc.
9861 Broken Land Parkway
Suite 355
Columbia, MD 21046
phone: (301) 381-9400
email: hsw@columbia.sparta.com

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 91 19:29:39 GMT
From:      tr@samadams.princeton.edu (Tom Reingold)
To:        comp.protocols.tcp-ip
Subject:   Re: backup over tcp/ip

stevenf@m2xenix.psg.com (Steven Frazier) writes:

$ s it possible to backup over tcp-ip using tar or ctar?  If so, how would you
$ do it?

$ Thanks inadvance.

How about

	tar cvf - {dirname} | rsh {tapehost} dd of={tapedevice}

Then restore would be

	rsh {tapehost} dd if={tapedevice} | tar xvf - [names]
--
        Tom Reingold
        tr@samadams.princeton.edu  OR  ...!princeton!samadams!tr
        "Warning: Do not drive with Auto-Shade in place.  Remove
        from windshield before starting ignition."

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 91 20:09:13 GMT
From:      torben@FORALIE.ICS.HAWAII.EDU (Torben Nielsen)
To:        comp.protocols.tcp-ip
Subject:   Re:  follow up [Re: unsolicited unclassified FYI]


>Since we did drive faster than 55mph, I apologize for our people's speeding.  
>However, we obviously did not drive too fast, therefore, "economic sanction" 
>("don't buy") is not acceptable.

The problem wasn't so much one of speed. Rather, it was one of you not having
a license.....

As far as I'm concerned, you've been appropriately reprimanded for your actions
and that's the end of the issue as far as I'm concerned. What bothers me is
your attitude that you weren't ``that wrong". You were very clearly over the
line. Please realize that and get on with conducting your business.

						Cheers, Torben

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 91 21:20:47 GMT
From:      fyuan@INTERLINK.COM (Felix Yuan)
To:        comp.protocols.tcp-ip
Subject:   Looking for stream based ldterm and telnet module


Does anyone have any vendor information regarding stream based ldterm and
telnet module on UNIX SVR3/SVR4?

Please respond via E-mail

Thanks in advance.

Felix Yuan    fyuan@interlink.com

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 91 22:20:39 GMT
From:      willis@cs.tamu.edu (Willis Marti)
To:        comp.protocols.tcp-ip
Subject:   Re: On the need to develop Internet user services


Peter wrote:
">From bad to worse... first, some guy who thinks the whole world consists of
second year (at least) CS and EE students. Then another guy who thinks that
the first guy was doing a good job. How about this:

"To send mail to someone through the Internet mail system (called the Domain
Name System or DNS for reasons we shan't go into here)..."

Arghhh! If we're going to simplify things, at least let's not put out
completely wrong information.  In no way is the DNS == Internet mail.

Willis Marti

"remember, user is a 4 letter word."

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 91 22:58:29 GMT
From:      torben@FORALIE.ICS.HAWAII.EDU (Torben Nielsen)
To:        comp.protocols.tcp-ip
Subject:   These guys don't give up!


Looks like these people just don't give up; they certainly don't seem to get
the point. Does anyone know who their service provider is? They keep trying
to peddle their product even though I've *never* requested any information
about it! Unless their service provider will deal with this and educate them,
the only option I have is to impose filtering against them. 

						Torben

From netix.com!yeh Mon Jul 15 12:38:55 1991
Received: from netix.com by foralie.ics.Hawaii.Edu with SMTP id 55; Mon, 15 Jul 91 12:38:46 HST
Received: from localhost.netix.com by netix.com (4.1/LLNL-1.18)
	id AA04628; Mon, 15 Jul 91 15:37:26 PDT
Message-Id: <9107152237.AA04628@netix.com>
To:	Torben Nielsen <torben@foralie.ics.hawaii.edu>
Cc:	yeh@netix.com
Subject: Re: follow up [Re: unsolicited unclassified FYI] 
In-Reply-To: Your message of "Mon, 15 Jul 91 10:09:13 -1000."
             <91Jul15.100916hst.55@foralie.ics.Hawaii.Edu> 
Date:	Mon, 15 Jul 91 12:37:22 HST
Sender: <tcp-ip-relay@nisc.sri.com>
From:	Shannon Yeh <yeh@netix.com>
Status: RO

 > and that's the end of the issue as far as I'm concerned. What bothers me is
 > your attitude that you weren't ``that wrong". You were very clearly over the
 > line. Please realize that and get on with conducting your business.

Thanks for the comment, Torben. 

Are you interested to have a look at the product, anyway?

Best...\shannon

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      15 Jul 91 23:14:29 GMT
From:      jnford@argos.weeg.uiowa.edu (Jay Ford)
To:        comp.protocols.tcp-ip
Subject:   Re: backup over tcp/ip


In article <tr.679606179@samadams>, tr@samadams.princeton.edu (Tom Reingold) writes:
|> stevenf@m2xenix.psg.com (Steven Frazier) writes:
|> 
|> $ s it possible to backup over tcp-ip using tar or ctar?  If so, how would you
|> $ do it?
|> 
|> How about
|> 	tar cvf - {dirname} | rsh {tapehost} dd of={tapedevice}
|> Then restore would be
|> 	rsh {tapehost} dd if={tapedevice} | tar xvf - [names]

We do the same thing, but with dump/restore instead of tar.  We found it
necessary to force blocking (by using obs=32k with dd) to keep restore happy.

------------------------------------------------------------------------
Jay Ford, Weeg Computing Center, University of Iowa, Iowa City, IA 52242
jnford@handlebar.weeg.uiowa.edu, 319-335-5555

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 12:22:01 GMT
From:      mni@techops.cray.com (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   Re:  Subnet Addresses & SLIP

your subnet ...240 is a subset address space from the subnet ...0   .
If your subnetting implementation is intelligent it will see that.
Subnet address spaces should be non overlapping if they are meaningful.
If your sw does not check that you get unpredictable results, depending
on your route hashing.

michael


(.. and the disclaimer)

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 12:56:52 GMT
From:      mni@techops.cray.com (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   Re:  backup over tcp/ip

tar cvf - dir_to_tar_path | rsh targetmachine cat '>' where_to_put_archive_path

path specifications must be sufficient, beware of rsh (does not know your
private $PATH $path values!)
don't forget the .rhosts stuff!

'>' : the ' are important!

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 13:44:27 GMT
From:      mni@CRAYAMID.CRAY.COM (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   backup over tcp/ip


tar cvf - dir_to_tar_path | rsh targetmachine cat '>' where_to_put_archive_path

path specifications must be sufficient, beware of rsh (does not know your
private $PATH $path values!)
don't forget the .rhosts stuff!

'>' : the ' are important!


michael



(... and the disclaimer ...)

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 13:57:50 GMT
From:      HANK@VM.BIU.AC.IL (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Network maps v2

This document is meant to catalog all known network maps in postscript
format that are available via the Internet.  One purpose is so that people
can review other network maps for ideas and formats.  The main purpose
is for the newly forming RIPE mapping WG to determine what icons people
use in their network maps and to create an RFC that standardizes the
icons as well as the format that people will create for their network
maps.  Please send all corrections and additions to this list to:
hank@vm.tau.ac.il

CAVAET:

Some Postscript maps won't print correctly on many laser printers.
This is due to the files being in Apple Postscript rather than in
standard postscript.  Most maps reported here will print properly.
-----------------------------------------------------------------
1) anonymous ftp name and number
   aarnet.edu.au   139.130.204.4

2) cd __________
   pub/maps

3) get ___________.ps
   aarn-backbone.ps

4) What is included in your map?
   Backbone of AARNet network, link speeds, comment on topology

5) How often is it updated?
   Whenever something significant changes! Say, every three months,

6) Contact?
   P.Elford@aarnet.edu.au
-----------------------------------------------------------------
1) anonymous ftp name and number
   ftp.cc.berkeley.edu        128.32.136.9

2) cd __________
   pub

3) get ___________.ps
   ucb.map.ps

4) What is included in your map?
   The UCB IP routers

5) How often is it updated?
   Whenever I feel like it (actually I just created it recently).

6) Contact?
   cliff@garnet.berkeley.edu
-----------------------------------------------------------------
1) anonymous ftp name and number
   Arizona.EDU  128.196.128.233

2) cd __________
   networks.maps

3) get ___________.ps
   uanet-prepped.ps

4) What is included in your map?
   Subnets of the University of Arizona's network (128.196.0.0).

5) How often is it updated?
   Once every couple of months or so.

6) Contact?
   Leonard@Arizona.EDU
-----------------------------------------------------------------
1) anonymous ftp name and number
   NIS.NSF.NET    35.1.1.48

2) cd __________
   maps

3) get ___________.ps
ASIANET  PS       V        128        276          8  1/17/89  1:30:13
BACKBONE NEW-PS   V        117       6765         50 10/01/90 14:41:43
BACKBONE OLD-PS   V         94       2437         25  2/24/89 15:40:22
BACKBONE OLD2-PS  V         94       2445         25  2/24/89 15:39:57
BACKBONE T1-PS    V        106       6375         46  4/18/91 12:36:39
BACKBONE T1T3-PS  V        108       7088         51  4/23/91  9:39:58
BACKBONE T3-PS    V        117       6515         46  4/18/91 15:05:57
BARRNET  PS       V        124       1222         10  5/30/90 11:39:03
BITNET   PS       V        130       2870         85  1/17/89  1:30:20
BITNET4  PS       V        130       3389        101  1/17/89  1:30:28
CERFNET  PS       V        876       3594         24 11/30/90 11:03:39
CICNET   PS       V         28      23597         68  2/11/91 18:16:12
CORNELL  PS       V        112        110          2  2/17/89  1:53:49
DC       PS       V         99        421          5  3/23/89 11:01:45
EARNET   PS       V        129       1447         43  1/17/89  1:30:33
ESNET    PS       V         94       2462         25  5/05/89 14:10:25
HARVARD  MAP      V         78         59          1  2/17/89  1:57:53
LOSNETTO PS       V        106       1309          9 11/27/90 17:26:12
MERIT-MI PS       V         88       6449         19  6/01/90 11:50:09
MIDNET   PS       V        132        730          6  2/17/89  1:52:58
NA_NETS  PS       V         94       2802         26  5/17/89  9:56:55
NCAR     PS       V        255       1602         11  2/17/89  1:52:46
NETMAP   DOC      V         78       1140         13  2/24/89 16:05:27
NETNORTH PS       V        129        511         16  1/17/89  1:30:36
NYSERNET PS       V         53       2475          9  2/17/89  1:56:40
PREPNET  PS       V         80       1856          9  2/22/89  9:59:39
PSC_IP   PS       V         80       3479         18  2/22/89  9:59:48
RICENET  PS-LW    V         57       2079          8  3/07/89 16:31:24
SCINET   PS       V         94       2536         26  4/28/89 14:23:35
SCINETDC PS       V        100        280          3  4/28/89 16:40:31
SESQUINE PS-LW    V         53        610          3  3/07/89 16:31:11
SURANET  PS       V         87       1158         13  3/23/89 11:01:40
SURAN289 PS       V         96        468          4  3/07/89 16:29:10
TEXASIP  PS       V         96        405          4  3/07/89 16:28:32
UIUC     PS       V         93        904          5 12/28/88 14:10:34
UIUC-MAP PS       V         72       3892         14 12/28/88 14:10:45
UMNET    PS       V        124       1343          9  5/30/90 10:14:22
UNETS-A  PS       V         94       3824         29  5/14/90 14:29:51
USENIX   PS       V         79       4916         17  2/10/89  9:29:59
USNETS   PS       V         94       3824         29  5/14/90 14:26:37

4) What is included in your map?

5) How often is it updated?

6) Contact?
   userhelp@nis.nsf.net
-----------------------------------------------------------------
1) anonymous ftp name and number
   mcsun.eu.net       192.16.202.1

2) cd __________
   ripe/maps

3) get ___________.ps
   Jun  4 10:25 europe.ps
   Feb  2  1990 map01-netnums.ps.Z
   Feb  2  1990 map01-speeds.ps.Z
   Jun 15  1990 map02-netnums.ps.Z
   Jun 20  1990 map02-speeds.ps.Z
   Jul  9  1990 map03-legend.ps.Z
   Jul  9  1990 map03-netnums.ps.Z
   Jul  9  1990 map03-speeds.ps.Z
   Aug 28  1990 map04-legend.ps.Z
   Aug 28  1990 map04-netnums-1p.ps.Z
   Aug 28  1990 map04-netnums-2p.ps.Z
   Aug 28  1990 map04-speeds-1p.ps.Z
   Aug 28  1990 map04-speeds-2p.ps.Z
   Nov  9  1990 map05-legend.ps.Z
   Nov  9  1990 map05-netnums-1p.ps.Z
   Nov  9  1990 map05-netnums-2p.ps.Z
   Nov  9  1990 map05-speeds-1p.ps.Z
   Nov  9  1990 map05-speeds-2p.ps.Z
   Feb 27 14:16 map06-legend.ps.Z
   Feb 27 13:55 map06-netnums.ps.Z
   Feb 27 13:54 map06-speeds.ps.Z
   Jun  4 10:25 us-europe.ps

4) What is included in your map?

5) How often is it updated?

6) Contact?
-----------------------------------------------------------------
1) anonymous ftp name and number
   nic.nordu.net    192.36.148.17

2) cd __________
   maps

3) get ___________.ps
   Nov  9  1990 ch-map-netnums.ps
   Nov  9  1990 ch-map-speeds.ps
   May 26 20:35 europe.ps
   Mar  2  1990 fi-map.ps
   Mar  2  1990 fr-map.ps
   Nov  9  1990 map05-legend.ps
   Nov  9  1990 map05-netnums-1p.ps
   Nov  9  1990 map05-netnums-2p.ps
   Nov  9  1990 map05-speeds-1p.ps
   Nov  9  1990 map05-speeds-2p.ps
   Mar 14  1990 nl-map.ps
   Mar  2  1990 no-map.ps
   Nov  9  1990 nordunet.ps
   May 26 20:36 us-europe.ps

4) What is included in your map?

5) How often is it updated?

6) Contact?
-----------------------------------------------------------------
1) anonymous ftp name and number
   ftp.pitt.edu    130.49.253.1

2) cd __________
   /prepnet/maps

3) get ___________.ps
   member_map_mmddyy.ps
   connectivity_map_mmddyy.ps

4) What is included in your map?
   member map is the geographical locations of our members and shows
   the backbone circuits; connectivity map shows how the routers are
   connected and the speed of the connections

5) How often is it updated?
   member map is updated each time we have a new member; connectivity
   map is updated each time a member is connected or a member changes
   some configuration

6) Contact?
   kf1b+@andrew.cmu.edu
-----------------------------------------------------------------
1) anonymous ftp name and number
   spot.colorado.edu   128.138.129.2

2) cd __________
   westnet

3) get ___________.ps
   map.ps

4) What is included in your map?
   A logical map of Westnet, the Rocky Mountain states Internet
   regional network.

5) How often is it updated?

6) Contact?
---------------------------------------------------------------------
1) anonymous ftp name and number
   nisc.sesqui.net         128.241.0.84

2) cd __________
   pub

3) get ___________.ps
   texas.ps

4) what is included in your map?
   The combined IP topology of Sesquinet and THEnet implemented as
   a single autonomous system of Cisco routers.  No detail at the
   campus level is included.

5) how often is it updated?
   Whenever this topology changes.

6) Contact?
-----------------------------------------------------------------
1) anonymous ftp name and number
   vm.tau.ac.il            132.66.32.4

2) cd __________
   hank.400

3) get ___________.ps
   ilanmap.ps

4) what is included in your map?
   The cisco router backbone in Israel, line speeds, router interfaces and
   subnet addresses.  Certain headers and legends are in Hebrew.

5) how often is it updated?
   Whenever this topology changes.

6) Contact?
   ccyilan@technion.technion.ac.il
-----------------------------------------------------------------
1) anonymous ftp name and number
   ftp.lcs.mit.edu   18.26.0.36

2) cd __________
      nets

3) get ___________.ps
   get {LCS,AI,MIT,NEAR}.PS


4) what is included in your map?
   LCS: The lab where I work
   AI: Another lab closely connected in the same building
   MIT: MIT overall (slightly out-of-date, does not have new FDDI yet)
   NEAR: NEARnet, the New England Academic and Research network
         (an NSFnet regional)

5) how often is it updated?


6) Contact?
   map@lcs.mit.edu
-----------------------------------------------------------------
1) anonymous ftp name and number
   cs.ucl.ac.uk     128.16.5.31

2) cd __________
   bbn

3) get ___________.ps
   icb_twb_map.ps

4) what is included in your map?
   A topology map of the Terrestrial Wideband Net (twbnet) and the
   International Cooperation Board Net (icbnet).

5) how often is it updated?


6) Contact?
   J.Crowcroft@cs.ucl.ac.uk
-----------------------------------------------------------------
1) anonymous ftp name and number
   nic.near.net     192.52.71.4

2) cd __________
   maps

3) get ___________.ps
   nearnet-topology.PS

4) what is included in your map?


5) how often is it updated?
   Weekly

6) Contact?
   jcurran@nic.near.net
-----------------------------------------------------------------
1) anonymous ftp name and number
   nisc.jvnc.net   128.121.50.7

2) cd __________
   nicol/MAPS

3) get ___________.ps
   JvNCnet.PS

4) What is included in your map?
   Sites connected, backbone topologies, and speed of links.

5) How often is it updated?
   Monthly, at least.

6) Contact?
   nisc@jvnc.net
-----------------------------------------------------------------
1) anonymous ftp name and number
   ns.nic.yorku.ca         130.63.7.3

2) cd __________
   pub/york/maps

3) get ___________.ps
   ip-backbone-v3.2.ps

4) what is included in your map?


5) how often is it updated?


6) Contact?
-----------------------------------------------------------------
1) anonymous ftp name and number
   noc.sura.net        192.80.214.100

2) cd __________
   maps

3) get ___________.ps
   noc.map.ps
   directions.map.ps
   geo.map.ps
   sites.map.ps

4) what is included in your map?


5) how often is it updated?


6) Contact?
-----------------------------------------------------------------
1) anonymous ftp name and number
   ftphost.nwnet.net       128.95.112.1

2) cd __________
   local/nwnet

3) get ___________.ps
   nwnet-map.ps

4) what is included in your map?


5) how often is it updated?


6) Contact?
-----------------------------------------------------------------
1) anonymous ftp name and number
   nic.es.net         128.55.32.3

2) cd __________
   maps

3) get ___________.ps
   ESNET-BACKBONE-MAP.PS

4) what is included in your map?


5) how often is it updated?


6) Contact?
-----------------------------------------------------------------
1) anonymous ftp name and number
   nic.barrnet.net       36.56.0.151

2) cd __________
   barrnet

3) get ___________.ps
   barrnet.geog.ps
   barrnet.ps

4) what is included in your map?


5) how often is it updated?


6) Contact?

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 15:49:51 GMT
From:      greg@gagme.chi.il.us (Gregory Gulik)
To:        comp.protocols.tcp-ip,misc.wanted
Subject:   Ethernet question and hardware wanted.


I'm pretty new to this so please bear with me.

I want to get a 3B2 and a 386 talking to each other
over TCP/IP.  Both computers have Ethernet cards
(the 3B2 has a D-Type connector, and the 386 has
both the D-Type and a Coax connector)

Since this is for home use, I would like to set
up the network as inexpensively as possible.

What hardware do I need?

I assume I need the following:

Drop cable
Transciever to convert to Coax
Those T shaped connectors
A Coax cable
Coax terminators


Is that right?
Can anyone recomment a better way?

Does anyone have any of the above that they don't
need and would be willing to sell?

Thanks.

-greg

-- 
Gregory A. Gulik                                        Call Gagme, a public
       greg@gagme.chi.il.us  ||  gulik@depaul.edu       access UNIX system at
   ||  gulik@motcid.rtsg.mot.com                        (312) 714-8568

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 16:24:42 GMT
From:      lars@spectrum.CMC.COM (Lars Poulsen)
To:        comp.protocols.tcp-ip
Subject:   Re: ftp file type extenstion

In article <RS.91Jul9084810@sun09.com> rs@sun09.com (Rick Silterra) writes:
>I am adding to ftp the capability to write to a non-standard file
>type ("contiguous").  I would like this capability in my non-standard 
>ftp server to be available to standard ftp clients.

Some IBM MVS resident implementations have used the SITE command to
communicate DCB feature options before a STOR command. Your need appears
to be similar. In particular, STRU is NOT the right thing, since the 
contiguous attribute is orthogonal to the STRU attributes.
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 17:03:14 GMT
From:      dab@BERSERKLY.CRAY.COM (David Borman)
To:        comp.protocols.tcp-ip
Subject:   Re: Valid subnetwork numbers

> Date: 15 Jul 91 15:50:04 GMT
> From: norand!zumbachl@uunet.uu.net  (lyle zumbach)
> Organization: Norand Data Systems, Cedar Rapids, IA
> Subject: Valid subnetwork numbers
> 
> A question about subnetting. Is it considered a no-no to use a subnetwork
> number of 0 ? Here's my situation.: 

Yes, a subnetwork number of 0 is illegal.  From RFC 1122, page 31:

            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 above).
            This implies that each of these fields will be at least two
            bits long.

			-Dave Borman, dab@cray.com

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 17:04:23 GMT
From:      wmarko@UB.D.UMN.EDU (William J. Marko)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented

Received:  by ub.d.umn.edu (5.59/UMD-891211)
	id AA01193; Tue, 16 Jul 91 12:00:05 CDT
Sender: <tcp-ip-relay@nisc.sri.com>
From: wmarko (William J. Marko)
Full-Name: William J. Marko
Message-Id: <9107161700.AA01193@ub.d.umn.edu>
Subject: Re: htonl() patented
To: backman@ftp.com (Larry Backman)
Date: Tue, 16 Jul 91 12:00:03 CDT
Cc: tcp-ip
In-Reply-To: <9107160120.AA07739@ftp.com>; from "Larry Backman" at Jul 15, 91 9:20 pm
X-Mailer: ELM [version 2.3 PL11]

>  >> >>Subject: Patent on a standard-byte order for intermachine communication
>  >> >>
>  >> >>US patent number 4,956,809 covers using a single standard byte
>  >> >>ordering for transfer of data between machines whose normal byte
>  >> >>ordering is different.
>  >> >>
>  >> 
>  >> I just read that US patent number 2,345,678 covers using written
>  >> symbols (called "numbers") to represent quantities -- I think we're
>  >> all in trouble now... 
>  >>
> 
> 
> I'm planning on taking out a series of patents on the following lines
> 
> 	for (i=0; i < 2; i++)
> 	for (i=0; i < 3; i++)
> 		...
> 		...
> 
> 	for (i=0; i < 100; i++)
> 
> I figure 17 years of royalties on these lines would be worth the legal
> fees.  :-)
> 					
> 					Larry

my feelings exactly.  i was considering applying for a patent on the
addition and multiplication tables we all learned as a youth.  and if
that goes well, next will be the concept of providing exactly one
outcome when we flip a coin.  or the much more complex notion of
having exactly one outcome (out of six) when a labeled cube is tossed.

note how careful i was to avoid the use of those special symbols so i
would not get stuck for paying a fee for sending this message.

-- 
Bill Marko			wmarko@ub.d.umn.edu	internet
UMD Information Services	wmarko@umndul		bitnet
10 University Drive		218-726-8842		work
Duluth, MN   55812		218-724-7617		home

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 17:20:41 GMT
From:      mah@wu-wien.ac.at (Michael Haberler)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented


A quick grep finds that RFC791 (IP) defines `Data Transmission Order at the
octet level' in Appendix B.  It is dated September 1981.

I dont have old RFC's accessible - could someone check?

This is getting incredible. What a waste of resources.

- michael

-- 
Michael Haberler 		mah@wu-wien.ac.at,  mah@awiwuw11.bitnet
University of Economics and Business Administration
A-1090 Vienna, Augasse 2-6	   
Tel: +43 (1) 961-679 (voice & fax) D-Netz/Cell Tel: +43 (663) 811-056

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 17:23:59 GMT
From:      sam@unity.ncsu.edu (Sam Moore)
To:        comp.protocols.tcp-ip
Subject:   Who is running WHOIS(or other)?


Who is running WHOIS as a directory service? Is anyone else running something 
like this? Is there anything in the works for a TCP/IP dirctory service 
standard?

-- 
------------------------------------------------------------------------------  
        | Sam Moore | Sam_Moore@ncsu.edu | NCSU Computing Center | 
------------------------------------------------------------------------------

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 17:30:08 GMT
From:      ken@opusc.csd.scarolina.edu (Ken Sallenger)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented

In <1991Jul14.183332.24637@wlbr.imsd.contel.com>
fdm@WLV.IMSD.CONTEL.COM (Frank D. Malczewski) writes:

[ about possibility of prior art in network byte-order conventions]

>Wouldn't this be something that Digital would have had to do in order for
>DECnet to work between PDPs and VAXen ?

That would have been word-swapping: both little-endian, but 16-bit vs.
32-bit words.  Same principle, though.

>I find it really hard to believe that there aren't multiple cases of prior
>art in existence...

I, too.  I worked with serial links among PDPs, VAXen, and M68Ks during
the period in question.  It's the sort of thing that our students
probably re-invented constantly. 

-- 
     Ken Sallenger / ken@bigbird.csd.scarolina.edu / +1 803 777-6551
     Computer Services Division / 1244 Blossom ST / Columbia, SC 29208

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 18:11:31 GMT
From:      peterd@cs.mcgill.ca (Peter Deutsch)
To:        comp.protocols.tcp-ip
Subject:   Re: On paying for the Internet (was: Re: On the need to develop . . . )

In article <1991Jul14.144845.35@gacvx2.gac.edu> dan@gacvx2.gac.edu writes:
>In article <9107120052.AA12029@psi.com>, schoff@PSI.COM ("Martin Lee Schoffstall") writes:
>>  1) Several people have observed that its easy for organizations to
>>  budget for fixed costs, but virtually impossible for them to budget for
>>  variable costs.  I disagree.  Almost every organization I know of,
>>  universities, non-profits, and commercial, budgets at some level for use
>>  of telephone services, use of postal services, use of package services,
>> ...  All of these are variable cost services based on usage.  .  .  .

I was one of the people who suggested that it was
difficult in the university world to budget for variable
costs, and I said this from some experience, although I
should have been more specific. I was refering to
the start-up phase for a new service (and I know about
those!).

Let's take our network links here at McGill university as
a case study. My department (the School of Computer
Science) was the first in Montreal to have an Internet
link, and also one of the first to have a CDNnet link
(CDNnet was an early, and still surviving, Canadian-based
network of researchers).

Our Internet link was via a leased line to Boston (CSnet)
and was at a fixed cost per year (about $35k/year for
9600baud <AackOoP!>, plus the needed hardware maintenace
contracts and part of a body to watch over things).

CDNnet was at the time only a "pay as you go" network,
based on commercial X:25 links with communications costs
proportional to usage (I understand you can now get fixed
cost links, but this was not an option in 1986-87). I
could only guess at usage and costs, but the figure I
calcuated was seen as a floor and I could offer no
guarantees to potential users and those I approached for
funding.

Now, when I took over the management of our equipment,
one of the programmers had been investigating networking
and had arranged connections to both nets. These were
installed for testing but not operational.

When I realized what I'd had inherited I wanted to
preserve as much as I could so asked around for the needed
funding. I was told by my Departmental chair that if I
could find the money I could keep things going, but it was
made clear (in no uncertain terms) that the department was
not paying for network connections since we just couldn't
afford it. Initially the University Computing Centre
treated this as just another Computer Science experiment
and didn't see it as a viable campus-wide service at that
point.

I can be pretty pursuasive sometimes and I managed to raise
some money (eventually the Computing Centre gave a fixed
size donation, CRIM - a local research group - gave a fixed
donation, etc). We had enough to get things started, but
we had no mechanisms in place to bill our customers and
nobody with the time to build these mechanisms. Cost
recovery was not even an option for the first year.

In addition, all our inital users (mainly comp.sci. and
engineering groups at the four Montreal area universities)
stated time and again that they couldn't help with cash
but loved the service and encouraged us to keep it going.

Their pressure on their institutions did lead to the
development of our regional and the eventual financing of
the network and yes, in fact they are all paying for
things now since all university money comes out of the
same pot. The biggest challenge for people wishing to
start up such services is to somehow pry that money away
from other, equally valid projects to demonstrate your
viability. This is easier when you are asking for a fixed
amount. It is somewhere from hard to impossible if you are
making estimates or educated guesses and your costs will
rise if you're a success.

Given the uncertain nature of the CDNnet charges, I let
that link go with some regret. We kept the Internet link
going until the demonstrated usefulness convinced the
powers-that-be to finance it themselves and the university
took over its operation. We now have a regional network,
connected to a national network, a faster link to the
Internet and the world is all sweetness and light.

The point of all this is to say that once a service is
established and demonstrated to be useful, people will
come out of the woodwork to claim responsibility for it.
At least in our case, getting it off the ground is very
difficult, and would have been impossible in this case if
we'd in fact been "punished" by our own success by rising
costs in the first two years.

In practice, we very quickly saturated our slow, fixed
speed, fixed cost line to the States and thus we found
ourselves with limitations on our ability to deliver.
Fortunately, this very success could be used as proof of
the demand for a campus-wide service (and Quebec wide)
network and we've now gone on to a pretty stable
configuration. I'm still convinced that if we'd been
paying proportional costs my own link would have died on
the vine and networking would have taken longer to develop
here.

This is all about the initial start-up phase and gaining
acceptance for a _new_ idea or service. I've seen exactly
the same pattern play out for our archie service.  Now
it's a success my boss in making noises about letting us
run a version here at CC (I came over here six months ago
but archie still lives at Comp. Sci. on borrowed hardware)
and we've a number of volunteer sites installing archie
code.  Still, this was not something that was easy to
launch.  We were amazingly lucky to be in a position to
offer cycles to the Internet at a time when no one saw
this as a viable idea and even now are not yet in a
position to guarantee ongoing development. I think this is
a near universal problem for innovative service ideas and
after all, one of the beauties of the Internet is that it
is still spawning such ideas.

This initial resistance to innovation stands in the way of
any new service charged as pay-as-you-go. How do you show
people they need it? You let them try it at relatively low
risk. One it is accepted you can look at other methods of
payment, and we would then talk about the "Internet
culture" and resistance to paying for things that people
percieve to be "free" but before you can do that I really
think you have to get over the initial hump of "buyer
resistance" and get things underway. This is eaiser if
costs are fixed and predictable.

>> .  .  .  .  .  Of course
>>  the more users who are grouped together in the budget, the more the
>>  costs take on the appearance (via statistical properties) of being fixed
>>  costs.  I don't see any intrinsic reason why budgeting for information
>>  services should be different.  In fact, I'll bet that most organizations
>>  already budget for access to some kinds of information services (e.g.,
>>  the company library has access to some information providers, the
>>  marketing department gets D&B financial reports on current or
>>  prospective customers).

These are all established services. I would hope and
expect that in a year or two we'll have commercial
Internet information providers and using them will be an
acceptable thing to do. Departmental chairs or university
management would then see paying for this as part of doing
their work.  Right now the Internet is still in some
measure seen as an experimental entity and there is
resistance to treating its associated costs as a business
expense like the telephone or photocopier. Maybe we have to work
at changing this attitude, but we're still going to have
it for a while to come. Maybe we don't want to, if we want
to continue to sponsor innovation. Food for thought, and
perhaps another posting...

>
>Yes, variable costs are budgeted.  This is generally done by estimation, and
>trating the estimate as a fixed cost.  Almost always when the estimate is
>wrong, the use of the service is stoped, or slowed when funds run low.

I will second this. In 1987 I had about $35k to spend on
networking from various sources. If I'd run out I can be
sure there would have been no more that year and we'd have
had to limit access to the net. This is not a problem
today and I'm sure that we would have eventually connected
but for sure our access would have come later and with
greater restrictions.

I believe that the current perceived fixed cost nature of
the Internet is one of its greatest assets. Before we
change this too much perhaps we should look at the effect this
would have on innovation and the ability of smaller groups
to contribute to the "community". Maybe we _need_ this
perception to keep the experimentation going? I may be
wrong, but I'd be careful about pay as you go at least in
the short-term.


				- peterd

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

 " Although botanically speaking a fruit, in 1893 the U.S. Supreme Court 
 unanimously ruled that tomatoes are a vegetable (and thus taxable under 
 the Tariff Act of 1883) because of the way they are usually served. "

                                          ref:  Smithsonian, August, 1990.
------------------------------------------------------------------------------

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 18:33:00 GMT
From:      gavron@alpha.sunquest.com (Ehud Gavron 602-885-7700x.2546)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented

In article <1991Jul16.172041.23956@swdsrv.edvz.univie.ac.at>, mah@wu-wien.ac.at writes...
# 
#A quick grep finds that RFC791 (IP) defines `Data Transmission Order at the
#octet level' in Appendix B.  It is dated September 1981.
# 
#I dont have old RFC's accessible - could someone check?

[RFC0791.TXT, page 39]

APPENDIX B:  Data Transmission Order

The order of transmission of the header and data described in this
document is resolved to the octet level.  Whenever a diagram shows a
group of octets, the order of transmission of those octets is the normal
order in which they are read in English.  For example, in the following
diagram the octets are transmitted in the order they are numbered.


    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       1       |       2       |       3       |       4       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       5       |       6       |       7       |       8       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       9       |      10       |      11       |      12       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Transmission Order of Bytes

                               Figure 10.

Whenever an octet represents a numeric quantity the left most bit in the
diagram is the high order or most significant bit.  That is, the bit
labeled 0 is the most significant bit.  For example, the following
diagram represents the value 170 (decimal).


                            0 1 2 3 4 5 6 7 
                           +-+-+-+-+-+-+-+-+
                           |1 0 1 0 1 0 1 0|
                           +-+-+-+-+-+-+-+-+

                          Significance of Bits

                               Figure 11.

Similarly, whenever a multi-octet field represents a numeric quantity
the left most bit of the whole field is the most significant bit.  When
a multi-octet quantity is transmitted the most significant octet is
transmitted first.


#This is getting incredible. What a waste of resources.
	
	Indeed.

#- michael
# 
#-- 
#Michael Haberler 		mah@wu-wien.ac.at,  mah@awiwuw11.bitnet
#University of Economics and Business Administration
#A-1090 Vienna, Augasse 2-6	   
#Tel: +43 (1) 961-679 (voice & fax) D-Netz/Cell Tel: +43 (663) 811-056

	Ehud

--
Ehud Gavron        (EG76)     
gavron@vesta.sunquest.com

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 19:16:25 GMT
From:      yeh@NETIX.COM (Shannon Yeh)
To:        comp.protocols.tcp-ip
Subject:   Re: These guys don't give up!


 > Looks like these people just don't give up; they certainly don't seem to get
 > the point. Does anyone know who their service provider is? They keep trying
 > to peddle their product even though I've *never* requested any information
 > about it! Unless their service provider will deal with this and educate them,
 > the only option I have is to impose filtering against them. 


	enough is enough...

	Please note that there are two types of advertising:
		Type 1:
			Dear People, please listen to me...

		Type 2:
			Dear People, please do not listen to them...

	Maybe Type 2 is non-profitable, but, it construes the fact that someone
	is trying to call a group of people for destroying something, or for
	making up her/himself, or for other purposes.

Shannon Tao Yeh

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 20:23:13 GMT
From:      johnf@hprnd.rose.hp.com (John Flick)
To:        comp.protocols.tcp-ip
Subject:   Re: Valid subnetwork numbers

From: zumbachl@norand.UUCP (lyle zumbach)

> A question about subnetting. Is it considered a no-no to use a subnetwork
> number of 0 ? Here's my situation.: 

From RFC 1122 ( Requirements for Internet Hosts ) Sec 3.2.1.3, Page 31:

    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 above).

The special cases listed are the various types of broadcast addresses.

Later in the same section, on Page 32:

    A host MUST silently discard an incoming datagram containing
    an IP source address that is invalid by the rules of this
    section.  This validation could be done in either the IP
    layer or by each protocol in the transport layer.

> Can I assign an IP addresses in the range of 136.179.0.1 to 136.179.15.254
> using my current network mask of 255.255.240.0 ? 

The above rule seems to say no.

Note that RFC 1122 was written in October, 1989, and many IP implementations
on the market were written before this RFC, or ported from implementations
written before this RFC.  The IP layer in the HP Ethertwist hubs was written
more recently, and it adheres to these rules.


John Flick
Hewlett Packard Company
Roseville Networks Division
johnf@hprnd.rose.hp.com

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 20:45:27 GMT
From:      eli@bart.UUCP (Eli Blumenthal)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented



So -- Who owns this patent anyways??  

Eli Blumenthal
Penril DataComm Networks	(301) 921-8600 x8869 (Voice)
1300 Quince Orchard Boulevard	(301) 921-8376 (FAX)
Gaithersburg, Maryland  20878	uunet!penril!eli

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 21:16:57 GMT
From:      utterbac@husc9.harvard.edu (Margot Utterback)
To:        comp.protocols.tcp-ip
Subject:   What is Connectathon, Interop, and how do you test interoperability?

I am trying to get a handle on interoperatibility between network devices.
Just what is Interop? Connectathon? How to they relate and how do you sign 
up (as an attendee? as a vendor?) 

Some time ago there was a discussion about a network test lab where a vendor 
could test interoperability. Does anyone have any info about this?

Does anyone know of any tcp/ip test suites?

Does anyone know of any network testing tools like traceroute and tcpdump
that will run under System V R4?  PErhaps tcpdump and traceroute already do?

Any info will be appreciated.

Margot Utterback
utterbac@husc9.harvard.edu

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 22:18:56 GMT
From:      scoggin@delmarva.delmarva.COM (John Scoggin)
To:        comp.protocols.tcp-ip
Subject:   (none)

Subject: Re: htonl() patented
To: email!swdsrv.edvz.univie.ac.at!wu-wien.ac.at!mah@uunet.UUCP (Michael Haberler)
Date: Tue, 16 Jul 91 18:18:55 EDT
Sender: <tcp-ip-relay@nisc.sri.com>
From: John Scoggin <scoggin@delmarva.delmarva.com>
Cc: tcp-ip@nisc.sri.com
Priority: Idle Chatter
Reply-To: scoggin@delmarva.com
In-Reply-To: <1991Jul16.172041.23956@swdsrv.edvz.univie.ac.at>; from "Michael Haberler" at Jul 16, 91 5:20 pm
X-Mailer: ELM [version 2.3 PL11]

> 
> 
> A quick grep finds that RFC791 (IP) defines `Data Transmission Order at the
> octet level' in Appendix B.  It is dated September 1981.
> 
> I dont have old RFC's accessible - could someone check?
> 
> This is getting incredible. What a waste of resources.
> 
> - michael
> 
> -- 
> Michael Haberler 		mah@wu-wien.ac.at,  mah@awiwuw11.bitnet
> University of Economics and Business Administration
> A-1090 Vienna, Augasse 2-6	   
> Tel: +43 (1) 961-679 (voice & fax) D-Netz/Cell Tel: +43 (663) 811-056
> 

You are correct - the excerpt from RFC791 is attached:  Note the date!


----------------------------------------------------------------------
John K. Scoggin, Jr.	
Supervisor, Network Operations		Phone:  (302) 451-5200
Delmarva Power & Light Company		        (800) 388-7076
500 N. Wakefield Drive			Fax:    (302) 451-5321      
Newark, DE  19714-6066	                Email:  scoggin@delmarva.com
-----------------------RFC EXCERPT FOLLOWS (RFC791) ------------------


September 1981                                                          
                                                       Internet Protocol



APPENDIX B:  Data Transmission Order

The order of transmission of the header and data described in this
document is resolved to the octet level.  Whenever a diagram shows a
group of octets, the order of transmission of those octets is the normal
order in which they are read in English.  For example, in the following
diagram the octets are transmitted in the order they are numbered.

                                    
    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       1       |       2       |       3       |       4       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       5       |       6       |       7       |       8       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       9       |      10       |      11       |      12       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Transmission Order of Bytes

                               Figure 10.

Whenever an octet represents a numeric quantity the left most bit in the
diagram is the high order or most significant bit.  That is, the bit
labeled 0 is the most significant bit.  For example, the following
diagram represents the value 170 (decimal).

                                    
                            0 1 2 3 4 5 6 7 
                           +-+-+-+-+-+-+-+-+
                           |1 0 1 0 1 0 1 0|
                           +-+-+-+-+-+-+-+-+

                          Significance of Bits

                               Figure 11.

Similarly, whenever a multi-octet field represents a numeric quantity
the left most bit of the whole field is the most significant bit.  When
a multi-octet quantity is transmitted the most significant octet is
transmitted first.

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 23:29:21 GMT
From:      rleeson@rleesonpc.nswc.navy.mil (Robert Leeson)
To:        comp.protocols.tcp-ip
Subject:   KA9Q Internet Program




        
I understand that there is an Internet program called KA9Q by 
Phil Karn --- Can anyone tell me where I can find a copy?
 
thanks much --- Rob
        
---------------------------------------------------------------
Robert Leeson, Jr
rleeson@relay.nswc.navy.mil --- please send email here not to the
				address in the header

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      16 Jul 91 23:45:10 GMT
From:      hyder@spike.ucar.edu (Paul Hyder)
To:        comp.protocols.tcp-ip
Subject:   Re:  backup over tcp/ip

From hosts that don't already support rmt based tar/dump/cpio the
easiest method for backup over the net is to simply get a copy of
gnutar and compile it.  Gnutar not only knows how to get to remote
drives it handles sparse files, knows how to dump single file systems
from overlapped spaghetti, handles network link blocking, and can
provide very nice headers.

My experience with cpio or tar piped to any type of rsh was that it
would have connection problems fairly often.  Almost nothing is as
bad as a garbled backup in the middle of an 8mm tape.  We're currently
dumping a bunch of SysV machines daily with gnutar.

Gnutar is available from your local gnu archive.
	Paul Hyder
	NOAA/FSL

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 00:11:04 GMT
From:      gabriel@DISO.DGSCA.UNAM.MX (Gabriel C. Lopez Walle)
To:        comp.protocols.tcp-ip
Subject:   Re:  backup over tcp/ip

Yes, many of the anonymous ftp work with tar files...

   Your friend.  Gabriel C. Lopez Walle.

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 02:21:37 GMT
From:      ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
To:        comp.protocols.tcp-ip
Subject:   Re: These guys don't give up!

yeh@NETIX.COM (Shannon Yeh) writes:
>
> > Looks like these people just don't give up; they certainly don't seem to get
> > the point. Does anyone know who their service provider is? They keep trying
> > to peddle their product even though I've *never* requested any information
> > about it! Unless their service provider will deal with this and educate
 [...] 
>	enough is enough...
>
Apparently, it is not...

>	Please note that there are two types of advertising:
>		Type 1:
>			Dear People, please listen to me...
>
>		Type 2:
>			Dear People, please do not listen to them...
>
>	Maybe Type 2 is non-profitable, but, it construes the fact that someone
>	is trying to call a group of people for destroying something, or for
>	making up her/himself, or for other purposes.
>
>Shannon Tao Yeh

BS.

I also got an unsolicited ad from Shannon, and I objected to it in strong
terms. If he sent me another solicitation, no matter how subtle, I'd raise
hell about it. I don't have any axe to grind, I have no stake in Shannon's
misery, etc... I simply hate to see the Net turn into yet another Home
Shopping Channel. In the past month I've received 4 unrelated letters like
that. *Dear People, please do not listen to them...*, and keep those
outraged letters coming to whatever gateway those types use!!!

Your [highly] dissatisfied customer.    E.
-- 
Eric Behr, Illinois State University, Mathematics Department
Internet: ejbehr@rs6000.cmp.ilstu.edu    Bitnet: ebehr@ilstu

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 02:50:33 GMT
From:      battle@cs.utk.edu (David Battle)
To:        comp.protocols.tcp-ip
Subject:   SLIP woes


I am having some problems running SLIP.  I am running a version called sl41beta
I got from a guy at UT.  Is there a more recent/better public domain version
available?

My configuration is, I have a Sun 3 at home attached to a Telebit T2500 modem
which dials in to a Microcom v.32 MNP modem connected to a cisco router at
the University of Tennessee Computer Science Department.

The problem is, SLIP seems to work fine for things like telnet (I'm using
it right now), but if I try to use it for FTP there are long periods of
silence (I mean really long, like 5 minutes or more) when the modem is neither
transmitting or recieving.  This makes ftp from here absolutely useless.
This is especially true if I am ftping to somewhere besides UT, like uunet.
Note that ftp to uunet from UT works just fine.  What, if anything, can I do?

-David L. Battle
battle@cs.utk.edu

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 07:16:34 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: What is Connectathon, Interop, and how do you test interoperability?

In <1991Jul16.171658.1886@husc3.harvard.edu> utterbac@husc9.harvard.edu (Margot Utterback) writes:

>I am trying to get a handle on interoperatibility between network devices.
>Just what is Interop? Connectathon? How to they relate and how do you sign 
>up (as an attendee? as a vendor?) 

Interop is probably the biggest and best of the data communications trade
conferences.  It is held in the fall. This fall it is 7-11 October in
San Jose.  They claim to draw over 10,000 people, and given how hard it
was to get a hotel room in the neighborhood last year, I believe it.
The first two days are courses, which are also generally very good (but
note, I'm biased about the courses, I teach one).  One nice thing about
the conference is that all vendors are required to connect to the Show
Network -- so you can see their stuff work and actually give it a spin.
Last year the FDDI network didn't quite work, which was interesting to
see.  Anyway, you can call them at +1 415-941-3399 or 1-800-INTEROP
for information.

I don't recall what Connectathon is.

>Some time ago there was a discussion about a network test lab where a vendor 
>could test interoperability. Does anyone have any info about this?

Digital Equipment Corporation's Network Systems Lab has a facility to
allow groups to test the interoperability of their software.  A nice
public service.  Call them -- they're in Palo Alto.

Craig Partridge

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 08:57:04 GMT
From:      rlang@NISC.SRI.COM (Ruth Lang)
To:        comp.protocols.tcp-ip
Subject:   Re: Who is running WHOIS(or other)?

Sender: <tcp-ip-relay@nisc.sri.com>
From: taco!sam@mcnc.org  (Sam Moore)
Subject: Who is running WHOIS(or other)?
Message-Id: <1991Jul16.172359.23875@ncsu.edu>
To: tcp-ip@nic.ddn.mil

> Who is running WHOIS as a directory service? Is anyone else running something 
> like this? Is there anything in the works for a TCP/IP dirctory service 
> standard?


As part of the DARPA Field Operational X.500 (FOX) project, SRI has
developed a prototype offering of the existing WHOIS data via the
Directory. The types of information available include: autonomous
system, computer, domain, group, individual, IP network, and
organization.  Various relationships among these items, such as
administrative and technical points of contact are supported as well.
The DSA offering this data is a QUIPU process running as part of the
White Pages Pilot Project.  If you'd like more information on this
effort, please contact me directly.

There are two other related activities to note: 1) There is a whois
emulation (a front end to the dish program) offered as part of the
QUIPU distribution.  This offers whois-like access to information in
the Directory, but not specifically to registered entities.  2) Merit
has developed schema to support site contact information for the
Internet (i.e., points of contact for IP network and autonomous
systems registered with the SRI NIC).  This is an alternative
structuring for a subset of the WHOIS data.

Ruth Lang
SRI International

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 16:10:18 GMT
From:      HOU@MSL1.MARINE.USF.EDU
To:        comp.protocols.tcp-ip
Subject:   (none)

Hi,netters,
Anyone out there can tell me: how do I ftp some files with long extention
like abc.gif.Z to VMS? When I do this, it said 'pipe broken'.
Many thanks in advance.

William Hou
PhD, Marine Science
USF,
hou@msl1.marine.usf.edu

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 17:11:23 GMT
From:      josevela@mtecv2.mty.itesm.mx (Jose Angel Vela Avila)
To:        comp.protocols.tcp-ip
Subject:   Re: KA9Q Internet Program

rleeson@rleesonpc.nswc.navy.mil (Robert Leeson) writes:




>        
>I understand that there is an Internet program called KA9Q by 
>Phil Karn --- Can anyone tell me where I can find a copy?
> 
>thanks much --- Rob
>        

 Yes ! it is in ucsd.edu server in subdirectory hamradio/ka9q/nos

 Enjoy it !!


 Jose A. Vela Avila

josevela@mtecv2.mty.itesm.mx

   ITESM

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 17:17:04 GMT
From:      brunner@telebit.com (Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Re: What is Connectathon, Interop, and how do you test interoperability?

In article <1991Jul16.171658.1886@husc3.harvard.edu> utterbac@husc9.harvard.edu (Margot Utterback) writes:
>I am trying to get a handle on interoperatibility between network devices.
>Just what is Interop? Connectathon? How to they relate and how do you sign 
>up (as an attendee? as a vendor?) 

I can't give you details on Connectathon, but suggest that you contact the
Sun User's Group for details. InterOp vendors call InterOp and reserve booth
space, they may or may not want to join a technology-specific demo group as
well. There is cost of course, for booth space. Network drops are provided
as the vendor requests (unless the requests are insane), this year like last
we're providing 802.3 over UTP throughout and 802.5, X.25, T1, T3 and FDDI
for the respective demo groups. Attendees call InterOp (415) 941-3399 and
get an information mailing sent to them.

>Some time ago there was a discussion about a network test lab where a vendor 
>could test interoperability. Does anyone have any info about this?

InterOp used to mean just that, however we've noticed that aside from the
leading edge hardware and software implementations (e.g., fddi last year),
there is a very load utilization of the shownet's backbone. Rib utilization
was also low. Two "test labs" have come into existance in the past two years:
the ANTC at AMD in Sunnyvale, which is were at least one of the 91 InterOp
demo groups will test their gear (fddi), and several vendor-owned certified
test facilities. Someone from each of these ought to supply further details
on each.

>Does anyone know of any tcp/ip test suites?

What are you testing? Router (rfc1009) conformance? Some aspect of host 
network layer (rfc1122) behavior? Or some aspect of network application(s)
on a host. It makes a difference.

>Does anyone know of any network testing tools like traceroute and tcpdump
>that will run under System V R4?  PErhaps tcpdump and traceroute already do?

I suggest that it would be a mistake to use time forcing tools to work on
foreign platfoms when they are drop-ins on cheap and widely available boxes.
Get a Sun at a price you can afford (3/50-M4 run for $750 last time I looked)
and run tcpdump and traceroute to your heart's content.

>Any info will be appreciated.

You're welcome!

-- 
Eric Brunner
Tule Network Services - 4bsd/rt project

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 17:58:36 GMT
From:      zweig@parc.xerox.com (Jonathan M. Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented

I think it is a bad idea to try to fight this patent on Prior Art grounds. It
should be fought on Obviousness.

-Johnny Patent

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 18:42:09 GMT
From:      yeh@NETIX.COM (Shannon Yeh)
To:        comp.protocols.tcp-ip
Subject:   Re: These guys don't give up!


Disclaimer:  this will be my last message on the subjected discussion.  Thanks.

 > I also got an unsolicited ad from Shannon, and I objected to it in strong
 > terms. If he sent me another solicitation, no matter how subtle, I'd raise

Please note that I sent you information upon your request in the newsgroup!!  
(You asked questions in the newsgroup).

Your message is attached here:
 
|| From orion.oac.uci.edu!usc!zaphod.mps.ohio-state.edu!mips!news.cs.indiana.edu!ux1.cso.uiuc.edu!rs6000.cmp.ilstu.edu!ejbehr Tue Jun 18 19:14:28 PDT 1991
|| Article: 1721 of comp.mail.mh
|| Path: orion.oac.uci.edu!usc!zaphod.mps.ohio-state.edu!mips!news.cs.indiana.edu!ux1.cso.uiuc.edu!rs6000.cmp.ilstu.edu!ejbehr
|| From: ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
|| Newsgroups: comp.mail.mh
|| Subject: MH vs. POP ?
|| Message-ID: <1991Jun13.052158.2269@rs6000.cmp.ilstu.edu>
|| Date: 13 Jun 91 05:21:58 GMT
|| Reply-To: ejbehr@rs6000.cmp.ilstu.edu (Eric Behr)
|| Organization: Central Illinois Surfing Club
|| Lines: 16
|| 
|| Here is a couple of questions someone asked me:
|| 
|| First, what are the experiences of those who use mh and xmh with a PC
|| client PC/MH? (I've never used it).
|| 
|| Second - how does that combination compare to a POP server and available
|| POP clients on the PC?
|| 
|| Around here, we use sendmail, popd and POP3 clients with good results, so I
|| have no other experience. It is therefore possible that even my phrasing of
|| the questions is nonsensical - please forgive me.
|| 
|| Thanks in advance.
|| -- 
|| Eric Behr, Illinois State University, Mathematics Department
|| Internet: ejbehr@rs6000.cmp.ilstu.edu    Bitnet: ebehr@ilstu


 > Your [highly] dissatisfied customer.    E.

	Both I and my Employer will never interact with you again.

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 19:07:42 GMT
From:      booloo@lll-crg.llnl.gov (Mark Boolootian)
To:        comp.protocols.tcp-ip
Subject:   Can you drop the packet that caused the ARP?

Folks,

Is it inappropriate behaviour for a router to drop a packet if it first must
fulfill an arp request before sending that packet (leaving it to upper layers
someplace else to resend the original packet)?  Is this discussed in any RFC?
And how about for a host?  I would think a router could reasonably drop a packet
if it first had to arp in order to keep resources from being consumed.

Any help is appreciated.

regards,
mb

booloo@lll-crg.llnl.gov

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 19:17:52 GMT
From:      hz01930@hx.deere.com (jay d. anderson)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP and Novell at the same time.

Sorry if this has been asked before; I imagine it has.

What ethernet cards are capable of handling both TCP-IP and IPX packets at
the same time.  Our specific need is to run AttachMate for 3270 access to
mainframes while using PC-NFS to handle file serving from assorted Unix and
VMS boxes.

Thanks for any input.


--
Jay D. Anderson                   hz01930@hx.deere.com
John Deere Harvester              ...uunet!deere!cygnus!hz01930
1100 13th Avenue                  (309) 765-6063
E. Moline, Illinois 61244

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 19:32:37 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you drop the packet that caused the ARP?

In article <102003@lll-winken.LLNL.GOV> booloo@lll-crg.llnl.gov (Mark Boolootian) writes:
>Is it inappropriate behaviour for a router to drop a packet if it first must
>fulfill an arp request before sending that packet (leaving it to upper layers
>someplace else to resend the original packet)?  Is this discussed in any RFC?

1009, the gateway requirements RFC, is silent about it.  However, 1122, the
host requirements RFC (part 1) explicitly says "don't do that unless you
really must":  it messes up performance, e.g. by confusing TCP's initial
round-trip-time estimate, and can be quite troublesome to UDP applications
(e.g. name service) that are cautious about retrying.  These sound like
good arguments against doing it in a gateway/router too.
-- 
Lightweight protocols?  TCP/IP *is*     | Henry Spencer @ U of Toronto Zoology
lightweight already; just look at OSI.  |  henry@zoo.toronto.edu  utzoo!henry

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 20:26:59 GMT
From:      peter@ficc.ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented

In article <1991Jul14.183332.24637@wlbr.imsd.contel.com> fdm@WLV.IMSD.CONTEL.COM (Frank D. Malczewski) writes:
> Wouldn't this be something that Digital would have had to do in order for
> DECnet to work between PDPs and VAXen?

PDP-11s use 3 4 1 2 order for longs. VAXen use 1 2 3 4. So they would just
have to swap words.

I don't think there is anything in the PDP-11 hardware that requires 3 4 1 2,
by the way. It's just a convention.
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 22:04:00 GMT
From:      mcdaniel@HQAFSC-VAX.AF.MIL ("Mr Rodney A McDaniel")
To:        comp.protocols.tcp-ip
Subject:   IBM TERMINALS AND X.25 MILNET TACS - SYNCHRONOUS/ASYNCHRONUS

Andrews AFB

                  I N T E R O F F I C E   M E M O R A N D U M

                                        Date:     17-Jul-1991 04:41pm EST
                                        From:     Mr Rodney McDaniel
                                                  MCDANIEL
                                        Dept:     HQ AFSC/SCXR
                                        Tel No:   DSN 858-7909 COMM 301/981-7909
                                        Owner:    Mr Rodney McDaniel

TO:  Remote Addressee                     ( _TCP-IP-RELAY@NISC.SRI.COM )
TO:  Remote Addressee                     ( _TCP-IP@NISC.SRI.COM )


Subject: IBM TERMINALS AND X.25 MILNET TACS - SYNCHRONOUS/ASYNCHRONUS



Netlanders,

Recently, we have been informed to migrate to use the DDN MILNET 
instead of our dedicated circuits for our IBM TYPE Terminals and 
IBM Networks.  Therefore, we run into major problems with 
capability and speed of service responses between the two 
different types of Protocols, plus the IBM users have some serious 
doubts about migrating to DDN versus service and reliability. 

Not to go into specifics, what I really need is a Point of 
Contact(s) within the IBM World that has any "magical black boxes" 
that provides an interface to MILNET DDN and still provides SDLC 
speed of service and Network Control.  Synchronous versus 
Asynchronous and SNA verus X.25 Packet Switching.  ANY Assistance 
would be appreciated.

So, if any one out there has gone thru this type of scenario, 
or has a plausible solution would appreciate hearing from you 
direct.  To save Bandwidth, and boring the other Netlanders, 
please reply directly to:

HQ AFSC/SCXR
Mr. McDaniel
Email: mcdaniel@hqafsc-vax.af.mil
COM: 301-981-7909
Andrews AFB MD

Disclaimer:  I am doing this on my own to try and help out some of 
our users.  The Air Force doesn't have any idea what I am doing!!

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 22:06:00 GMT
From:      poulson@cs.widener.edu (Joshua Poulson)
To:        comp.protocols.tcp-ip
Subject:   Yet another subnetting question

Here at Widener University we've recently acquired a Class B network
number (yay!) and we're thinking of subnetting with eight bits.  This
way we can keep the departments separated by subnet number and have the
dotted IP numbers be meaningful to everyone.  

We have a problem to consider, however.  Two departments sit on the
other side of a Proteon router and I want each one of the departments to
have its own subnet.  So... I tell them to use the 255.255.255.0 subnet
mask and I tell them to send everything else to the router.

Can I have the router keep those two departments cool over there?  For
example, what's going to happen when one subnet pings the other and the
ping is sent to the router?

Since we're growing up from Class C we haven't had much of a chance to
play with subnetting yet, so we're all new...

Thanks a lot for your pointers,
-- 
Joshua R. Poulson (NIC handle: JRP8)       [Joshua.R.Poulson@cyber.Widener.EDU]
Systems Programmer, Widener University     [poulson@cs.Widener.EDU]

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      17 Jul 91 23:34:43 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you drop the packet that caused the ARP?

In article <102003@lll-winken.LLNL.GOV>, booloo@lll-crg.llnl.gov (Mark Boolootian) writes:
> Folks,
> 
> Is it inappropriate behaviour for a router to drop a packet if it first must
> fulfill an arp request before sending that packet (leaving it to upper layers
> someplace else to resend the original packet)?

From RFC1122:

         2.3.2.2  ARP Packet Queue

            The link layer SHOULD save (rather than discard) at least
            one (the latest) packet of each set of packets destined to
            the same unresolved IP address, and transmit the saved
            packet when the address has been resolved.
                       
            DISCUSSION:
                 Failure to follow this recommendation causes the first
                 packet of every exchange to be lost.  Although higher-
                 layer protocols can generally cope with packet loss by
                 retransmission, packet loss does impact performance.
                 For example, loss of a TCP open request causes the
                 initial round-trip time estimate to be inflated.  UDP-
                 based applications such as the Domain Name System are
                 more seriously affected.

``SHOULD'' means ``this is what we recommend, but you're not required
to comply''.

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 01:58:55 GMT
From:      heffron@falstaff.css.beckman.com (Matt Heffron)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented

In <zweig.679773516@osric> zweig@parc.xerox.com (Jonathan M. Zweig) writes:

>I think it is a bad idea to try to fight this patent on Prior Art grounds. It
>should be fought on Obviousness.

Actually it's BOTH, you must show that it would have been obvious at the time
the invention was made, therefore the state of prior art will impact on how
obvious it is.

"No patent--if the differences between the subject matter sought to be patented
 and the prior art are such that the subject matter as a whole would have been
 obvious at the time the invention was made to a person having ordinary skill in
 the art to which said subject matter pertains." [35 U.S.C. sec.103]

(quoted in "An Intellectual Property Law Primer", Kinther, Earl W. and Jack L.
Lahr, 1975, Macmillan Publishing Co., Inc. page 30)

-Matt

(Disclaimer: I'm not a lawyer, I just looked it up in the book.)

Matt Heffron                      heffron@falstaff.css.beckman.com
Beckman Instruments, Inc.         voice: (714) 961-3128
2500 N. Harbor Blvd. MS X-11, Fullerton, CA 92634-3100
No tax $$ to plan a murder.  (No federal funding of abortion councelling.)
--
Matt Heffron                      heffron@falstaff.css.beckman.com
Beckman Instruments, Inc.         voice: (714) 961-3128
2500 N. Harbor Blvd. MS X-11, Fullerton, CA 92634-3100
No tax $$ to plan a murder.  (No federal funding of abortion councelling.)

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 03:49:24 GMT
From:      battle@cs.utk.edu (David Battle)
To:        comp.protocols.tcp-ip
Subject:   dialupip

Has anyone out there ported dialupip2.0 to SunOS 4.1.1?

Thanks,
	-David L. Battle
	battle@cs.utk.edu

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 09:59:17 GMT
From:      ami@msil.sps.mot.com (Ami Ben-Amram.System Manager.)
To:        comp.protocols.tcp-ip
Subject:   HELP

HELP
LIST

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 14:39:15 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented

In article <WQOCVQA@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
>PDP-11s use 3 4 1 2 order for longs. VAXen use 1 2 3 4. So they would just
>have to swap words.
>
>I don't think there is anything in the PDP-11 hardware that requires 3 4 1 2,
>by the way. It's just a convention.

If I am not misremembering, the PDP11 hardware floating point units had some
instructions that used 32 bit integers, and these dictated the byte order.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 14:44:07 GMT
From:      hardiman@csd4.csd.uwm.edu (Paul V Hardiman)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet question and hardware wanted.


References: <1727@gagme.chi.il.us>
Sender:	Paul Hardiman 

Distribution: world 
Organization: University of Wisconsin - Milwaukee
Keywords: 

In article <1727@gagme.chi.il.us> greg@gagme.chi.il.us (Gregory Gulik) writes:



>I want to get a 3B2 and a 386 talking to each other
>over TCP/IP.  Both computers have Ethernet cards
>(the 3B2 has a D-Type connector, and the 386 has
>both the D-Type and a Coax connector)
 
>Since this is for home use, I would like to set
>up the network as inexpensively as possible.
 
>What hardware do I need?
>
>I assume I need the following:
 
>Drop cable
>Transciever to convert to Coax
>Those T shaped connectors
>A Coax cable
>Coax terminators
>










You don't need any Ethernet cable and transceivers for a 2-station
network.  You can get a 2-port direct connect box instead.  This is
a self-contained Ethernet with 2 AUI ports in a box about 1x2x6".
The only cables needed are from the 2 Ethernet adapters to the direct
connect box - these are standard AUI cables.  You can also get 4-port
direct connects.  Black Box carries these at $225 for 2 ports, $375
for 4 ports.

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 15:26:14 GMT
From:      holbrook@cic.net (J Paul Holbrook)
To:        comp.protocols.tcp-ip
Subject:   CICNet DS-3 Report

This report was done to survey the need for DS-3 speeds in
CICNet.  It should be of interest to anyone who wants to know what
kinds of applications may need DS-3 speeds.

J. Paul Holbrook
CICNet Technical Services Manager
holbrook@cic.net    (313) 998-7680


Message-Id: <9107181439.AA15987@nic.cic.net>
To: members@farnet.org
Subject: CICNet DS-3 Report
Date: Thu, 18 Jul 91 10:39:51 -0400
Sender: <tcp-ip-relay@nisc.sri.com>
From: Mike Staman <staman@cic.net>


A report titled "High Performance Applications on CICNet: Impact on Design 
and Capacity" is available from CICNet via anonymous FTP.

host:       NIC.CIC.NET 
directory:  /pub/reports
file:       ds3-report.[ps or txt]

ABSTRACT: This twenty-three page report summarizes available network 
technologies, reports on a survey of the needs of researchers and faculty 
at CIC institutions, and provides detailed studies of network 
requirements in four areas of contemporary, scientific research: 

1) Advanced Radiation Sources 
2) Astronomy 
3) Computational Science
4) Geology, Seismology, and Geophysics

The needs of these four areas of research are then summarized in terms
of network requirements, and specific recommendations are presented by
the working group to CICNet, Inc. The report was authored by the
CICNet DS-3 Working Group, which was chaired by Mike Enyeart of Indiana
University.

                                          E. Michael Staman
                                          President
                                          CICNet, Inc.     

------- End of Forwarded Message

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 15:34:06 GMT
From:      art@opal.acc.com (Art Berggreen)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you drop the packet that caused the ARP?

In article <102003@lll-winken.LLNL.GOV> booloo@lll-crg.llnl.gov (Mark Boolootian) writes:
>Folks,
>
>Is it inappropriate behaviour for a router to drop a packet if it first must
>fulfill an arp request before sending that packet (leaving it to upper layers
>someplace else to resend the original packet)?  Is this discussed in any RFC?
>And how about for a host?  I would think a router could reasonably drop a packet
>if it first had to arp in order to keep resources from being consumed.
>
>Any help is appreciated.
>
>regards,
>mb
>
>booloo@lll-crg.llnl.gov

IMHO, I believe that dropping a packet is not the proper thing to do.
In most cases, the ARP will be resolved relatively quickly and the packet
could be delivered.  Dropping the packet causes the transport layer to
have to time out and retransmit.  All other routers in the path to the
one doing the dropping also have to reswitch the retransmitted packet.
If the dropped packet was the initial SYN for a TCP connect (likely case),
then the initial round-trip estimate may fairly large, which translates
to a long retransmit timeout.  This may be noticeable by the user.
I believe this behavior is often seen though, when pinging a node and
the first ping or two is lost.

Art

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 16:50:54 GMT
From:      coates@UC780.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: What is Connectathon, Interop, and how do you test interoperability?

In article <1991Jul17.071634.5801@sics.se>, craig@sics.se (Craig Partridge) writes:

>In <1991Jul16.171658.1886@husc3.harvard.edu> utterbac@husc9.harvard.edu (Margot Utterback) writes:
>>Some time ago there was a discussion about a network test lab where a vendor 
>>could test interoperability. Does anyone have any info about this?
>
>Digital Equipment Corporation's Network Systems Lab has a facility to
>allow groups to test the interoperability of their software.  A nice
>public service.  Call them -- they're in Palo Alto.
>
>Craig Partridge

I've also heard that the same folk who put on Interop, are attempting to set up
a lab to test vendors products for interoperability.

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 16:52:11 GMT
From:      josevela@mtecv2.mty.itesm.mx (Jose Angel Vela Avila)
To:        comp.protocols.tcp-ip
Subject:   Re: (none)

HOU@MSL1.MARINE.USF.EDU writes:

>Hi,netters,
>Anyone out there can tell me: how do I ftp some files with long extention
>like abc.gif.Z to VMS? When I do this, it said 'pipe broken'.
>Many thanks in advance.


 Well you could do :

 get abc.gif.Z abc.Z

 Your archive is going to be save with the abc.Z name ...

 Don't forget set type to binary ( bin )

 Jose A. Vela Avila

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 17:10:01 GMT
From:      DUCKY@ACADVM1.UOTTAWA.CA ("Richard V. Janke")
To:        comp.protocols.tcp-ip
Subject:   help WHOIS

HELP
WHOIS

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 17:34:51 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented

In article <WQOCVQA@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
>I don't think there is anything in the PDP-11 hardware that requires 3 4 1 2,
>by the way. It's just a convention.

Look hard at the floating-point conversion instructions:  they know about
that byte order.
-- 
Lightweight protocols?  TCP/IP *is*     | Henry Spencer @ U of Toronto Zoology
lightweight already; just look at OSI.  |  henry@zoo.toronto.edu  utzoo!henry

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 17:34:57 GMT
From:      guy@auspex.auspex.com (Guy Harris)
To:        comp.protocols.tcp-ip,alt.folklore.computers
Subject:   PDP-11 byte order (was Re: htonl() patented)

(No longer has much to do with TCP-IP; forwarded to, and followups to,
"alt.folklore.computers", at least on USENET.  Mailing list people are
on their own....)

>PDP-11s use 3 4 1 2 order for longs. VAXen use 1 2 3 4. So they would just
>have to swap words.
>
>I don't think there is anything in the PDP-11 hardware that requires 3 4 1 2,
>by the way. It's just a convention.

Nope.  As I remember, the PDP-11 floating point processors (the ones
that implement what I call the "floating point instruction set", e.g.
the 11/45's FPP, as opposed to what DEC called the FIS) instructions
that converted between 32-bit integer quantities and floating-point
numbers assumed the floating-point numbers used 3 4 1 2 order.

Now, some of DEC's *software*, such as PDP-11 FORTRANs, used 1 2 3 4
order, as I remember, the fact that the *hardware* used 3 4 1 2 order
nonwithstanding.

On the other hand, I think *other* of DEC's software used 3 4 1 2 order;
there was something in a VMS manual, as I remember, that indicated that
some Files-11 field, either on disk or in a control block, had a 32-bit
integral quantity in 3 4 1 2 order and, as such, required a software
workaround on a VAX. 

Dennis Ritchie's C compiler used 3 4 1 2 order, and so did PDP-11 UNIX
(except, of course, for ports of DEC FORTRAN to UNIX...).

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 17:35:29 GMT
From:      larry@abtlabs.uucp (Larry Pajakowski)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   rumor about NEC Ethernet chip

I'm trying to trace down or put to rest a rumor.

One of our suppliesr of LAN h/w mentioned that he had heard that the
rev. "B" of a NEC ethernet chip was not a good neighbor on a LAN.

I agree that's vague but it came from our sales type.

Can anybody tell me if there is any truth to this or is this guy all wet.
Also if true who uses it?  Most of the workstation vendors, at least, seem
to use the lance chip.  What about PC types?

Thanks for your patience.


Larry Pajakowski
Abbott Labs.
uunet!abtlabs!larry
pajakowskil@randb.abbott.com

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 17:42:57 GMT
From:      jlawton@Stardent.COM (Jennifer Lawton)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet question and hardware wanted.

what's wrong with 2 t's, 2 terminator's and a piece of cable?

much, much, much cheaper than $225.


Jennifer Lawton			Stardent Computer
jlawton@stardent.com		521 Virginia Road
(508)287-0100 x305		Concord, MA 01742

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 18:03:56 GMT
From:      sichermn@beach.csulb.edu (Jeff Sicherman)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Artisoft AE-3 cards


   Does anyone have any experience with or judgement about the new Artisoft
AE-3 ethernet cards which support both coax and twisted pair implementations ?

  Any opinions about the previous generation (AE-2) which would reflect upon
the new ones?

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 20:06:31 GMT
From:      peter@csg.uwaterloo.ca (Peter Bumbulis)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you drop the packet that caused the ARP?

In article <1991Jul17.193237.20342@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <102003@lll-winken.LLNL.GOV> booloo@lll-crg.llnl.gov (Mark Boolootian) writes:
>>Is it inappropriate behaviour for a router to drop a packet if it first must
>>fulfill an arp request before sending that packet (leaving it to upper layers
>>someplace else to resend the original packet)?  Is this discussed in any RFC?
>
>1009, the gateway requirements RFC, is silent about it.  However, 1122, the
>host requirements RFC (part 1) explicitly says "don't do that unless you
>really must":  it messes up performance, e.g. by confusing TCP's initial
>round-trip-time estimate, and can be quite troublesome to UDP applications
>(e.g. name service) that are cautious about retrying.  These sound like
>good arguments against doing it in a gateway/router too.

I'm curious as to why there is a need for an ARP protocol in the first place.
Why couldn't you just maintain an ARP table (mapping IP addresses to ethernet
addresses) as follows:

    When an IP packet is received, if it is not an ethernet broadcast/
    multicast packet and the IP address is a valid host address on the local
    subnet, update the ARP table with this address information.  (If it is
    an ethernet broadcast packet with our host address as the destination,
    send out some sort of ICMP packet just to publish our IP address.)

    When transmitting an IP packet, if we know the ethenet address, use
    it.  Otherwise just use the ethernet broadcast address.

It seems to be that this is (marginally) more efficient in terms of
network traffic than using ARP, and consumes less host/router resources
(i.e. we don't have to keep packets around waiting for ARP replies.)  Is
ARP only needed for compatability reasons, or is there some technical
reason that I've missed?  Thanks,

Peter

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 21:17:38 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: What is Connectathon, Interop, and how do you test interoperability?


    ..... we've noticed that aside from the leading edge hardware and
    software implementations (e.g., fddi last year), there is a very
    load utilization of the shownet's backbone. 

Well, 200 packets per second isn't earth-shaking, particularly when half of
it is SNMP, but I wouldn't have said 'lightly loaded' myself.
				
James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 21:17:39 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP and Novell at the same time.

This is a Frequently-Asked-Question, and here's my standard post on the
subject, recently updated.

There are three ways you can make Netware and TCP/IP usable from the
same PC while using only one network interface card.  Each has advantages
and disadvantages, I sell one, but I'll list them in order of introduction:

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

1. You can modify the IPX module so that it is possible to share the
hardware interface, and use a TCP/IP protocol stack side-by-side with
Netware.  BICC Data networks did this first, initially with PC-IP and
later with our PC/TCP product, but they didn't make their interface
sharing spec public.  Proteon did the same thing, but with a
different, P1300-specific interface and our PC/TCP.  We didn't want to
write drivers for a dozen private interfaces, so John Romkey came up
with the Packet Driver spec (which isn't specific to Netware, but has
been most widely used with it) and published it.  Later, Excelan did
the same thing using a private interface and their ethernet board's
on-board TCP/IP.  Since then, 3Com and Microsoft developed the NDIS
specification, which is functionally similar to the Packet Driver spec
but different in many details.  Although Novell has shown no interest
in supporting it themselves, at least two 3rd parties sell Netware driver
modules for NDIS.  Recently, Novell introduced their own competing
software driver spec, ODI, which can be used in the same way.

Developers who chose the Packet Driver can build it into IPX.COM (Interlan,
Gateway, Schneider & Koch, IMC Networks, Sytek, Univation and others), in
which case users can stick with the normal, illegal, Netware encapsulation
on Ethernet.  As an alternative, one can require the use of legal 'Bluebook'
packets (by using ECONFIG on older Netware, or by a configuration command
in Netware 386), and build an IPX.COM which uses a separate Packet Driver
to do its network I/O (Kelly McDonald's freeware SHELLDRV.OBJ from BYU does
it this way).  A third alternative is to use a dual mode (both Class 1, DIX
Ethernet, and Class 11, 802.3 with 802.2 headers) Packet Driver, and have
Netware use its normal encapsulation through Class 11, while IP uses Class 1.
This is supported by some commercial Packet Drivers as well as Clarkson's
latest release.

Advantages: Faster, no load on the server because the IP traffic goes
direct to the other IP host.  If the interface is Packet Driver and
not NDIS, ODI or proprietary, you can use either commercial or freeware
TCP/IP stacks, as well as the freeware Packet Drivers from Clarkson.  The
exact TCP/IP features you get with this approach vary, depending on
which TCP/IP package you use (FTP Software's PC/TCP, NCSA, PC-IP, KA9Q,
Wollongong's product, Novell's Lan Workplace, Sun's PC-NFS, Beame &
Whiteside's BWNFS or MD-DOS/IP at the moment), but in general, this choice
gives you the widest variety of applications (TN3270, RCP, TFTP etc.)
to choose from.

Disadvantages: The LAN you're connected to has to be one on which
TCP/IP is widely used on (Ethernet, Starlan, ProNET-10, 802.5).  The
PC has to have an IP address, and the software has to be installed on
it.  Needs a separate PC running an FTP server to let hosts at the
Netware server's files, unless the server is Netware 386 and has the
optional TCP/IP support.

NOTE: You get the same effect as if a Packet Driver was in use on
802.5 interfaces which support IBM's ASI software driver spec (TOKREUI
or LAN Support Program).  It is different in structure, but it serves
the same purpose, of letting many protocol stacks use the same card at
the same time.  PC/TCP and IBM's DOS TCP/IP both support 802.5 via
this interface.

NOTE: Banyan VINES has supported this scheme of interface sharing on Ethernet
since v2.10, with a private interface.  3Com 3+/Open and other derivatives
of Microsoft's LAN Manager support the same scheme via NDIS.  10Net/DCA
does so via the Packet Driver spec.

NOTE: Adapter modules are available from various sites on the Internet which
1) allow Netware to use Packet Drivers directly, 2) supply a Packet Driver
interface on top of an NDIS driver, 3) supply a Packet Driver interface on
top of an ODI driver, or 4) supply a simulated Class 1 (DIX Ethernet) Packet
Driver interface on an ASI driver.  I could spend all day explaining the
ramifications, but just consider that most can be layered on one another...
---------------------------------------------------------------------------

2. You can get the Interlan "gateway" product, and install it in your
Netware server.  This is an NP600 intelligent Ethernet card and
software which acts as a high-level translating gateway between IPX
protocols on one side and TCP/IP on the other.  It supports Telnet and
FTP from the workstation, and incoming FTP to the server.  The Telnet
user interface is via a user-supplied terminal emulation program on
the PC.  I am told that it supports 16 connections via a single
server.

Advantages: PC can use any Netware-supported media (Ethernet, Arcnet,
Omninet, etc.) without consideration of whether or not IP is used on
it.  PCs don't have to have IP address (but some software must be
installed on them).  Other TCP/IP hosts can use FTP to connect directly
to the server to access files there.

Disadvantages: Can only use protocols the gateway understands (it can
do normal Telnet, but not 3270-mode Telnet, for instance).  Each
active connection loads the gateway (and the server) some, and this
approach will probably be the slowest of the three even when only one
person is using it.

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

3. Wollongong has a version of their product (used to be called WIN/PC)
which uses NETBIOS datagrams to transport either IP packets only, or any
kind of Ethernet packet over Netware.  They have published RFCs describing
each protocol, but I don't know of anyone else who has yet implemented it.
There have also been academic developments which I understand used different
mechanisms to do roughly the same thing.  Either requires a separate,
(possibly dedicated) router to forward the IP packets onto an Ethernet
or other TCP/IP media.  Wollongong supplies a PC-based router which
accomplishes this as a background process on a non-dedicated machine.

Advantages: Can run any TCP/IP application which supports the interface,
doesn't care what media the PC is using.  The Netware server is not loaded.

Disadvantages: Must install software on individual PCs.  A router is
required, which may be a throughput bottleneck.  Needs a separate PC
running an FTP server to let hosts at the Netware server's files.

---------------------------------------------------------------------------
So, there it is, as I understand it, today, July 15, 1991.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 21:36:29 GMT
From:      brunner@NAPA.TELEBIT.COM ("Consultant, Netblazer Testing")
To:        comp.protocols.tcp-ip
Subject:   Re: What is Connectathon, Interop, and how do you test interoperability?

James,
    ..... we've noticed that aside from the leading edge hardware and
    software implementations (e.g., fddi last year), there is a very
    load utilization of the shownet's backbone. 

Thanks, it looks as if I dropped the word "low" while composing that note.

Eric

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 21:53:07 GMT
From:      brunner@telebit.com (Eric Brunner)
To:        comp.protocols.tcp-ip
Subject:   Re: What is Connectathon, Interop, and how do you test interoperability?

>I've also heard that the same folk who put on Interop, are attempting to set up
>a lab to test vendors products for interoperability.

This comes as news to me, perhaps you mean one or the other of the following:

	1. use of the ANTC by technology demo groups, such as the fddi demo
	   group,

	2. hot staging by us (the shownet crew) in August/September in a
	   wherehouse in San Jose of most of the show-critical gear,

Eric
-- 
Eric Brunner
Tule Network Services - 4bsd/rt project

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 22:36:57 GMT
From:      rwwerlwas@ORION.ARC.NASA.GOV ("Robert W. Werlwas")
To:        comp.protocols.tcp-ip
Subject:   TCP/IP bulletin board

Please remove me from the subject bulletin board.
R. Werlwas
rwwerlwas@orion.arc.nasa.gov

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 22:54:03 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you drop the packet that caused the ARP?

In article <1991Jul18.200631.3385@maytag.waterloo.edu> peter@csg.uwaterloo.ca (Peter Bumbulis) writes:
>I'm curious as to why there is a need for an ARP protocol in the first place.
>Why couldn't you just maintain an ARP table (mapping IP addresses to ethernet
>addresses) as follows:
>
>    When an IP packet is received, if it is not an ethernet broadcast/
>    multicast packet and the IP address is a valid host address on the local
>    subnet, update the ARP table with this address information.  (If it is
>    an ethernet broadcast packet with our host address as the destination,
>    send out some sort of ICMP packet just to publish our IP address.)
>
>    When transmitting an IP packet, if we know the ethenet address, use
>    it.  Otherwise just use the ethernet broadcast address.

The IP destination address is the address of the ultimate destination,
not necessarily that of the next hop.  This scheme would make it
difficult to control routing, you would have to either broadcast
all gateway-bound traffic, which is unreasonable, or have the gateway
"proxy-ICMP" for any traffic that it knows how to deliver, thus moving
the routing function from the host to the gateway.  This would increase
the load on the gateway, and also make it harder to recover from gateway
failures.

Also, the IP packets you are broadcasting can potentially be much larger
than ARP packets, so may consume significant buffer resources in
uninterested hosts.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 23:10:17 GMT
From:      jsanchez@polari.UUCP (jim sanchez)
To:        comp.protocols.tcp-ip
Subject:   Looking for SNMP Mgmt package

As a favor to a customer of mine at a school district, I am trying to find
a PC based package that will allow him to do some simple SNMP management.  He
needs to gather some variables from some agents and keep track of the values.
The agents use MIB_II with enterprise extensions but the MIB is avaiable.
If anyone can point me to a ftp site, I will appreciate it.
Thanks

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 23:15:12 GMT
From:      hchen@BIGBIRD.CSD.SCAROLINA.EDU (Hong Chen)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe

unsubscribe me, thank you!!!!

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      18 Jul 91 23:30:21 GMT
From:      peter@ficc.ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented

In article <1991Jul18.103915.16889@jarvis.csri.toronto.edu> thomson@hub.toronto.edu (Brian Thomson) writes:
> In article <WQOCVQA@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
> >PDP-11s use 3 4 1 2 order for longs. VAXen use 1 2 3 4. So they would just
> >have to swap words.
 
> >I don't think there is anything in the PDP-11 hardware that requires 3 4 1 2,
> >by the way. It's just a convention.
 
> If I am not misremembering, the PDP11 hardware floating point units had some
> instructions that used 32 bit integers, and these dictated the byte order.

Yes, I had forgotten the various Floating Instruction Sets.

Of course, given that FIS were extensions, that begs the question of whether
the convention or the implementation came first.

Also, I was reminded of FIS by someone in Email, who also noted that the
Commercial Instruction Set used the opposite word order for long words.

Obviously the right hand knoweth not what the left hand doeth. It's odd that
the beancounters got it right and the engineering types wrong. It's usually
the other way around.
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 91 00:09:07 GMT
From:      swansonc@acc.stolaf.edu (Chris Swanson)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   TCP-IP terminal server software for PC's


Greetings,

	I am looking for sources or binaries that will turn a garden
variety PC/PC clone into a TCP/IP terminal server.  I know that there
is at least one company turns out a commercial product (Datability, I
think), but I am looking for a cheaper solution (PD, ShareWare,
CopyLeft variety, etc.).  If you know of such a beast, I would love a
pointer to it.

	Please reply via e-mail, as I do not read the majority of
these groups.

	Regards,
	-=Chris


--
 Chris Swanson, C.U. CS/Pre-med Student, 1502 N. 59 st., Omaha, NE  68104-4830
 DDN: [CDS6]   INTERNET:  swansonc@acc.stolaf.edu  UUCP: uunet!stolaf!swansonc
  AT&T:	    Work: (402)-449-4894       Home: (402)-551-7393 or (402)-551-0766
	I would deny this reality, but that wouldn't pay the bills...

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 91 00:50:19 GMT
From:      swansonc@acc.stolaf.edu (Chris Swanson)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP documentation wanted


Greetings,

	I am looking for pointers to any documentation available on
the net that describes the TCP-IP protocol including framing,
addressing, etc.  I am also looking for doc's on the basic TCP-IP
services like telnet, ftp, tftp, etc. as well as NFS (if possible).

	Regards,
	-=Chris

P.S.  Please respond via e-mail


--
 Chris Swanson, C.U. CS/Pre-med Student, 1502 N. 59 st., Omaha, NE  68104-4830
 DDN: [CDS6]   INTERNET:  swansonc@acc.stolaf.edu  UUCP: uunet!stolaf!swansonc
  AT&T:	    Work: (402)-449-4894       Home: (402)-551-7393 or (402)-551-0766
	I would deny this reality, but that wouldn't pay the bills...

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 91 01:30:36 GMT
From:      anderson@macc.wisc.edu (Jess Anderson)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: TCP-IP terminal server software for PC's


In article <SWANSONC.91Jul18190907@grendel3.acc.stolaf.edu>
swansonc@acc.stolaf.edu (Chris Swanson) writes:

>	I am looking for sources or binaries that will turn a garden
>variety PC/PC clone into a TCP/IP terminal server.  I know that there
>is at least one company turns out a commercial product (Datability, I
>think), but I am looking for a cheaper solution (PD, ShareWare,
>CopyLeft variety, etc.).  If you know of such a beast, I would love a
>pointer to it.
 
>	Please reply via e-mail, as I do not read the majority of
>these groups.

But please post as well, if you know about this; I'm interested
in the topic too.

-- 
Jess Anderson <> Madison Academic Computing Center <> University of Wisconsin
Internet: anderson@macc.wisc.edu <-best, UUCP:{}!uwvax!macc.wisc.edu!anderson
NeXTmail w/attachments: anderson@yak.macc.wisc.edu  Bitnet: anderson@wiscmacc
Room 3130 <> 1210 West Dayton Street / Madison WI 53706 <> Phone 608/262-5888

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 91 01:48:26 GMT
From:      bret@orac.UUCP (Bret Indrelee)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented



Would it be good enough to dig up some of the early Internet and ARPAnet
documents.  I remember an artical (think it was in Byte) that was an
interview of the people who designed Ethernet.  Ethernet uses network
byte order for the head -- ethernet address.  I would think that some
of the early documentation for it would mention big and little endian,
in the context that it didn't matter which order was used for the
ethernet address just as long as all machines agreed on the byte order.

If nothing else, I think that you could build a case for this not
being unique -- it is obvious to anyone who has ever worked on more
than one machine.  The early networking documents had to solve this
for the protocol, but did not consider this a noteworthy event.

Mainly because it isn't.

-Bret
-- 
------------------------------------------------------------------------------
Bret Indrelee		|	Our mail is still somewhat unreliable.  Sorry.
uunet.uu.net!cs.umn.edu!kksys!edgar!orac!bret		-And still trying

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 91 02:54:35 GMT
From:      kory@avatar.com (Kory Hamzeh)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Router Questions


I have a couple of questions regarding the operation of TCP/IP routers:

	1.	If a Network Management Stations adds a new route or
		modifies an existing route in a router, should this be
		considered a Static route? If so, it should not be aged?

	2.	If a Network Management Station adds a route, and the router 
		learns a route dynamicly (through RIP for example) which
		contradicts or has a different metric than the route
		set by NMS, which one should the router accept?

	3.	If the router has a filter table entry which will block
		packets to a certain network, what should it do if it
		receives a packet destined for that network? Simply
		discard the packet? Send an ICMP destination unrechable?
		Send an ICMP redirect? Note that a filter table is different
		than a routing table.

	4.	Under MIB II, a route can be set to INVALID, does this
		mean that this entry should be deleted from the routing
		table, or just stop routing to that network?

Any help would be greatly appreciated.

Thanks,
Kory


-- 
-------------------------------------------------------------------------------
Kory Hamzeh             UUCP: avatar!kory or ..!uunet!avatar!kory
                    INTERNET: kory@avatar.com 

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 91 02:55:08 GMT
From:      G.Eustace@massey.ac.nz (Glen Eustace)
To:        comp.protocols.tcp-ip,comp.unix.misc,comp.periphs.printers
Subject:   Distributed Printing - A protocol ? An implementation ?

I am hoping someone has already found a solution to this problem, but
if no one has perhaps some of you have opinions that might lead to a
solution.

Distributed Network Printing.
-----------------------------

Most of our printers are connected to a Pyramid 9815 which is in
effect working as a IO server providing disk, printers etc.  We have
Sun, HP and DEC workstations which want to use the printers connected
to the Pyramid.

We tried using the 'remote' option in the printcap files but found
that multiple jobs came through as a continuous stream of characters
and we couldn't tell who they belonged to.  We want to be able to use
the spooling mechanism to queue jobs on the local machine but most
processing ( filters etc. ) and in particular accounting must be done
on the Pyramid.

We have implemented the above by having 'of=' a filter that is simply
'rsh remotehost lpr -Plp7'.  The local system has no banner etc etc
and because of the rsh the remote machine knows whose job it is.
This scheme means that all workstation users must have an account on
the Pyramid.  The problem is that I don't want to have each
workstation in hosts.equiv, nor do I want users to have to put
entries in their '.rhosts' file.  Being very blunt about it, I do not
want users being able to 'rsh' to the Pyramid.  It is not intended
for running users programs but with rsh the users do just that.

I want a protocol or implementation that will permit dissimiliar
spooling systems, SysV, BSD and EaseSpool to transfer jobs between
each other in a secure way.  Information about the user etc must
accompany the data and the user need not exist on the machine that
actually has the printer attached.

All of the spooling mechanisms we use permit output filters so a
program which could fit in as a filter and then talk to a daemon on
the printer server would be the sort of thing we would like to do.

If you have done something like this please let me know.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Glen Eustace, Systems Software Manager | EMail: G.Eustace@massey.ac.nz
 Computer Centre,  Massey University,  Palmerston North,  New Zealand
Phone: +64 6 356 9099 x7440, Fax: +64 6 350 5607,     Timezone: GMT-12

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 91 09:01:52 GMT
From:      garyo@apricot.co.uk (Gary Osborne)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP and Novell at the same time.

hz01930@hx.deere.com (jay d. anderson) writes:

>What ethernet cards are capable of handling both TCP-IP and IPX packets at
>the same time.  Our specific need is to run AttachMate for 3270 access to
>mainframes while using PC-NFS to handle file serving from assorted Unix and
>VMS boxes.

Try Western Digital who are able to link their Netware workstation driver 
with their Packet Driver (in a non-standard way) so you can put Netware 
together with (say) FTP's TCP/IP stuff in the same machine.

We've done something along the same lines for our ethernet, but our ethernet
hardware exists as an integral part of our motherboards so it's probably
of little use to you unless you have some of our kit. 

An alternative is to use 3Com's NDIS/IPX converter (I don't know the product's
real name). This enables you to run IPX with anything-else on top of an NDIS.
This is what I use (I have 3Com's NBP [LAN Manager] + IPX + TCP/IP which I
demand load). 

You can get a public domain NFS-NDIS converter from some BBSs and from SUN
and there's a newer version of it in retail PCNFS version 3.5 currently on  
release.  

Hope this is of use.

=============================================================================
Gary Osborne						garyo@apricot
Apricot Computers Limited
Birmingham, UK
============================================================================= 

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 91 11:10:12 GMT
From:      jtw@lcs.mit.edu (John Wroclawski)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented


In article <zweig.679945869@osric> zweig@parc.xerox.com (Jonathan M. Zweig) writes:

   Having a network standard byte order is not what is claimed in the patent --
   you can only patent doing things for a reason.  What is probably being
   patented is using it to allow computers with different byte orders to
   talk to each other.


Richard Stallman was kind enough to send this to me as part of a
discussion about possible documented prior art.

The claims of patent 4,956,809 (Mark Williams Company, issued Sep 11, 1990,
perhaps goes back to application in 1982):

1.  A method for use with a portable operating system used on
different computers which use different binary structures, whereby
files containing binary data become portable, comprising the steps of:

By means of a computer, representing in a standardized order
consisting of a standard binary structure file stored on auxiliary
memory or transported on a communications means, said standardized
order being different from a different order used on at least one
of the different computers;

Converting in each of the different computers binary data read from an
auxiliary data storage or communications means from the standardized
order to the natural order of the respective host computer after said
binary data are read from said auxiliary data storage or
communications means and before said binary data are used by the
respective host computer; and

Converting in each of the different computers binary data written into
auxiliary data storage or communications means from the natural order
of the respective host computer to the standardized order prior to
said writing.

2.  A method according to claim 1 wherein the said operating system
comprises a unix-like operating system.

3.  A method according to claim 1 wherein said file comprises a file
system and some or all of said binary data is converted.

4.  A method according to claim 1, wherein said file comprises an
object file expressed in binary.

5.  A method for use on different computers which use different binary
structures, whereby files containing binary data become portable
between the computers, comprising the steps of:

Representing by means of a computer files that are stored for use by
one or more of the computers or are transported on a communications
means to one or more of the computers, in a predetermined binary
structure different than the binary structure used on at least one
of the different computers;

Converting in each of the computers binary data, to be stored for use
by one or more of the computers or to be transported on said
communications means to one or more of the computers, from the binary
structure of the originating computer, to the predetermined binary
structure; and

Converting in each of the computers binary data obtained from said
stored files or from said communications means from the predetermined
binary structure to the binary structure used by said computer.

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 91 14:43:34 GMT
From:      lms@SSDS.SSDS.COM (L. Michael Sabo)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for SNMP Mgmt package

The two public domain SNMP manager implementations are:

1) Carnegie-Mellon University (CMU) written by Steve Waldbusser and available 
from lancaster.andrew.cmu.edu

2) Massachusetts Institute of Technology (MIT) written by Chuck Davin and 
available from allspice.lcs.mit.edu

L. Michael Sabo
lms@ssds.com

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 91 17:51:09 GMT
From:      zweig@parc.xerox.com (Jonathan M. Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented

Having a network standard byte order is not what is claimed in the patent --
you can only patent doing things for a reason.  What is probably being
patented is using it to allow computers with different byte orders to talk to
each other.  Although this is implicit in RFC791's Appendices, I don't think
those documents explicitly state that the reason for using a network standard
byte ordering is to facilitate interoperation.  It's a fine hair to split, but
one which the lawyers are probably nibbling on.

By the way, I just read Rob Pike's patent 4,555,775 (I think that was it),
which is the one I have heard called "the backing store patent" -- actually,
it patents the idea of having N processes sending output to N windows
simultaneously, with screen updates taking place pseudo-concurrently.  He
cites Smalltalk-80 as an example of prior art for windowing systems, and that
it doesn't allow multiple processes to simultaneously update their windows.
It was filed in 1982, issued in 1985, so any prior art challenge would
probably have to come from the late '70's.  Has emacs been doing stuff like
that for that long?  I would assert that taking simultaneously-updated ASCII
windows on a vt100 and looking at Smalltalk-80 and coming up with Pike's
patent would be an obvious incremental enhancement.  Coming up with the idea
from scratch seems more patentable to me....

-Johnny ByteOrder

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 91 19:38:56 GMT
From:      chk@alias.com (C. Harald Koch)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you drop the packet that caused the ARP?

In <1991Jul17.193237.20342@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:

>1009, the gateway requirements RFC, is silent about it.  However, 1122, the
>host requirements RFC (part 1) explicitly says "don't do that unless you
>really must":  it messes up performance, e.g. by confusing TCP's initial
>round-trip-time estimate, and can be quite troublesome to UDP applications
>(e.g. name service) that are cautious about retrying.  These sound like
>good arguments against doing it in a gateway/router too.

It also shows up as an unacceptable delay when performing a telnet, rsh,
ftp, etc. to a host on the other side of a router. We have some routers that
appear to drop the packet, and the difference in startup speed for TCP
sessions is a continual annoyance at the user level.

--
C. Harald Koch  VE3TLA                Alias Research, Inc., Toronto ON Canada
Internet:    chk@alias.com      chk@gpu.utcs.toronto.edu      chk@chk.mef.org
"I think you curdled my Pepsi!"-Gerry Smit, in response to sickening cuteness

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 91 20:22:02 GMT
From:      tannenba@engr.wisc.edu (Todd Tannenbaum)
To:        comp.periphs.printers,comp.protocols.tcp-ip,comp.unix.misc
Subject:   Re: Distributed Printing - A protocol ? An implementation ?

In article <1991Jul19.025508.19448@massey.ac.nz> G.Eustace@massey.ac.nz (Glen Eustace) writes:
>I am hoping someone has already found a solution to this problem, but
>if no one has perhaps some of you have opinions that might lead to a
>solution.
>  [...stuff removed...]
>and we couldn't tell who they belonged to.  We want to be able to use
>the spooling mechanism to queue jobs on the local machine but most
>processing ( filters etc. ) and in particular accounting must be done
>on the Pyramid.
>
>We have implemented the above by having 'of=' a filter that is simply
>'rsh remotehost lpr -Plp7'.  The local system has no banner etc etc
>and because of the rsh the remote machine knows whose job it is.
>This scheme means that all workstation users must have an account on
>the Pyramid.  The problem is that I don't want to have each
>workstation in hosts.equiv, nor do I want users to have to put
>entries in their '.rhosts' file.  Being very blunt about it, I do not
>want users being able to 'rsh' to the Pyramid.  It is not intended
>for running users programs but with rsh the users do just that.
>

I know this is not exactly what you are looking for, but it may help
a little (at least with your filtering problem).

We also encountered the "filter" problem, which is that the BSD lpd
program only applies filters ("of=" and "if=") when the destination
printer is locally attached.  Filters are NOT applied & are completely
ignored if you are sending the job along to a remote machine (using 
"rm=" and "rp=" in you printcap file).

Thus, we hacked the BSD lpd program so that it ALWAYS applies filters,
no matter if the job is destined for a local printer or a remote machine.
The source code and a compiled binary (compiled for sun sparcs sunos 4.1.1)
is available via anonymous ftp to doug.cae.wisc.edu under the file
pub/sunsparcs/lpd.hacked.tar.Z.  Read the README file in the tar.  It
should compile without much trouble on any BSD-ish Unix.

-- 
Todd Tannenbaum, Network Manager   | e-mail: tannenba@engr.wisc.edu
Computer Aided Engineering Center  | Voice Ph: (608) 262-3118
University of Wisconsin-Madison    | Fax Ph: (608) 262-6707

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 91 20:28:17 GMT
From:      lancelot@mais.hydro.qc.ca (Christian Doucet)
To:        comp.protocols.tcp-ip
Subject:   AS/400 on IP?


Does anybody knows about a product that could network an AS/400 in IP
over Token Ring?

Thanks


--
Christian Doucet    (aka. Sir Lancelot)             | Hydro-Quebec
Administrateur de systeme                           | 140 Cremazie Ouest, 3e
Traitement des Donnees de Surveillance des Barrages | tel: (514) 385-7701
{This space for rent}                               | lancelot@mais.hydro.qc.ca

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 91 21:35:27 GMT
From:      coates@UC780.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: What is Connectathon, Interop, and how do you test interoperability?

I just remember an article in LAN TIMES from about a year ago. There was an interview of one of the Interop group founders, he mentioned there that they palnned to set up a lab. Sorry can't find the rag er mag:-) right now.

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      19 Jul 91 21:41:50 GMT
From:      netmanage@cup.portal.com (William - Dunn)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP-IP and Novell at the same time.

Jay D. Anderson  writes:
>Sorry if this has been asked before; I imagine it has..
>
>What ethernet cards are capable of handling both TCP-IP and IPX packets at
>the same time.  Our specific need is to run AttachMate for 3270 access to
>mainframes while using PC-NFS to handle file serving from assorted Unix and
>VMS boxes.
>
>Thanks for any input.
>
	There are several board interfaces that support multiple protocols
simultaniously.  NDIS was developed jointely by 3Com and Microsoft
and is getting a very popular in many new products. ODI was developed
by Novell and has not gained a great popularity either among other
network software vendors or among the board manufacturers.  Both these
specifications allow running of multiple protocol stacks on the same
board at the same time.
	Netmanage has a product that will allow IPX to run on top of
NDIS interface.  We also supply a TCP/IP stack (NEWT) that can run at 
the same time as IPX on the same board.  Our TCP/IP package does not 
run in DOS it is a MS Windows DLL but it has the NDIS interface to the
board.

Boris Yanovsky
netmanage@cup.portal.com
(408)257-6404

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 91 00:37:52 GMT
From:      nisc@NISC.SRI.COM (SRI NISC)
To:        comp.protocols.tcp-ip
Subject:   Domain Survey Results

Network Information Systems Center                                July 1991
SRI International                                             Domain Survey

                  ZONE (Zealot Of Name Edification) Results
                
                Hosts:                  535,000  [minimum]
                Domains:                16,000   [approximately]
                Survey elapsed time:    7 days
                Survey cpu time:        10 hours
                Host table generated:   42 megabytes

                  Number of IP Addresses per Host
                Addresses               Hosts
                    1                   525684
                    2                   7315
                    3                   918
                    4                   481
                    5                   227

                 Top 30 Most Popular Top-Level Domains
                205648 edu      9290 fr         1559 dk
                143868 com      8761 fi         1193 nz
                 35569 gov      8264 no          979 es
                 25536 mil      7382 nl          800 kr
                 21774 au       6990 uk          501 us
                 21109 de       6657 jp          343 be
                 18582 ca       2148 at          220 mx
                 14747 org      1948 net         216 gr
                 11800 se       1656 it          194 is
                  9918 ch       1610 il          111 br

                       Top 50 Most Popular Host Names
 306 venus       205 mac2        166 mac3       151 fred        140 pc3
 288 pluto       203 orion       165 eagle      149 apollo      137 mac7
 277 mars        201 mac1        161 thor       148 grumpy      137 mac10
 229 jupiter     189 gauss       161 cisco      146 mac5        137 earth
 225 cs          187 newton      158 opus       146 hal         136 sol
 223 iris        183 neptune     158 merlin     143 phoenix     134 gandalf
 216 saturn      178 hobbes      158 calvin     143 athena      133 io
 216 pc1         175 pc2         157 titan      142 mac6        132 alpha
 213 zeus        174 gw          157 mac4       141 mozart      131 mac9
 207 mercury     167 sirius      156 hermes     140 snoopy      131 mac8

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 91 03:35:22 GMT
From:      dan@gacvx2.gac.edu
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: TCP-IP terminal server software for PC's

In article <SWANSONC.91Jul18190907@grendel3.acc.stolaf.edu>, swansonc@acc.stolaf.edu (Chris Swanson) writes:
> 
> Greetings,
> 
> 	I am looking for sources or binaries that will turn a garden
> variety PC/PC clone into a TCP/IP terminal server.  I know that there
> is at least one company turns out a commercial product (Datability, I
> think), but I am looking for a cheaper solution (PD, ShareWare,
> CopyLeft variety, etc.).  If you know of such a beast, I would love a
> pointer to it.
> 
> 	Please reply via e-mail, as I do not read the majority of
> these groups.
> 
> 	Regards,
> 	-=Chris
> 
> 
> --
>  Chris Swanson, C.U. CS/Pre-med Student, 1502 N. 59 st., Omaha, NE  68104-4830
>  DDN: [CDS6]   INTERNET:  swansonc@acc.stolaf.edu  UUCP: uunet!stolaf!swansonc
>   AT&T:	    Work: (402)-449-4894       Home: (402)-551-7393 or (402)-551-0766
> 	I would deny this reality, but that wouldn't pay the bills...

I know of no public domain terminal server with multiple ports.  However in the
U of W DOS/IP package, and I think other versions of the U of Maryland DOS/IP,
there is a special version of telnet that uses a serial port rather than a
screen for user input and output.  One of our physics profs liked this feature
since it let him hook his HP48 to the network and do kermit file transfers (the
HP48 knows kermit.)

-- 
Dan Boehlke                    Internet:  dan@gac.edu
Campus Network Manager         BITNET:    dan@gacvax1.bitnet
Gustavus Adolphus College
St. Peter, MN 56082 USA        Phone:     (507)933-7596

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 91 06:00:02 GMT
From:      dan@gacvx2.gac.edu
To:        comp.protocols.tcp-ip
Subject:   Re: AS/400 on IP?

In article <lancelot.679955297@tdsb-s>, lancelot@mais.hydro.qc.ca (Christian Doucet) writes:
> 
> Does anybody knows about a product that could network an AS/400 in IP
> over Token Ring?
> 
> Thanks
> 
> 
> --
> Christian Doucet    (aka. Sir Lancelot)             | Hydro-Quebec
> Administrateur de systeme                           | 140 Cremazie Ouest, 3e
> Traitement des Donnees de Surveillance des Barrages | tel: (514) 385-7701
> {This space for rent}                               | lancelot@mais.hydro.qc.ca

IBM has a TCP/IP product for the AS/400.  It works with token ring.  I believe
that some vendors are selling an ethernet board for the AS/400 as well.  IBM
also sells a token ring to ethernet bridge.

-- 
Dan Boehlke                    Internet:  dan@gac.edu
Campus Network Manager         BITNET:    dan@gacvax1.bitnet
Gustavus Adolphus College
St. Peter, MN 56082 USA        Phone:     (507)933-7596

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 91 10:38:49 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Re: TCP-IP terminal server software for PC's

In article <SWANSONC.91Jul18190907@grendel3.acc.stolaf.edu> swansonc@acc.stolaf.edu (Chris Swanson) writes:

   	I am looking for sources or binaries that will turn a garden
   variety PC/PC clone into a TCP/IP terminal server.

Hmmm...  I'll bet that you could put together a pretty good one by marrying
KA9Q with a Fossil driver.  Fossil is a specification for supporting serial
ports.  I'm pretty sure that you can get Fossil drivers for multiport serial
boards...

--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      20 Jul 91 13:36:20 GMT
From:      black@beno.CSS.GOV (Mike Black)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented

In article <JTW.91Jul19131012@mercury.lcs.mit.edu> jtw@lcs.mit.edu (John Wroclawski) writes:
>Richard Stallman was kind enough to send this to me as part of a
>discussion about possible documented prior art.
>
>The claims of patent 4,956,809 (Mark Williams Company, issued Sep 11, 1990,
>perhaps goes back to application in 1982):
>
>1.  A method for use with a portable operating system used on
>different computers which use different binary structures, whereby
>files containing binary data become portable, comprising the steps of:
>

After reading this the thought immediately crossed my mind, "Gee, if
I want to transfer data from one format on one machine to another
format on a different machine I'll have to convert it".  This patent
is so obvious it's ridiculous.  The idea of binary portability has
been around for decades and this patent does nothing more than say it
would be nice if it were automatic!  I'm assuming of course that the
patent doesn't actually describe a method for doing this.
The extension of a standard format from byte to word to record to file
is a logical extension of any format.  That's why there are IEEE
formats and such.  However, with few exceptions, there is no "binary
file format" that could be generically applied to ALL files without
severely compromising the speed/size advantage of binary files.
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!:
-------------------------------------------------------------------------------

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 91 00:27:06 GMT
From:      yeh@NETIX.COM (Shannon Yeh)
To:        comp.protocols.tcp-ip
Subject:   policy issue


While the Internet cloud is becoming larger and larger, some policies about
the appropriate use of Internet stay murky.  Take the "for research
purpose only" for example, how about marketing research (survey)--it is a
scientific thing, too.  (well, it depends. if it is for government, ok...)  
Although the traffic issue is a key concern for the entire infrastructure, 
people judge each other by the contents of their messages; many service 
providers do not charge their users by traffic, either.  

Some people are engaged on the government contracts.  Sometimes, some of them
(very few) can use their governmental title as the police stick.  But, nobody 
can propose the appropriate use of the police stick--even someone can, LAPD
stays as well as before...  (I am not going to complain anything but try to 
describe the reality.)

So, instead of fingering each other inside the community, can we start
the discussion of "how to make "inappropriate" use legal?"  I am sure 
many people had this kind of discussion before, and our community leaders are
worrying this for us, but the participation of the majority net users is 
important.  I would like to work as a volunteer to coordinate the early 
discussions.  If you are interested in the topic, please drop me a note at 
"yeh@netix.com".  We start from there.

shannon
-------

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 91 01:12:17 GMT
From:      peter@ficc.ferranti.com (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented

In article <zweig.679945869@osric> zweig.PARC@Xerox.com writes:
> By the way, I just read Rob Pike's patent 4,555,775 (I think that was it),
> which is the one I have heard called "the backing store patent" -- actually,
> it patents the idea of having N processes sending output to N windows
> simultaneously, with screen updates taking place pseudo-concurrently.  He
> cites Smalltalk-80 as an example of prior art for windowing systems, and that
> it doesn't allow multiple processes to simultaneously update their windows.

Well, it's been nearly 10 years now, but I remember Interlisp-D doing something
like that on the Xerox 1100 at NCC '82, even if SmallTalk on the same hardware
didn't. I also played around with the Xerox Star, and I want to say that it
supported that capability. Certainly it'd do things like update your mail
folder icon to tell you you had mail waiting while you were working on a
document in a window.
-- 
Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180;
Sugar Land, TX  77487-5012;         `-_-' "Have you hugged your wolf, today?"

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 91 04:21:44 GMT
From:      adesai@na.excelan.com (Arun Desai)
To:        comp.protocols.tcp-ip
Subject:   NSF Net??


Does anybody know about NSFNet? Does NSFNet support ISO routing? 

Thank you,
Arun

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Arun Desai (@ Novell Inc., 2180 Fortune Dr. San Jose, CA-95131)
  Phone	   : 408/473-8517
  FAX	   : 408/433-9827
  Internet : adesai@novell.com
  UUCP     : {ames,sun,apple,amdahl,mtxinu,cae780}!excelan!adesai
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 91 14:31:50 GMT
From:      willis@cs.tamu.edu (Willis Marti)
To:        comp.protocols.tcp-ip
Subject:   Re:  policy issue

Shannon,

  I read a lot of discussion about appropriate use & modifications to
current policy; I'm not sure there's a need for yet another start of
discussion.
  And given your recent background, I believe your motives are suspect.
{re:
So, instead of fingering each other inside the community, can we start
the discussion of "how to make "inappropriate" use legal?"  I am sure
many people had this kind of discussion before, and our community leaders are
worrying this for us, but the participation of the majority net users is
important.  I would like to work as a volunteer to coordinate the early
discussions.  If you are interested in the topic, please drop me a note at
"yeh@netix.com".  We start from there.

shannon
}

While I support commercial entities on the Internet, doing (some) commercial
things, I *don't* want to encourage junk email -- unsolicited product
announcements.
Several vendors have mailing lists that you can request to join to keep up
with things.  Or read the appropriate announcement group(s) in NetNews.

If you other, specific, suggested modifications to appropriate use policies,
why don't you post/email to the com-priv list?

Willis Marti

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 91 15:55:04 GMT
From:      ji@cs.columbia.edu (John Ioannidis)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you drop the packet that caused the ARP?

In article <1991Jul18.200631.3385@maytag.waterloo.edu> peter@csg.uwaterloo.ca (Peter Bumbulis) writes:
>I'm curious as to why there is a need for an ARP protocol in the first place.
>Why couldn't you just maintain an ARP table (mapping IP addresses to ethernet
>addresses) as follows:
>
>    When an IP packet is received, if it is not an ethernet broadcast/
>    multicast packet and the IP address is a valid host address on the local
>    subnet, update the ARP table with this address information.  (If it is

Your software will never see it. Remember that your ethernet board
only hands you packets destined for your unicast, your broadcast, or
one of your multicast addresses. Unless you keep the equivalent of
your ARP table in hardware, you can't derive other machines' hardware
addresses from previous traffic. Of course, you can put your interface
in promiscuous mode, but then you end up being interrupted for *every*
packet on the net. Not a very efficient solution. 

>    an ethernet broadcast packet with our host address as the destination,
>    send out some sort of ICMP packet just to publish our IP address.)
>

ICMP is the wrong vehicle for this problem; besides, you would just be
replacing one kind of broadcast (ARP request), with another (the
broadcast of your address)

>    When transmitting an IP packet, if we know the ethenet address, use
>    it.  Otherwise just use the ethernet broadcast address.
>

And send out a broadcast packet that is certainly larger than the ARP
broadcast! Besides, if you have to wait for a reply from the host you
are trying to send to before you can update your ARP table, you may
end up spewing out A LOT of packets before the reply makes it back to
you, assuming you are even asking for a reply. 

/ji

In-Real-Life: John "Heldenprogrammer" Ioannidis
E-Mail-To: ji@cs.columbia.edu
V-Mail-To: +1 212 854 8120
P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 91 16:59:27 GMT
From:      AKayser@dnpap.et.tudelft.nl (Alfred Kayser)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for SNMP Mgmt package

lms@SSDS.SSDS.COM (L. Michael Sabo) writes:
>The two public domain SNMP manager implementations are:
 MAKE THAT THREE!!!
>1) Carnegie-Mellon University (CMU) written by Steve Waldbusser and available 
>from lancaster.andrew.cmu.edu
 
>2) Massachusetts Institute of Technology (MIT) written by Chuck Davin and 
>available from allspice.lcs.mit.edu

3) CARDIT (Computer Architecture and Digital Technique) at the Technical
University of Delft has written a Scheme based SNMP manager. Authors are:
J.P.M. van Oorschot, D. Wisse and A. Kayser.
Availalble from dutepp0.et.tudelft.nl.

>L. Michael Sabo
>lms@ssds.com
--
-- Ir. Alfred Kayser. PACS, OS/2, TCP/IP. --- Email: AKayser@et.tudelft.nl --
-- CARDIT, Delft University of Technology ------------ Tel: (31)-15-786179 --
-- P.O.Box 5031, 2600 GA Delft, The Netherlands ------ Fax: (31)-15-784898 --

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      21 Jul 91 22:03:19 GMT
From:      ggw@wolves.uucp (Gregory G. Woodbury)
To:        comp.protocols.tcp-ip,comp.org.eff.talk
Subject:   Re: htonl() patented - INFO PLEASE!

In rehmi@MILK.FTP.COM (rehmi post) writes:
>this is ludicrous. see IEN 137, _On Holy Wars and a Plea for Peace_, by
>Danny Cohen, 1 April 1980.
>
>From: rms@gnu.ai.mit.edu (Richard Stallman)
>Subject: Patent on a standard-byte order for intermachine communication
>
>US patent number 4,956,809 covers using a single standard byte
>ordering for transfer of data between machines whose normal byte
>ordering is different.
>
	:
>
>This is exactly what is covered by US patent 4,956,809.

	Somebody please tell us who filed for and got this patent?  It
might help if public outcry was directed at the stupid technology
marketing manager at that company responsible for the attempt.
-- 
Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC
UUCP: ...dukcds!wolves!ggw   ...duke!wolves!ggw           [use the maps!]
Domain: ggw@cds.duke.edu     ggw%wolves@duke.cs.duke.edu
[The line eater is a boojum snark! ]           <standard disclaimers apply>

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 91 01:17:58 GMT
From:      chrisv@CMC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   DEC FDDI throughput

Good morning everyone,
I was hoping that DEC's recent announcements and product rollouts of their FDDI
wares would mean that an independent third party might have some visibility
into throughput on the various platforms? I was hoping to get a rough idea of
memory to memory transfer rates between their workstation adapters and the
larger machines. As those of us involved with FDDI find our ranks swelling it
becomes more and more difficult to keep up on how fast the bits are starting
to flow(or blink in this case (:*) ). Please respond to me directly if you've
taken a look at these products or any others that you would care to discuss.
It might even finally be a good time to look into a real FDDI-oriented list...
thanks in advance,
Chris VandenBerg
cmc
return mail - chrisv@cmc.com
805-562-3127

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 91 03:22:06 GMT
From:      greg@gagme.chi.il.us (Gregory Gulik)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet question and hardware wanted.

In article <9107181742.AA00993@stardent.Stardent.COM> jlawton@Stardent.COM (Jennifer Lawton) writes:
>what's wrong with 2 t's, 2 terminator's and a piece of cable?
>
>much, much, much cheaper than $225.


Because the 3B2 Ethernet card only has one of those 15 (?) pin
connectors for the drop cable.

The PC Ethernet card has both.

-greg

-- 
Gregory A. Gulik                                        Call Gagme, a public
       greg@gagme.chi.il.us  ||  gulik@depaul.edu       access UNIX system at
   ||  gulik@motcid.rtsg.mot.com                        (312) 714-8568

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 91 05:19:35 GMT
From:      CCYILAN@TECHNION.BITNET (Ilan Alter)
To:        comp.protocols.tcp-ip
Subject:   FDDI

Since there is no list for FDDI (as far as I know) I will ask my question
in this list.

The Technion is going to install an FDDI backbone.

We want to connect 7-10 buildings to the FDDI using FDDI routers.
The FDDI ring is going to be daul ring.
We decided that we need an FDDI/Ethernet routers (and not bridges).
Some machines are suppose to be connected to the FDDI also. One of them has
a single attach interface only.

We heard about few manufactures the make those kind of routers:
CISCO (AGS+), Timplex (LAN/TIME 100 series), Network Systems (6400 6600 6800),
Fibronics (FX8530) etc.

I want to hear impresion on those units if anyone had an experiance with them.

Please mail me the information and i'll summerize for the list.






                                              Regards

                            XXXXX            Ilan  Alter
                           XX              Network Manager
                           XX   XXXX       Computer Center
                            XX   XX           TECHNION
                             XX XX         HAIFA  - ISRAEL
                              XXX         CCYILAN@TECHNION
                               X          TEL.  972-4-292651
                                          FAX   972-4-236212

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 91 06:59:14 GMT
From:      toivo@antlia.cc.uwa.oz.au (Toivo Pedaste)
To:        comp.protocols.tcp-ip,aus.comms
Subject:   annex terminal servers and routing


We've just installed an Annex3 terminal server on which we are installing
some SLIP lines. Since it turns out that the annex does not send out
rip routing packets I've had to configure an Ultrix host with static
routes to the networks connected to the annex and gated setup to 
broadcast that it has a route to the networks. What happens the is
that anything that wants to talk to those networks sends to the Ultrix
system which then replies with an ICMP redirect message. 

The current problem I have is that the Cisco routers we have connected
do not take any notice of the redirects so that any packet from them
to the networks on the other side of the annex end up being routed by
the ultrix system and also producing a ICMP redirect as well. Is there
a solution to this problem other than installing static routes into
the Ciscos. 

It seems to me what I really need is to be able to produce prox rip
packets. Does anyone know of any software to do this on Ultrix or Sun.

--
 Toivo Pedaste                        Email:  toivo@antlia.cc.uwa.oz.au
 WARCC,                               Phone:  +61 9 380 2605
 University of Western Australia      Fax:    +61 9 382 1688

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 91 11:43:58 GMT
From:      c.robbins@XTEL.CO.UK (Colin Robbins)
To:        comp.protocols.tcp-ip
Subject:   ISODE 7.0 Available


Multiple apologies for the multiple postings, it does not happen very often...

Colin & Julian

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

			  A N N O U N C E M E N T


    The next release of the "ISO Development Environment" will be
    available on 22 July 1991.  This release is called

				   ISODE 7.0

    This software supports the development of certain kinds of OSI protocols
    and applications.  Here are the details: 

  - The ISODE is not proprietary, but it is not in the public domain.  This was
    necessary to include a "hold harmless" clause in the release.  The upshot
    of all this is that anyone can get a copy of the release and do anything
    they want with it, but no one takes any responsibility whatsoever for any
    (mis)use.

  - The ISODE runs on native Berkeley (4.2, 4.3) and AT&T System V systems,
    in addition to various other UNIX-like operating systems.  No kernel
    modifications are required.

  - Current modules include:
	OSI transport service (TP0 on top of TCP, X.25 and CONS; TP4
	    for SunLink OSI)
	OSI session, presentation, and association control services
	ASN.1 abstract syntax/transfer notation tools, including:
	    remote operations stub-generator (front-end for remote operations)
	    structure-generator (ASN.1 to C)
	    element-parser (basic encoding rules)
	OSI reliable transfer and remote operations services
	OSI directory services
	OSI file transfer, access and management
	FTAM/FTP gateway
	OSI virtual terminal (basic class, TELNET profile)

  - ISODE 7.0 consists of final "IS" level implementations with the
    exception of VT which is a DIS implementation.  The ISODE also 
    contains implementations of the 1984 X.400 versions of ROS and RTS.

  - Although the ISODE is not "supported" per se, it does have a problem
    reporting address, Bug-ISODE@XTEL.CO.UK.  Bug reports (and fixes) are
    welcome by the way. 

  - The discussion group ISODE@NISC.SRI.COM is used as an open forum on ISODE.
    Contact ISODE-Request@NISC.SRI.COM to be added to this list.

  - The primary documentation for this release consists of a five volume
    User's Manual (approx. 1000 pages) and a set of UNIX manual pages.  The
    sources to the User's Manual are in LaTeX format.  In addition, there are
    a number of notes, papers, and presentations included in the documentation
    set, again in either LaTeX or SLiTeX format.  If you do not have LaTeX, you
    should probably get a hardcopy from one of the distribution sites below.






 

    DISTRIBUTION SITES

    The FTP or FTAM distributions of ISODE-7.0 consists of 3 files.  
    The source and main ISODE-7.0 distribution is in the file
    isode-7.tar.Z which is approximately 4.7MB in size.  

    LaTeX source for the entire document set can be found
    in the isode-7-doc.tar.Z file (3.5MB).  A list of documents can be
    found in the doc/ directory of the source tree.

    A Postscript version of the five volume manual can be found in the
    isode-7-ps.tar.Z file (4.3MB).  


 1. FTP
    If you can FTP to the Internet, then use anonymous FTP to uu.psi.com
    [136.161.128.3] to retrieve the files in BINARY mode from the
    isode/ directory. 

 2. NIFTP
    If you run NIFTP over the public X.25 or over JANET, and are registered in
    the NRS at Salford, you can use NIFTP with username "guest" and your own
    name as password, to access UK.AC.UCL.CS to retrieve the files
    from the <SRC> directory

 3. FTAM on the JANET, IXI or PSS
    The sources are available by FTAM from UCL over X.25 using 
	JANET (DTE 00000511160013), 
	IXI   (DTE 20433450420113) or 
	PSS   (DTE 23421920030013) 
    all with TSEL "259" (ASCII encoding).  
    (This service is registered under "ucl, gb" in the OSI Directory).
    Use the "anon" user-identity and retrieve the files from the 
    src/ directory. 
    The file service is provided by the FTAM implementation in
    ISODE 6.0 or later (IS FTAM). 

 4. NORTH AMERICA
    For mailings in NORTH AMERICA, send a check for 375 US Dollars to:

	University of Pennsylvania
	Department of Computer and Information Science
	Moore School
	Attn: David J. Farber (ISODE Distribution)
	200 South 33rd Street
	Philadelphia, PA 19104-6314
	US

        +1 215 898 8560

    Specify either (a) 1600bpi 1/2-inch tape, or (b) Sun 1/4-inch
    cartridge tape.  The tape will be written in tar format and returned
    with a documentation set.  Do not send tapes or envelopes.
    Documentation only is the same price.

 5. EUROPE (tape and documentation)
    For mailings in EUROPE, send a cheque or bankers draft and a purchase order
    for 200 Pounds Sterling to:

        Department of Computer Science
        Attn: Natalie May/Dawn Bailey
        University College London
        Gower Street
        London, WC1E 6BT
        UK

    For information only:
	Telephone:	+44 71 380 7214
	Fax:		+44 71 387 1397
	Telex:		28722
	Internet:	natalie@cs.ucl.ac.uk, dawn@cs.ucl.ac.uk

    Specify either (a) 1600bpi 1/2-inch tape, or (b) Sun 1/4-inch
    cartridge tape.  The tape will be written in tar format and returned
    with a documentation set.  Do not send tapes or envelopes.
    Documentation only is the same price.

 

 7. EUROPE (tape only)
    Tapes without hardcopy documentation can be obtained via the European
    Forum for Open Systems (EurOpen, formerly known as EUUG).
    The ISODE 7.0 distribution is called EurOpenD14.
    
          EurOpen Software Distributions
          c/o Frank Kuiper
          Centrum voor Wiskunde en Informatica
          Kruislaan 413
          1098 SJ  Amsterdam
          The Netherlands

    For information only:
          Telephone:	+31 20 5924121 (or: +31 20 5929333)
          Telex:	12571 mactr nl
	  Telefax:	+31 20 5924199
          Internet:	euug-tapes@cwi.nl

    Specify one of:
	- 1600bpi 1/2-inch tape:			140 Dutch Guilders
	- Sun 1/4-inch cartridge tape (QIC-24 format):	200 Dutch Guilders

    If you require DHL this is possible and will be billed through.
    Note that if you are not a member of EurOpen, then there is an
    additional handling fee of 300 Dutch Guilders (please enclose a
    copy of your membership or contribution payment form when
    ordering).  Do not send money, cheques, tapes or envelopes, you
    will be invoiced. 

 8. PACIFIC RIM
    For mailings in the Pacific Rim, send a cheque for 300 dollars
    Australian to:  

	Isode Distribution
	(Attn Andrew Waugh)
	723 Swanston St,
	Carlton, VIC 3053
	Australia

    For information only:
	Telephone:	+61 3 282 2615
	Fax:		+61 3 282 2600
	Internet:	ajw@mel.dit.csiro.au

    Please specify the media you desire: (a) 1/2-inch tape at 1600bpi,
    3200bpi, or 6250bpi; or (b) Sun 1/4-inch cartridge tape in either
    QIC-11, QIC-24 or QIC-150 format; or (c) Exabyte 2.3 Gigabyte or 
    5 Gigabyte format.  The tape will be written in tar format and
    returned with a documentation set.  Do not send tapes or envelopes.
    Documentation only is the same price.



    SUPPORT

    A UK company has been set up to provide support for the ISODE and
    associated packages - X-Tel Services Ltd.  This company provides
    an update service, source distribution, general assistance and
    site specific support.  Although inclusion of this information
    should not be considered an endorsement, it should be noted that
    two of the primary ISODE developers now work at X-Tel Services Ltd.

	X-Tel Services Ltd.
	University Park,
	Nottingham, NG7 2RD
        UK

	Telephone:	+44 602 412648
	Fax:		+44 602 790278
	Internet:	support@xtel.co.uk

    If other organizations offering formal support for the ISODE wish to be
    included in future announcements, a suitable index will be organized.

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 91 12:21:19 GMT
From:      fontaine%sri.ucl.ac.be@CUNYVM.CUNY.EDU ("Alain FONTAINE ", Postmaster - NAD)
To:        comp.protocols.tcp-ip
Subject:   TCP-IP for VersaDos ??

Hi...
Context  : data acquisition equipment based on VME Bus and 680xx processor,
           driven by VersaDos. Ethernet interface available.
Need     : transfer results to a reasonable computer.
Question : is there an implementation of TCP/IP for VersaDos ? FTP, or even
           TFTP (replace TCP by UDP..) as only application-level protocol
           would suffice.
Thank you for your kind attention.                           /AF

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 91 12:24:38 GMT
From:      eddjp@edi386.UUCP ( Dewey Paciaffi )
To:        comp.protocols.tcp-ip
Subject:   rlogin -> character per packet ?


When I rlogin via TCP/IP, are the characters I type being transmitted
one per packet? Do I have any control over this ?

I'm doing TCP over a "slow" link (.5 second packet round trip) and the 
typing is painfully slow. Block transfers (files / screens) are 
ok.
-- 
Dewey Paciaffi           ...!uunet!edi386!eddjp

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 91 13:29:50 GMT
From:      petonic@daisy.hal.com (Michael A. Petonic)
To:        comp.protocols.tcp-ip
Subject:   Old Talk Program

I'm running on a Sun Sparcstation IPC w/ SunOS 4.1 and would like to chat
via talk(1) to a friend on a VAX/VMS 4.7 System.  I understand that the
Suns have the new talk protocol and the VAX probably has the older one
(I'm fairly sure they use the TCP/IP package from SRI).  Does anyone have
the source or an old version of the talk program that I can use?

Thanks a million,
-MikeP
--
Michael A. Petonic	       petonic@hal.com		       +1-512-794-2855
    HaL Computer Systems - Director of Custodial Services and Entertainment
				 Austin, Texas
		      "If you *have* to live in Texas..."

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 91 15:12:34 GMT
From:      crom@cbnewsb.cb.att.com (michael.crom)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   SLIP/PPP for AT&T 3B2



Well, I tried this on the AT&T internal distribution, and didn't get
a reply from anyone, so now I'll try the rest of the world.


Does anyone know where I could get a version of either SLIP or PPP
for the 3b2 running Wollongong TCP/IP (3.0.1)?


			- Mike Crom
			AT&T Network Systems
			crom@vogon.att.com
			...!att!vogon!crom
			attmail!mcrom

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 91 19:32:20 GMT
From:      jlawton@Stardent.COM (Jennifer Lawton)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet question and hardware wanted.

Still, a little converter from Cabletron and the thinnet and terminators,
etc. are cheaper than a black box product.

And reusable and more versatile and standard.

If you want more info on all of these things, let me know in person.

Jennifer Lawton			Stardent Computer
jlawton@stardent.com		521 Virginia Road
(508)287-0100 x305		Concord, MA 01742

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 91 20:36:43 GMT
From:      rbraun@spdcc.COM (Rich Braun)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.sys.novell
Subject:   Looking for configuration suggestions

This weekend our Novell administrator installed TCP/IP routing software
on several of our Novell servers (the 3.11 release), and my nice
simple TCP/IP LAN just got a whole lot more complicated.  The
topology is typical of large companies (though this is a small
company):  a backbone with about a dozen subnets connected through
gateways to the backbone.  The gateways are Novell servers containing
two Ethernet cards each.

There are a zillion (OK, about 100) DOS machines connected to these
subnets, none of which have TCP/IP software on them at present.  I'm
the lucky person who gets the task of telling everyone how to telnet
over to the Unix systems (some of which are on the backbone).

A small number (half a dozen) DOS systems are connected to the backbone,
and users of these have been using the Clarkson packet drivers to talk
to both the Novell servers and the Unix systems.  The CUTCP program
has a configuration file which can either define gateways and nameservers
itself, or refer to a BOOTP server from which such information can be
downloaded.

The average secretary or document writer here may have a need for access
to the Unix system, but won't have the expertise to go through a 20-step
installation procedure to (a) get the packet driver software, (b)
set up the configuration files, (c) initiate the CUTCP/TELNET program,
and (d) go back through and figure out why the heck step (b) went
wrong.  In addition, hard-coding the IP addresses for every single
DOS system *will* be an error-prone operation.

What's the best way to set up a low-administrative-headache network like
this?  Currently I've got to tell everyone about three different IP
addresses:

	- One of the two addresses of each router (e.g. 192.0.1.1 for
	  subnet 192.0.1, whose other address is on subnet 192.0.0)
	- Their assigned IP address
	- A domain-name-server address

I'd like to somehow automate the IP address assignments for each desktop,
as well.  This is complicated by the fact that both this address and
the gateway address are dependent upon which subnet is connected to
the user's system, and I'm not sure how to determine this in an
automated procedure.  (If developing the procedure takes a lot of effort,
I'll give up on it rather quickly in favor of manual configuration.)

The TCP/IP kit I have from Santa Cruz Operation mentions nothing about
BOOTP.  Can I set this up on the Novell servers?  BOOTP would clearly
be a winner here.

Help!

-rich
Newsgroups: comp.dcom.lans,comp.sys.novell,comp.protocols.tcpip
Subject: Configuring network routes, name servers
Summary: 
Expires: 
Sender: 
Followup-To: 
Distribution: 
Organization: Kronos Inc., Waltham, Mass.
Keywords: 

This weekend our Novell administrator installed TCP/IP routing software
on several of our Novell servers (the 3.11 release), and my nice
simple TCP/IP LAN just got a whole lot more complicated.  The
topology is typical of large companies (though this is a small
company):  a backbone with about a dozen subnets connected through
gateways to the backbone.  The gateways are Novell servers containing
two Ethernet cards each.

There are a zillion (OK, about 100) DOS machines connected to these
subnets, none of which have TCP/IP software on them at present.  I'm
the lucky person who gets the task of telling everyone how to telnet
over to the Unix systems (some of which are on the backbone).

A small number (half a dozen) DOS systems are connected to the backbone,
and users of these have been using the Clarkson packet drivers to talk
to both the Novell servers and the Unix systems.  The CUTCP program
has a configuration file which can either define gateways and nameservers
itself, or refer to a BOOTP server from which such information can be
downloaded.

The average secretary or document writer here may have a need for access
to the Unix system, but won't have the expertise to go through a 20-step
installation procedure to (a) get the packet driver software, (b)
set up the configuration files, (c) initiate the CUTCP/TELNET program,
and (d) go back through and figure out why the heck step (b) went
wrong.  In addition, hard-coding the IP addresses for every single
DOS system *will* be an error-prone operation.

What's the best way to set up a low-administrative-headache network like
this?  Currently I've got to tell everyone about three different IP
addresses:

	- One of the two addresses of each router (e.g. 192.0.1.1 for
	  subnet 192.0.1, whose other address is on subnet 192.0.0)
	- Their assigned IP address
	- A domain-name-server address

I'd like to somehow automate the IP address assignments for each desktop,
as well.  This is complicated by the fact that both this address and
the gateway address are dependent upon which subnet is connected to
the user's system, and I'm not sure how to determine this in an
automated procedure.  (If developing the procedure takes a lot of effort,
I'll give up on it rather quickly in favor of manual configuration.)

The TCP/IP kit I have from Santa Cruz Operation mentions nothing about
BOOTP.  Can I set this up on the Novell servers?  BOOTP would clearly
be a winner here.

Help!

-rich

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 91 20:44:19 GMT
From:      fvance@airgun.wg.waii.com (Frank Vance)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for SNMP Mgmt package

Several people have written:
>The two public domain SNMP manager implementations are:
 ...
>2) Massachusetts Institute of Technology (MIT) written by Chuck Davin and 
                                                        ^^^^^
>available from allspice.lcs.mit.edu

My sources say J. Davin.  RFC1157 gives his first name as James.
Does he really want to be called Chuck?

Regards,
-- 
Frank Vance  (713) 963-2426		Western Geophysical
fvance@airgun.wg.waii.com		10001 Richmond Avenue
...!uunet!airgun!fvance			Houston, TX 77042   USA

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      22 Jul 91 23:34:43 GMT
From:      herrickd@iccgcc.decnet.ab.com
To:        comp.protocols.tcp-ip,comp.archives.admin
Subject:   Re: On the need to develop Internet user services

In article <WORLEY.91Jul3102926@sn1987a.compass.com>, worley@compass.com (Dale Worley) writes:
> 
> A further barrier is that an astonishing fraction of the users of
> NSFnet have a deep, visceral objection to commercial information
> services.  Frankly, I don't understand where it comes from, but it's
> there, and it's intense.  Consider the flamage Ed Vielmetti got when
 [...]
> probably has the cheapest long-distance telephone service in the
> industrialized world (figuring in subsidies) precisely because it has
> the most capitalist long-distance telephone service.  (AT&T could
> probably reduce its rates by 10% if it just stopped running all those
> commercials!)  It has gotten to the point that ordinary people feel

This is not central to your argument, but it is widely believed.
The problem is, if AT&T stopped running those commercials, the
long-distance market would shrink some and AT&T's market share
would go down.  These two effects would lead to layoffs and 
higher (not lower) tolls.

dan herrick         dlh@NCoast.org

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 02:17:14 GMT
From:      almquist@JESSICA.STANFORD.EDU ("Philip Almquist")
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Router Questions

Kory,
	A replacement for the router standard RFC-1009 is in the process
of being written.  This message gives the answers found in that
replacement, which is not yet a standard but is likely to become one
next year.

>	1.	If a Network Management Stations adds a new route or
>		modifies an existing route in a router, should this be
>		considered a Static route? If so, it should not be aged?

	According to the current draft, a route created with SNMP
would be considered a static route.  Since static routes are not managed
by any routing protocol they do not time out.

	I don't think that the draft explicitly considers what happens
when you use SNMP to modify an existing route, but it would seem
reasonable to assert that modifying a route does not convert it into a
static route.  Thus, the modified route would be aged (unless it was a
static route to begin with).  An interesting note, by the way: it is (or
at least ought to be) an error to modify an OSPF or Dual IS-IS route,
since that would cause the protocol (OSPF or Dual IS-IS) to malfunction.

	2.	If a Network Management Station adds a route, and the router 
		learns a route dynamicly (through RIP for example) which
		contradicts or has a different metric than the route
		set by NMS, which one should the router accept?

	Again according to the current draft, every route (static or
dynamic) has associated with it a preference value (similar to what's
called a "preference" in gated or an "administrative distance" in
cisco-ese).  A dynamic route will override a static route if and only if
the preference value of the dynamic route is better than the preference
value of the static route.

	3.	If the router has a filter table entry which will block
		packets to a certain network, what should it do if it
		receives a packet destined for that network? Simply
		discard the packet? Send an ICMP destination unrechable?
		Send an ICMP redirect? Note that a filter table is different
		than a routing table.

	(Again according to the draft) you normally send a Destination
Unreachable, with a new subcode (not yet assigned, but probably 13)
which means that communication is administratively prohibited.  However,
some sites have security policies that require that no response be sent.

	4.	Under MIB II, a route can be set to INVALID, does this
		mean that this entry should be deleted from the routing
		table, or just stop routing to that network?

	That's an interesting one.  I would guess that deleting it from
the routing table would be ok, but some might not like the fact that
under that interpretation, a dynamic route which was set invalid would
reappear next time a routing update was received.

	This also raises some interesting questions about interactions
with routing protocols.  In protocols like RIP, it is bad manners to
delete or stop using a route without telling your neighbors you have
done so.  Setting an OSPF or Dual IS-IS route invalid should be illegal,
since those protocols don't allow a router to disbelieve or discard
routes learned through those protocols.
							Philip

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 03:22:50 GMT
From:      sob@isr.harvard.edu (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   Router (& Bridge) Bashing is baaaack

Well its about that time again, another round of "network interconnection"
device tests is about to start.  If you have suggestions about the tests or
want to offer products to be tested please let me know.

Tests:
	throughput: at what speed does the device still pass 100% of offered 
		packets?
	packet loss rate:  plot of offered packets vs passed packets up to
		max speed of media.
	back-to-back:  how long a burst of packets can the device take
		before its internal queues cause packets to be dropped?
	latency: how long does it take to process a packet, test run at
		throughput rate

Details:
	for a range of packet sizes:
		max & min for media and some in between
	for a number of protocols:
		TCP/IP, OSI, DECnet Phase IV, AppleTalk Phase II, XNS,
		IPX, bridge mode
	with & without security filters
	hope to do multiple addresses in test streams
	hope to do mixed protocol streams
	hope to add a test with 10% broadcast packets
	hope to add a test with 10% error packets
	hope to do up to 10 streams (on Ethernet)
	hope to do bidirectional

	(Yes there are a lot of "hope to"s, the software development is
	not finished yet.)

Media:
	Ethernet, 4MB Token Ring, 16MB Token Ring, FDDI, WAN (T1 & T3)

Devices:
	Bridges & Routers

Test Set Ups:
	   source side				dest side

                           ------------
	====Ethernet(s)====|  device  |========Ethernet(s)======
                           ------------

          ---------------
         /               \ ------------
	<  4MB T. Ring    >|  device  |========Ethernet===========
         \               / ------------
          ---------------

          ---------------
         /               \ ------------
	<  16MB T. Ring   >|  device  |========Ethernet(s)========
         \               / ------------
          ---------------

          ---------------
         /               \ ------------
	<     FDDI        >|  device  |========Ethernet(s)========
         \               / ------------
          ---------------

          ---------------                --------------
         /               \ ------------ /              \
	<     FDDI        >|  device  |<    FDDI        >          
         \               / ------------ \              /
          ---------------                --------------

                       ----------           ----------
    ====Ethernet(s)====| device |-----------| device |====Ethernet(s)====
                       ----------           ----------
                                  T1 or T3


One problem:
	after the testing how should the results be grouped?

	A trade publication test from a while ago tested 4 routers which
differed widely in function & cost but reported all the results together.
(As I did last year.) I now think it would be better to group the devices
somehow, for example:

	2 port bridges & routers

	<= 6 port bridges & routers with local connections

	<= 6 port bridges & routers with WAN connections

	> 6 port bridges & routers with local connections
 
	> 6 port bridges & routers with WAN connections

any suggestions?

When:
	Tests to start the last week of August & go through the last week
	of Sept.

Reports:
	Report at my Interop tutorial (a bit extra for the $) 
		and at a BOF (for free).
	Report to this list by the end of Oct.
	Raw data on husc6.harvard.edu after posting.

Test Equipment
	I've got offers of a bunch of nice test equipment and am banking on
	some of it.  In particular, Wandel & Goltermann has loaned a DA-30
	(a real nice box) that will be used for the single stream and
	latency tests.  Some vendors have offered in-house test equipment
	for things like FDDI (Timeplex) and Token Ring (Proteon).  Some of
	the names of the vendors that have offerd equipment can not be posted
	yet since the test equipment is based on un-announced products, all
	will be revealed the 2nd week in Oct.

Reality:
	I know that in most cases raw performance should not be the one thing
	that is used to select a router but it is of interest to many and
	does help if you think that world is going to the data packets as
	I do.

Suggestions ( flames etc ) to sob@harvard.edu

Equipment offers to same address.

If you HAVE to talk to me:  617-495-3864

Snail address:	Scott Bradner
		Harvard University
		10 Ware St.
		Cambridge MA 02138
		

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 07:24:50 GMT
From:      mni@CRAYAMID.CRAY.COM (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented

to me, this does not only go on byte order, but on nfs/ftam methods as
well, where files are made portable by representing them in a
"predetermined binary structure", which as well can be a protocol to me.


michael

*.. and the disclaimer .. (

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 08:48:40 GMT
From:      J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
To:        comp.protocols.tcp-ip
Subject:   the last word in terminal protocols...








Network Working Group                                         J.
Tforcworc Request for Comments: DRAFT                       Laboratory
for Cuban Unicorns
                                                           July 4th, 1492


                     LATNET - A DECLAraTive TELNET


Status of this Memo

   This RFC is being distributed to members of the Internet community in
   order to solicit their smiles. Distribution of this memo is in error.

Proposed LAT on TELNET Protocol

Somebodies LAT was designed to run on Ethernet networks. This makes the
sizes of packets and timers rather more suitable than some TC/PIP things
(eg. no Double checksumming).

There is no network layer in LAT. This again simplifies the packet
formats.

Being designed specifically for interactive terminal sessions, LAT cuts
down the number of packets travelling around the net for low levels of
user data. This makes it much more efficient than TCP for terminal
traffic.

The whole protocol runs from a free running timer in both the terminal
server and host. The timer controls how often user data is sent over the
network and the rate of packet retransmision in case of packet loss.

The use of a timer for packet transmision means that the maximum total
load offered by a LAT host may be both set and computed.

Most of the knowledge of LAT betrayed in this text was gleaned from
peering much too closely at yellow cables.

The Protocol

   Data delivery.

     LAT uses similar techniques to TCP in achieving the aims of a
     transport protocol. Packets which are unacknowledged are
     retransmitted.





Tforcworc                                                       ^L[Page 1]





RFC DRAFT                                                 July 4th, 1492


        Flow control.


     Each Virtual Circuit has a credit value associated with it. The
     credit value represents the number of slots that the receiver is
     prepared to buffer. The slots can vary in length and for this
     reason, the software to decide on the optimal credit strategy is
     rather too complex to comprehend.

   Packet ordering error checking (sequence numbering)

             The packet sequence numbering scheme of LAT uses only an 8
     bit
             field for the packet sequence number. Big deal unless you
     can         type at gigabits.

      Out of band data.

     Two mechanisms exists to send out of band data. The first is to
     send DATAB messages. These messages are used by hosts to negotiate
     terminal flow conrol characters. The second is to turn your
     terminal off.

      Name - Address mapping.

     LAT has its very own name/address perverse mapping functions.

     Mapping from user level names to MAC addresses is fairly horrible.

LAT in all its gory...

Virtual Circuits.
     Lat is very different from telnet/tcp/ip.  When a session is
     started between any two machines for the first time, a new Virtual
     Circuit is started. Any other sessions between the two machines
     will use this virtual circuit, and may transmit data on it. If at
     any time one or more sessions are between any two machines, a
     single virtual circuit will exist between those machines. All the
     data passed between the machines will be carried on this virtual
     circuit. Using this method data for two separate sessions may be
     carried in the same Ethernet packet.

     A Virtual Circuit will have a Virtual Circuit Control Block on each
     participating computer.

     Session information is carried in slots. There may be more than one
     slot contained in one Ethernet packet, either for different or the
     same session. Slots consist of a slot header which concisely



Tforcworc                                                       ^L[Page 2]





RFC DRAFT                                                 July 4th, 1492


     describes nature of the slot with any data following.

     A session will have a LAT Control Block on each participating
     computer.
 LAT MIB.
       This should include :-
           Total frames received.

           Duplicate frames received.

           Frames Transmitted.

           Frames ReTransmitted.

           Illegal messages received.

           Illegal slots received.

 Configuarable parameters.

              Parameters which may be altered between installations
     include :-

              Maximum number of slots on a Virtual Circuit

              Maximum number of Virtual Circuits

              Maximum total LAT sessions

              Maximum number of retransmissions

              Virtual Circuit timer frequency

              Idle timer frequency

              Maximum Number of credits to advertise

              LAT service class to use
   Mapping LAT VCs onto TCP

      Open Connection.

One end of the connection will have called passive open, which will
prime a VCB (= TELNET TCP Connection) into LISTEN, this end usually
offers the LAT login.

The other end (usually the terminal server) will call Open.  If no TCP
Connection exists between the machines, VC packets containing START



Tforcworc                                                       ^L[Page 3]





RFC DRAFT                                                 July 4th, 1492


messages will be exchanged. This will establish VCBs in RUNNING state
and VCB IDs at both ends of the connection.

If the Virtual Circuit was not present when the Open was called, the LCB
for the active opener will have been put into WAITFORVC state. As the VC
opens, the LCB will enter STARTING state. If the virtual circuit did
exist, the LCB will enter STARTING state.

   As the active open LCB enters STARTING, a START slot will be sent
   over the running VC.

   The host will reply with a START slot, this will put the LCBs into
   RUNNING state. Data may now be transferred. It might also be lost.
      Data Exchange.

   Both the VC and the session (VCB & LCB) at both ends should be
   RUNNING before data can be sent between units.

   Send will be called at one end. Once the credits advertised
   from the other end are sufficient, the sender may construct one or
   more packets containing the user data. The sender may choose to
   send many packets each containing one slot, or less packets each
   containing a number of slots. This choice should be confusing.

   The packet(s) will be transferred from the sender to the receiver.

   The receiver will Acknowlage the packets upon correct, in sequence
   packets. The Data slotsa from these packets will be copied into
   tempory buffer storage.

   Some time later, the user at the receiver will call Receive.
      Session Close.

   One participant in the exchange will call Close. That
   participant will send a STOP type slot, and will enter LCB STOPPING.

   Upon receiving the STOP slot, the host will reply with a STOP slot
   and will enter LCB STOPPING.

   The origionator of the close will receive the STOP message and will
   enter LCB IDLE.

   The host which received the first STOP message will timeout on the
   STOPPING slot and will send a STOP slot to the IDLE LCB. The
   receiver of this will reply with a STOP slot, which will force the
   sender into IDLE.

   As the hosts enter LCB IDLE, they check the VC for any other



Tforcworc                                                       ^L[Page 4]





RFC DRAFT                                                 July 4th, 1492


   session. When the last session on a VC enters IDLE, the VC is
   closed as a tidy up.

Security Considerations

   Security considerations may not be discussed in this memo.
State Considerations

   The protocol is virtually state free - it is also semantic free.
Author's  Address:

   Jon Tforcworc
   Laboratory for Cuban Unicorns
   West Grinstead
   emordnilap@uk.ac.ucl.cs.ucl.ac.uk




































Tforcworc                                                       ^L[Page 5]

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 12:45:54 GMT
From:      kasten@EUROPA.CLEARPOINT.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP Router Questions


 > 
 > 	4.	Under MIB II, a route can be set to INVALID, does this
 > 		mean that this entry should be deleted from the routing
 > 		table, or just stop routing to that network?
 > 
 > 	That's an interesting one.  I would guess that deleting it from
 > the routing table would be ok, but some might not like the fact that
 > under that interpretation, a dynamic route which was set invalid would
 > reappear next time a routing update was received.

Strictly speaking, within the SNMP and MIB-II framework, the actual effect
of setting an ipRouteType to invalid is implementation dependant, other than
that the route is no longer used. The MIB spec states that "It is an
implementation-specific matter as to whether the agent removes the
invalidated entry from the table."

MIB-II does not discuss the "permanence" of invalidating a route. If one's
implementation wished to permanently "not-learn" a route because it was
invalidated by SNMP, that's fine by SNMP and the MIB.

So much for the strictly formal view of what the MIB and SNMP say and do
not say.

My less-formal view is that invalidating a route should be similar in effect
to the "delete route" command that might be available on a router's console.
The few that I've seen would just remove the entry from the routing table and
if that route was relearned, well, that's life. This seems to be the more or
less "common" way that this function operates.

 > 	This also raises some interesting questions about interactions
 > with routing protocols.  In protocols like RIP, it is bad manners to
 > delete or stop using a route without telling your neighbors you have
 > done so.  Setting an OSPF or Dual IS-IS route invalid should be illegal,
 > since those protocols don't allow a router to disbelieve or discard
 > routes learned through those protocols.
 > 							Philip

When setting some object in a MIB you are not "merely" changing
a byte or two in storage someplace. Setting an object may cause a
whole series of operations to occur. In previous MIBs that
I've implemented, there have been reset-the-box types of objects,
which would send a response, gracefully shut things down, etc, etc.
Thus, having RIP tell the routers neighbors that route x is no
longer valid or whatever would be an expected operation.

If an entry in the routing table is such that it is not supposed to be
invalidated, then an attempt to set the ipRouteType object for that
route to invalid would be rejected with an SNMP badValue error code.
This policy also extends to other objects in the MIB. If for some reason,
you do not wish to let certain writable objects in the MIB be set to
particular values, the operation is rejected with badValue. Another
example would be trying to set the metric of a RIP route to 9999.


Hope this helps
Frank Kastenholz
Clearpoint Research Corp.

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 14:54:42 GMT
From:      heberlei@iris.UCDavis.EDU (Louis Todd Heberlein)
To:        comp.protocols.tcp-ip
Subject:   Re: rlogin -> character per packet ?

In article <170@edi386.UUCP>, eddjp@edi386.UUCP ( Dewey Paciaffi ) writes:
> 
> When I rlogin via TCP/IP, are the characters I type being transmitted
> one per packet? Do I have any control over this ?
> 

Typically the transfer is one character per THREE packets.  For example,
if you are in the command line and type an 'l' (for "ls"), the 'l' is
wrapped up in the TCP protocol, IP protocol, then then network layer
protocol (e.g., ethernet) and then transmitted.  The remote hosts then
responds by telling your terminal to print an 'l' (the second packet).
Finally,  your hosts sends back to the remote host an acknowledgement
that it received the command to print the 'l' (third packet).

Now you are ready to type in the 's'.   :-)

I am not sure if you can change this.  I am not sure you would want to.
What you see on your screen are are commands from the remote host to
to print certain characters on your screen.  For example, in the shell,
when you type a 'j' the remote host tells your terminal to print a 'j'.
But if you are in a visual editor (e.g., vi), the typing of a 'j' may
cause the remote host to send control characters to your screen to move
the cursor.  I think automatic buffering could lead to some confusion.


> I'm doing TCP over a "slow" link (.5 second packet round trip) and the 
> typing is painfully slow. Block transfers (files / screens) are 
> ok.
> -- 
> Dewey Paciaffi           ...!uunet!edi386!eddjp

Perhaps someone who has actually implemented (or has hacked on) a TCP
implementation can give you a good solution.  Sorry,

Todd

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 15:41:07 GMT
From:      leonard@arizona.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Old Talk Program

In article <PETONIC.91Jul22152950@daisy.hal.com>, petonic@hal.com 
(Michael A. Petonic) writes:
> I'm running on a Sun Sparcstation IPC w/ SunOS 4.1 and would like to chat
> via talk(1) to a friend on a VAX/VMS 4.7 System.  I understand that the
> Suns have the new talk protocol and the VAX probably has the older one
> (I'm fairly sure they use the TCP/IP package from SRI).  Does anyone have
> the source or an old version of the talk program that I can use?

Here's the scoop as I understand it:

"Old talk" had a bug in it where machines with different byte-ordering
were unable to converse with each other.  That is, big-endian machines,
such as Motorola based systems (e.g. Suns) could talk amongst themselves,
and little-endian machines (such as VAXen and Intel machines) could 
converse, but the twain couldn't meet.

This problem was fixed in "New talk".

To the best of my knowledge, Sun still ships the broken "Old talk".  If your
friend is running TGV's MultiNet on the VMS system, then that supports 
both kinds of talk, but since the Sun is big-endian and the VAX is
little-endian, you won't be able to talk.

Actually, what you want is "New talk" for SunOS.  That should be
available from Berkeley, though I don't know whether anyone's 
built it on the Sun.

Aaron

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 15:52:07 GMT
From:      john@loverso.leom.ma.us (John Robert LoVerso)
To:        comp.protocols.tcp-ip
Subject:   Re: rlogin -> character per packet ?

> > I'm doing TCP over a "slow" link (.5 second packet round trip) and the 
> > typing is painfully slow.
> 
> Perhaps someone who has actually implemented (or has hacked on) a TCP
> implementation can give you a good solution.  Sorry,

TELNET LineMode solves this problem.  See either the RFC and/or the
freely distributeable BSD telnet/telnetd programs on ucbarpa.berkeley.edu.

The next question is why does your link have such a high delay.  If it
is a SLIP link, consider using CSLIP.

John

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 16:45:07 GMT
From:      willis@cs.tamu.edu (Willis Marti)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet question and hardware wanted.

Greg Gulik writes:
In article <9107181742.AA00993@stardent.Stardent.COM> jlawton@Stardent.COM (Jenn
ifer Lawton) writes:
>what's wrong with 2 t's, 2 terminator's and a piece of cable?
>
>much, much, much cheaper than $225.


Because the 3B2 Ethernet card only has one of those 15 (?) pin
connectors for the drop cable.

The PC Ethernet card has both.

-greg
---------------------
You can always get the AUI-to-BNC transceivers, cost ~$120.  Still better than
thick cable.
-------------------------------------------------------------------------------
 Willis F. Marti		Internet: willis@cs.tamu.edu
 Director, Computer Services Group, Dept of Computer Science, Texas A&M Univ.
 	---Not an official document of Texas A&M---

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 16:47:53 GMT
From:      rlstewart@eng.xyplex.com (Bob Stewart)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for SNMP Mgmt package

Regarding the MIT SNMP package.  Although a bit lacking in documentation, I've
found it very useful.  The code is impressively portable (if not terribly
clear) and rigorously modular.  I've used it to construct two prototypes in
relatively short time, one of them an agent in a non-UNIX system.

Yes, James Davin pronounces his given name "Chuck".  :-)

	Bob

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 17:04:20 GMT
From:      coates@UC780.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: rlogin -> character per packet ?

In article <9372@ucdavis.ucdavis.edu>, heberlei@iris.UCDavis.EDU (Louis Todd Heberlein) writes:
>In article <170@edi386.UUCP>, eddjp@edi386.UUCP ( Dewey Paciaffi ) writes:
>> 
>> When I rlogin via TCP/IP, are the characters I type being transmitted
>> one per packet? Do I have any control over this ?
>> 
>
>Typically the transfer is one character per THREE packets.  For example,
>if you are in the command line and type an 'l' (for "ls"), the 'l' is
>wrapped up in the TCP protocol, IP protocol, then then network layer
>protocol (e.g., ethernet) and then transmitted.  The remote hosts then
>responds by telling your terminal to print an 'l' (the second packet).
>Finally,  your hosts sends back to the remote host an acknowledgement
>that it received the command to print the 'l' (third packet).
>[more stuff deleted]

Overall I found your explanation enlightening but, doesn't it go 1.) tcp->more
of a transport layer protocol, .) ip->more of a network layer protocol and
3.) ethernet->more of a data link layer (of the logical link control sublayer) 
protocol?

Happy Computing!

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 17:07:19 GMT
From:      daveh@marob.uucp (Dave Hammond)
To:        comp.unix.xenix.sco,comp.dcom.lans,comp.preotocols.tcp-ip
Subject:   Implementing ftp and telnet under SCO Xenix.

We are interested in setting up ftp and telnet services between two 386
machines running SCO Xenix 2.3.2.  Given that we have no experience with
implementing network services (other than uucp), can someone recommend a
software package, interface cards and wiring scheme which would be simple
to install and configure, reliable and relatively inexpensive?

Information about software and components to avoid would also be
appreciated.

Thanks in advance.

--
Dave Hammond
daveh@marob.uucp
uunet!rutgers!phri!marob!daveh

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 17:29:47 GMT
From:      VANCE@TGV.COM (Icarus)
To:        comp.protocols.tcp-ip
Subject:   Re:  Old Talk Program

>I'm running on a Sun Sparcstation IPC w/ SunOS 4.1 and would like to chat
>via talk(1) to a friend on a VAX/VMS 4.7 System.  I understand that the
>Suns have the new talk protocol and the VAX probably has the older one
>(I'm fairly sure they use the TCP/IP package from SRI).  Does anyone have
>the source or an old version of the talk program that I can use?

If the VMS user has anything from MultiNet V2.1 or later (actually, I think
it's in V2.0 as well), it definitely supports both old and new talk.  The real
question is, does Sun?  As of 4.0.3, they did not (at least, not that I could
find anywhere).  If you want to try new talk out on the Sun, you can snarf it
from UUNET.UU.NET in the bsd-sources/usr.bin/talk directory.

Regards,
-----Stuart

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 18:53:53 GMT
From:      hsw@COLUMBIA.SPARTA.COM (Howard Weiss)
To:        comp.protocols.tcp-ip
Subject:   Re: rlogin -> character per packet ?

You could use telnet in line at a time mode and relieve the burden of
the remote character per packet echoing.  You run into trouble running
editors like vi or emacs because you need to send raw characters to
control the screen.  The Multics tcp/ip implementation defaults to
line-at-a-time mode and then switches into character-at-a-time when
going into an application (e.g. emacs) that requires raw character
input.  When exiting from emacs on Multics the system then switches
back into line at a time mode to continue with local echoing.

Howard Weiss

SPARTA, Inc.
9861 Broken Land Parkway, suite 355
Columbia, MD 21046
phone: (301)381-9400
email: hsw@columbia.sparta.com

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 19:18:54 GMT
From:      rmilner@zia.aoc.nrao.edu (Ruth Milner)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Survey Results

In article <CMM.0.90.2.679970272.nisc@phoebus.nisc.sri.com> nisc@NISC.SRI.COM (SRI NISC) writes:
>
>                       Top 50 Most Popular Host Names
 
> 216 saturn      178 hobbes      158 calvin     143 athena      133 io
                  ^^^^^^^^^^      ^^^^^^^^^^

Somebody should tell Bill Watterson (?) how popular his characters are in 
the world of computers :-).  Similarly, Berke Breathed (opus) and Arthur C. 
Clarke (hal), though the latter is probably well aware of it.
-- 
Ruth Milner
Systems Manager                     NRAO/VLA                  Socorro NM
Computing Division Head      rmilner@zia.aoc.nrao.edu

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 19:56:56 GMT
From:      dave@fps.com (Dave Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: htonl() patented

In article <zweig.679945869@osric> zweig.PARC@Xerox.com writes:
>By the way, I just read Rob Pike's patent 4,555,775 (I think that was it),
>which is the one I have heard called "the backing store patent" -- actually,
>it patents the idea of having N processes sending output to N windows
>simultaneously, with screen updates taking place pseudo-concurrently.  He
>cites Smalltalk-80 as an example of prior art for windowing systems, and that
>it doesn't allow multiple processes to simultaneously update their windows.
>It was filed in 1982, issued in 1985, so any prior art challenge would
>probably have to come from the late '70's.  

I should think that backing store would be equivalent to a virtual screen.
The UCSD P-System on the Apple II had the virtual 80 column screen on the
40 column screen in the early 80's (I'm not sure how early, but quite probably
before '82).  It didn't have multiple processes, but it didn't require the
process updating the screen to hold onto its output for the half of the screen
not being displayed.

Perhaps it's time to start filing law suits against frivolous patents?
-- 
David L. Smith
FPS Computing, San Diego        ucsd!celit!dave or dave@fps.com
"It was time to stop playing games.  It was time to put on funny hats and
eat ice cream.  Froggie played his oboe" - Richard Scarry

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 20:33:43 GMT
From:      jpc@avdms8.msfc.nasa.gov (J. Porter Clark)
To:        comp.protocols.tcp-ip
Subject:   ucbarpa's telnetd fails under SunOS

I tried posting this to comp.sys.sun, but I have not received even one
reply yet.  (Yes, it did make it to the net.)

There is a bug somewhere that makes the telnet server (telnetd) from
the telnet.91.03.25.tar.Z package from ucbarpa.berkeley.edu fail under
certain circumstances when compiled under SunOS 4.1 or 4.1.1.

The problem is most noticeable when using telnet clients that use the
telnet command "IAC EC" to backspace.  I have only one telnet client
which does this; TOPS Terminal, which runs on a Mac using the Sitka
Corp. TOPS package.  There may be other clients which use "IAC EC" for
backspacing.

Any attempt by the telnet client to send "IAC EC" or other similar
commands will not succeed on the server, which will ignore the
command.

The chain of events is as follows: The telnet client sends "IAC EC".
The telnet server receives this command and attempts to determine what
the erase character associated with the pty is.  It does a
tcgetattr().  Under SunOS, this fails and errno is set to ENOTTY.  I do
not know why it does this.  Under SunOS, tcgetattr() and tcsetattr()
are converted into ioctl() calls.  Most of the ioctl() calls which the
server makes to the pty (controller) device fail past a certain point
(somewhere after the fork() which starts the login process).  The exit
status from these ioctl's is usually ignored, but the effects of the
failure are usually benign except for "IAC EC" and similar commands.

I've tested this on a Sun-3 running SunOS 4.1 and a Sun-4 running SunOS
4.1.1.  The results are the same.  I've also tested this on a
DECstation running Ultrix 4.1, but it performs correctly there.

Sun's own in.telnetd does not fail in this manner.  I haven't been able
to deduce anything from comparing trace(1) outputs from both servers
except to note that when Sun's server does similar ioctl's, it does not
fail except when expected to, such as a precautionary TIOCNOTTY call.
I do not have Sun source with which to compare the two telnet servers.
I also cannot trace the child processes from either Sun's or Berkeley's
telnetd.

I have sent an e-mail message to the appropriate party (Dave Borman at
Cray) but have not yet received a response.

I strongly suspect that there is a bug in the rather strange hybrid
("That's the nice word for it") tty subsystem in SunOS.  I am aware
that Sun's kernel source file tty.c (which I don't have) must be
patched to use the LINEMODE feature.  However, I can build telnetd with
LINEMODE turned off and the "IAC EC" problem is still there.

Anybody have any ideas?
--
J. Porter Clark    jpc@avdms8.msfc.nasa.gov

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      23 Jul 91 21:09:26 GMT
From:      tjh+@andrew.cmu.edu (Tom Holodnik)
To:        comp.protocols.tcp-ip
Subject:   SLIP under SunOS 4.1.1


	Recently, we installed the CSLIP package (header compression SLIP) for
SunOS 4.X machines, and things appear to be working well except for one
nit. 
	Whenever I open a TCP connection to a remote host, the initial packet
should contain the TCP SYN flag, and the TCP option for indicating TCP
MSS. However, no TCP MSS is within these packets, so I end up having TCp
that works well, but I have to put up with IP fragments on the serial
line. 
	As you'd imagine, everything works just fine when this is passed over
Ethernet. The compression module doesn't touch these packets; it senses
the SYN flag, and passes it without modifying it.  Is there anything
else that needs to be modified under SunOS 4.1.1? 
	If you've gotten this to work properly, please send me mail...

	I'm using the cslipbeta distribution from ftp.ee.lbl.gov.  I also have
the SunOS SLIP from ai.toronto.edu, but deferred to the LBL package
mostly, to utilize header compression. 

Thanks in advance for your time,
Tom Holodnik
CMU

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 91 00:29:18 GMT
From:      ggm@brolga.cc.uq.oz.au (George Michaelson)
To:        comp.protocols.tcp-ip
Subject:   Re: rlogin -> character per packet ?

john@loverso.leom.ma.us (John Robert LoVerso) writes:

>> > I'm doing TCP over a "slow" link (.5 second packet round trip) and the 
>> > typing is painfully slow.
>> 
>> Perhaps someone who has actually implemented (or has hacked on) a TCP
>> implementation can give you a good solution.  Sorry,
 
>TELNET LineMode solves this problem.  See either the RFC and/or the
>freely distributeable BSD telnet/telnetd programs on ucbarpa.berkeley.edu.
 
>The next question is why does your link have such a high delay.  If it
>is a SLIP link, consider using CSLIP.

Er... how about the link being slow cos it crosses at least 2 brouters,
2 satellite links, the NSF backbone, another Fatpipe owned by some 
multinational outfit registered in the bahamas and finally into a CPU sold
off to about 3 different groups as a "gateway" box? I've seen pings take
around 2sec on that mother.

If you're trying to use the nsf-relay.ac.uk to talk into JANET, wake up
to the nightmares of 4 years ago when 1-2 sec per-character delay was the
norm, and 30sec delay not impossible. Some things even telnet linemode cannot
fix, and multi-hop like this is one of them.

Answer: [muffled shrieks as the thought police bring out the RFC truncheons]
	use appropriate protocols and h/w for appropriate purposes, and 
	consider using X.29 services from the PSTN. They work much better for
	trans-continental i-just-want-to-read-my-mail-back-at-home-man usage.

-George
-- 
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 91 03:00:24 GMT
From:      ellozy@farber.dfci.harvard.edu (Mohamed Ellozy)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for SNMP Mgmt package

In article <alfred.680115567@dutepp0> AKayser@dnpap.et.tudelft.nl (Alfred Kayser) writes:
>lms@SSDS.SSDS.COM (L. Michael Sabo) writes:
>>The two public domain SNMP manager implementations are:
>MAKE THAT THREE!!!

Actually FOUR (if not FIVE).  Add:

1.  The ISODE contains an SNMP-capable gawk, described briefly in The
Simple Book, that makes writing manager queries trivial for
awk/nawk/gawk users.

2.  There is an SNMP Query Language (snmpql, as i recall) on
uu.psi.net.  The technical report that comes with it is intriguing, I
have not gotten around to compiling it yet.

Mohamed

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 91 06:45:32 GMT
From:      imp@solbourne.com (Warner Losh)
To:        comp.protocols.tcp-ip
Subject:   Re: Old Talk Program

In article <PETONIC.91Jul22152950@daisy.hal.com> petonic@daisy.hal.com (Michael A. Petonic) writes:
>I'm running on a Sun Sparcstation IPC w/ SunOS 4.1 and would like to chat
>via talk(1) to a friend on a VAX/VMS 4.7 System.  I understand that the
>Suns have the new talk protocol and the VAX probably has the older one
>(I'm fairly sure they use the TCP/IP package from SRI).  Does anyone have
>the source or an old version of the talk program that I can use?

I'm afraid that you have it backwards.  Sun still clings to the old
talk protocol, while most VMS TCP/IP vendors supply the new talk
protocol.  You can get a copy of the new talk program from the freed
BSD stuff that is on UUNET.UU.NET.  It should port w/o any headaches.

If you really want to run the old talk protocol between suns and
vaxen, then be prepared for some headaches.  Both ends must grok
different byte orders in order for it work (that's why there is a new
talk protocol).

Warner

P.S.  My info on talk is as of SunOS 4.0.3.  4.1 may have changed
things, but I seriously doubt it.
-- 
Warner Losh		imp@Solbourne.COM
But it was our hill.  And they were our beans.

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 91 07:06:59 GMT
From:      krygier@ASTERIX.KPH.UNI-MAINZ.DE (Klaus Werner Krygier)
To:        comp.protocols.tcp-ip
Subject:   Address Change


Because our bitnet node DMZNAT51 does not exist any more please remove
	"krygier@dmznat51.bitnet"
from your list. Instead of the old address please add the new one
	"tcpip@asterix.kph.uni-mainz.de".

Thank You
Klaus Werner Krygier

Klaus Werner Krygier
Institut fuer Kernphysik
Johannes Gutenberg-Universitaet Mainz
Saarstrasse 21
D-6500 Mainz

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 91 08:09:54 GMT
From:      a38@nikhefh.nikhef.nl (James Barr)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   ANNOUNCE: Network Mapping List


I apologise to those who may have seen this elsewhere,
but there seems to be a fair bit of interest so I thought
it best to announce it to a wider audience.

-------------------------------------------------------------------
Hi,

this is an announcement of a new mailing list for discussing
the issues involved in mapping and visualising computer
networks.

With the growth in complexity of computer networks, mapping is
becoming more important as a visualisation technique and for
finding anomalies.  There are numerous commericial and public
domain tools available but many have serious limitations and
are often specific to a single group of protocols.

RIPE (Reseau IP Europeen) has set up a working group for studying
the problem, this mailing list is intended as a forum for wider
discussions.

To join, send mail to      <ripe-map-request@nic.eu.net>
to contribute send mail to <ripe-map@nic.eu.net>
archives on mcsun.eu.net:~ftp/ripe/archives/ripe-map
Some of the issues for discussion are listed here,

Auto-discovery,
	automatically discovering the topology of computer networks.
	How can this be done, what standards need changing to do this
	efficiently.

Automatic Layout,
	Automatically laying out (or untangling) maps so that they look
	good on in a window or on a piece of paper.  

Features,
	which feaures of existing tools are the best what else is wanted.

Formats,
	in what format should maps be stored and how should they be
	distributed.

Model,
	What database model should be used.  Should it	be concerned
	purely with the graphic represention or should it try to model
	the underlying networks. Different types of map suitable for
	different purposes, what are the catagories.

Other Tools and Standards,
	how can existing tools and protocols be tied in with a mapping
	database.

Symbols,
	Standard symbols for representing network entities.
	How should the status of such entities be drawn.



Regards,
James Barr
	
-- 
James Barr                                        ...............       ......
+31 20-592-5104                                   ...........       ..........
James.Barr@nikhef.nl                              ......        ..............
NIKHEF, Kruislaan 409, 1009DB Amsterdam           ..        ..................

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 91 08:31:59 GMT
From:      k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
To:        comp.protocols.tcp-ip
Subject:   Re: rlogin -> character per packet ?

hsw@COLUMBIA.SPARTA.COM (Howard Weiss) writes:

>You could use telnet in line at a time mode and relieve the burden of
>the remote character per packet echoing.  You run into trouble running
>editors like vi or emacs because you need to send raw characters to
>control the screen.  The Multics tcp/ip implementation defaults to
>line-at-a-time mode and then switches into character-at-a-time when
>going into an application (e.g. emacs) that requires raw character
>input.  When exiting from emacs on Multics the system then switches
>back into line at a time mode to continue with local echoing.

The newest telnet versions (Bsd reno) introduces a new line mode, which
does the correct switching between raw and line mode. The distribution
includes a patch for BSD unix, which is needed for the server side.
The client side can be implemented without the OS patch.

There are not very much systems which have implemented it yet.
The only ones I know: BSD reno, BSD4.4 and CRAY.

Sincerely,
Klaus Steinberger
--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-8046 Garching, Germany
BITNET: K2@DGABLG5P             Internet: k2@bl.physik.tu-muenchen.de

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 91 12:37:20 GMT
From:      eddjp@edi386.UUCP ( Dewey Paciaffi )
To:        comp.protocols.tcp-ip
Subject:   Re: rlogin -> character per packet ?

In article <23Jul91.114841@loverso.leom.ma.us> John Robert LoVerso <john@loverso.leom.ma.us> writes:
>> > I'm doing TCP over a "slow" link (.5 second packet round trip) and the 
>> > typing is painfully slow.
>> 
>> Perhaps someone who has actually implemented (or has hacked on) a TCP
>> implementation can give you a good solution.  Sorry,
>
>TELNET LineMode solves this problem.  See either the RFC and/or the
>freely distributeable BSD telnet/telnetd programs on ucbarpa.berkeley.edu.
>
>The next question is why does your link have such a high delay.  If it
>is a SLIP link, consider using CSLIP.

Thanks to all who've replied. Telnet w/ line mode solves some of the problem,
but of course vi can`t be run.

I'm running the TCP/IP over an SNA network, with a 19.2 serial link, half 
duplex.

I'm doing PU4 (Front End) emulation, in secondary mode. The software
vendor has suggested I run Primary mode (don't wait for polls) and full
duplex. Sounds good to me, but the SNA guys would cut my line speed
in half (9600) to give me full duplex. Sounds like I can't win.

Thanks again for the help.

-- 
Dewey Paciaffi           ...!uunet!edi386!eddjp

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 91 13:20:42 GMT
From:      gary@sci34hub.sci.com (Gary Heston)
To:        comp.protocols.tcp-ip
Subject:   Re: rlogin -> character per packet ?

In article <23Jul91.114841@loverso.leom.ma.us> John Robert LoVerso <john@loverso.leom.ma.us> writes:
 [ ... ]
>The next question is why does your link have such a high delay.  If it
>is a SLIP link, consider using CSLIP.

Does anyone out there have CSLIP ported to SysV3.x for a 386? All the 
packages I see floating around seem to have lots of #include <sun/...>
entries, which isn't on my non-upgradeable ISC 1.0.6. (No, I can't use
anything that tries to talk directly to an AT serial port; I don't have
those on my MultiBus...)

Thanks,

-- 
Gary Heston   System Mismanager and technoflunky   uunet!sci34hub!gary or
My opinions, not theirs.    SCI Systems, Inc.       gary@sci34hub.sci.com
Become a pheresis donor. Loan your blood to the Red Cross for a couple
of hours. They, and cancer patients, will appreciate it.

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 91 14:21:53 GMT
From:      jjensen@convex.UUCP (James Jensen)
To:        comp.protocols.tcp-ip
Subject:   Re: rlogin -> character per packet ?

In article <k2.680344319@woodstock> k2@bl.physik.tu-muenchen.de (Klaus Steinberger) writes:
>
>The newest telnet versions (Bsd reno) introduces a new line mode, which...
>
>There are not very much systems which have implemented it yet.
>The only ones I know: BSD reno, BSD4.4 and CRAY.

And Convex.

Jim Jensen - jjensen@convex.com

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 91 15:21:31 GMT
From:      jackson@bdrc.bd.com (Gene Jackson)
To:        comp.dcom.lans,comp.sys.novell,comp.protocols.tcp-ip,comp.os.msdos.misc
Subject:   Novell vs. Pathworks

Our organization is planning to replace our current 10Net PC network.  
In addition to
MS Dos computers we have MAC's, VAX's, and SUN's.  Currently we use tcp/ip to 
communicate among the various systems (using PC/TCP from FTP sortware 
on the PC's.
We are considering replacing the current PC network with either Novell or 
DEC's Pathworks.

We are interested in comments on either of these networks and especially hearing 
from anyone who has compared the two.



We also would be interested in hearing from anyone using PC/TCP in 
addition to either of these networks.

Gene Jackson
Becton Dickinson Research Center
jackson@bdrc.bd.com

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 91 18:20:29 GMT
From:      rogers@LEGO.GSFC.NASA.GOV (Scott W. Rogers)
To:        comp.protocols.tcp-ip
Subject:   'service' program ?

I am looking for a program similar to the NIC "Service" program.
This program recieves requests via Email and automatically replys
to the sender.

I have a simple version of my own, but would like to see how others
handle some of the reply to Email adressing problems.  I would not
object to scrapping my own and replacing it with a better one, or
adding improvments to my existing one.

I am only interested in sources.  If you are interested in a summary of
my responses, please send me mail direct.  Thanks in advance...
------------------------------------------------------------------------
Scott W. Rogers	<rogers@dftsrv.gsfc.nasa.gov> FTS 888-1377, 301-286-1377
NASA Goddard Space Flight Cntr ADFTO/NSI Code 930.4  Greenbelt, MD 20771
NASA Science Internet - Network Information Center (NSINIC)
------------------------------------------------------------------------

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 91 19:40:09 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: rlogin -> character per packet ?

Some time ago, in who knows what article, Dewey Paciaffi writes:

> I'm doing TCP over a "slow" link (.5 second packet round trip) and the 
> typing is painfully slow.

and, some time later,
In article <172@edi386.UUCP> eddjp@edi386.UUCP ( Dewey Paciaffi ) writes:

>I'm running the TCP/IP over an SNA network, with a 19.2 serial link, half 
>duplex.
>
>I'm doing PU4 (Front End) emulation, in secondary mode. The software
>vendor has suggested I run Primary mode (don't wait for polls) and full
>duplex. Sounds good to me, but the SNA guys would cut my line speed
>in half (9600) to give me full duplex. Sounds like I can't win.

It would have helped if this information had been in the initial posting.
In your present configuration, the transmission time of a minimal TCP segment
should be under 20 milliseconds, so your round trip time of 500 milliseconds is
roughly 10% due to bandwidth limitations and 90% due to "other causes".  I would
speculate that the other causes are precisely the polling latencies inherent in
secondary mode operation.  I would guess that, despite your lament, you would
indeed win big by switching to primary mode, even though you halve the bandwidth.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 91 21:27:28 GMT
From:      gwilliam@SH.CS.NET (George Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: Router (& Bridge) Bashing is baaaack


    Date:    23 Jul 91 03:22:50 GMT
    From:    Scott Bradner <hsdndev!burrhus!isr.harvard.edu!sob@handies.ucar.ed
	      u>
    Subject: Router (& Bridge) Bashing is baaaack

    Well its about that time again, another round of "network interconnection"
    device tests is about to start.  If you have suggestions about the tests or
    want to offer products to be tested please let me know.

[ Disclaimer: Opinions, expressed or otherwise, my own. )
[ Never has there been so much to be tested....by so few ]

My two cents follows.

George Williams

    Tests:
    	throughput: at what speed does the device still pass 100% of offered 
    		packets?
    	packet loss rate:  plot of offered packets vs passed packets up to
    		max speed of media.
    	back-to-back:  how long a burst of packets can the device take
    		before its internal queues cause packets to be dropped?
    	latency: how long does it take to process a packet, test run at
    		throughput rate

response time: Telnet and FTP during some of the scenario's below.

    Details:
    	for a range of packet sizes:
    		max & min for media and some in between
    	for a number of protocols:
    		TCP/IP, OSI, DECnet Phase IV, AppleTalk Phase II, XNS,
    		IPX, bridge mode
    	with & without security filters
    	hope to do multiple addresses in test streams
    	hope to do mixed protocol streams
    	hope to add a test with 10% broadcast packets
    	hope to add a test with 10% error packets
    	hope to do up to 10 streams (on Ethernet)
    	hope to do bidirectional

    	(Yes there are a lot of "hope to"s, the software development is
    	not finished yet.)

    Media:
    	Ethernet, 4MB Token Ring, 16MB Token Ring, FDDI, WAN (T1 & T3)

    Devices:
    	Bridges & Routers

    Test Set Ups:
    	   source side				dest side

                               ------------
    	====Ethernet(s)====|  device  |========Ethernet(s)======
                               ------------

              ---------------
             /               \ ------------
    	<  4MB T. Ring    >|  device  |========Ethernet===========
             \               / ------------
              ---------------

              ---------------
             /               \ ------------
    	<  16MB T. Ring   >|  device  |========Ethernet(s)========
             \               / ------------
              ---------------

              ---------------
             /               \ ------------
    	<     FDDI        >|  device  |========Ethernet(s)========
             \               / ------------
              ---------------

              ---------------                --------------
             /               \ ------------ /              \
    	<     FDDI        >|  device  |<    FDDI        >          
             \               / ------------ \              /
              ---------------                --------------

                           ----------           ----------
        ====Ethernet(s)====| device |-----------| device |====Ethernet(s)====
                           ----------           ----------
                                      T1 or T3


    One problem:
    	after the testing how should the results be grouped?

By vendor. Smacks of commercialism, but this is how we make our choices. We 
don't have a different router for each function, protocol, and or protocol
mix, right ? A customer picks a __ _ , or a #$%%,  and goes with 
them - by name .

Maybe you could weight accordingly, by.....

() protocol support
() reliability
() diagnostic capability
() service support
() manageability
() interoperabilty
() speed
() functionality
() extensibility or flexibility
()......

    	A trade publication test from a while ago tested 4 routers which
    differed widely in function & cost but reported all the results together.
    (As I did last year.) I now think it would be better to group the devices
    somehow, for example:

    	2 port bridges & routers

    	<= 6 port bridges & routers with local connections

    	<= 6 port bridges & routers with WAN connections

    	> 6 port bridges & routers with local connections

    	> 6 port bridges & routers with WAN connections

    any suggestions?

Cisco/Stracomm frame-relay numbers. Can they really handle 10mb ethernet
and 4-16 token ring medium ( 'much heralded'  LAN to WAN bridges ). Are
there buffering and re-transmissions problems ? This probally isn't a fair
test ( beta ) but neither would a SMDS to LAN


Comparision numbers on a 1 meg FTP would be interesting. This would be
done over the range of protcols that support file transfer. I won't
even suggest mutiple streams.

..... A "Router User Group-10" rating, etc. If you do this you will be the
begin to answer the 64k question. How do a choose a ......


Not very origional -:), but what about a test with and without SNMP. The one
thing 'that' publication didn't do was design a test that showed 'relative'
overhead of SNMP protocols on router performance. I believe independent 
evaluations were done for management and routing protocols. The real world 
says that operationally they both co-exist, right; at what cost, if any ?

    When:
    	Tests to start the last week of August & go through the last week
    	of Sept.

    Reports:
    	Report at my Interop tutorial (a bit extra for the $) 
    		and at a BOF (for free).
    	Report to this list by the end of Oct.
    	Raw data on husc6.harvard.edu after posting.

    Test Equipment
    	I've got offers of a bunch of nice test equipment and am banking on
    	some of it.  In particular, Wandel & Goltermann has loaned a DA-30
    	(a real nice box) that will be used for the single stream and
    	latency tests.  Some vendors have offered in-house test equipment
    	for things like FDDI (Timeplex) and Token Ring (Proteon).  Some of
    	the names of the vendors that have offerd equipment can not be posted
    	yet since the test equipment is based on un-announced products, all
    	will be revealed the 2nd week in Oct.

    Reality:
    	I know that in most cases raw performance should not be the one thing
    	that is used to select a router but it is of interest to many and
    	does help if you think that world is going to the data packets as
    	I do.

    Suggestions ( flames etc ) to sob@harvard.edu

    Equipment offers to same address.

    If you HAVE to talk to me:  617-495-3864
      ( why SHOUGHT -:)
    Snail address:	Scott Bradner
    		Harvard University
    		10 Ware St.
    		Cambridge MA 02138
    		


        

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      24 Jul 91 22:39:09 GMT
From:      mcitron@phad.hsc.usc.edu (Mark Citron)
To:        comp.protocols.tcp-ip
Subject:   pd telnet for DOS with int14


Is there a public domain(?) telnet (like NCSA) that supports INT14 
redirection in order to use third party emulators? In short I 
want to emulate an SCO Unix console not a vt100 or the like.

If so, where can I ftp it from?

Thanks,
Mark Citron
-- 
Mark Citron
mark@neurosci.usc.edu

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 91 03:11:34 GMT
From:      dave@ips.oz.au (Dave Horsfall)
To:        comp.protocols.tcp-ip
Subject:   PTY master/slave control

Is it possible to set up a PTY in such a way that the master can be
notified whenever the slave is opened & closed, and take appropriate
action?  For exampe, the open() could block, or return an error.  In
other words, it's sort of a user-level TTY driver.  I have an application
that requires sharing slave PTY's on several machines to the one server.
Someone tries to open the slave, the master is notified which would attempt
a TELNET connection or whatever, and the result reported back.

Thanks for any help.

(It's to do with my recent posting about RTELNET, which although I attempted
to restrict it to Australia still appeared around the world.)

-- 
Dave Horsfall (VK2KFU)         VK2KFU @ VK2RWI.NSW.AUS.OC
dave@ips.OZ.AU                  ...munnari!ips.OZ.AU!dave

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 91 10:31:36 GMT
From:      wswietse@wsbs06.bs.win.tue.nl (Wietse Venema)
To:        comp.protocols.tcp-ip
Subject:   Re: Old Talk Program

leonard@arizona.edu writes:

|Actually, what you want is "New talk" for SunOS.  That should be
|available from Berkeley, though I don't know whether anyone's 
|built it on the Sun.

A SunOS 4 verson lives in ftp.win.tue.nl:/pub/ntalk.sunos4.tar.Z.

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 91 12:28:12 GMT
From:      israel@saturn.informatik.tu-chemnitz.de (Andreas Israel)
To:        comp.protocols.tcp-ip
Subject:   Re: Old Talk Program

leonard@arizona.edu writes:

>Actually, what you want is "New talk" for SunOS.  That should be
>available from Berkeley, though I don't know whether anyone's 
>built it on the Sun.

I installed it (the "New talk") on my Sun and have now both talks running
with no problems (little modification to make the deamons messages unique).

Andreas
--
Name: Andreas Israel  | Chemnitz University of Technology | Email:
Nick: Easy            | Dept. of Computer Science         | ai@tu-chemnitz.de
Phone: +37 71 668 361 | Germany, O-9010 Chemnitz, PSF 964 |
"Think of your family tonight. Try to crawl home after the computer crashes."

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 91 13:02:22 GMT
From:      km11hs@sbuvax.rz.uni-sb.de (Dieter Becker)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   NCSA-Telnet and others on EXCELAN 205T

I installed NCSA-Telnet on a PC (386) with Exelan 205T - card using
the ndis-drivers from ftp.com. NCSA-Telnet works, but other programs
using packet drivers like pcippkt don't work. How can I install the
Driver netdev.sys for working with ndis?
Also QNTVN (for windows) from simtel20 isn't running. 

Can You help me?

Dieter
********************************************************************************
* Dr. med. dipl.-math Dieter Becker          ** Tel.: (0 / +49) 6841 - 16 3046 *
* Medizinische Universitaets- und Poliklinik ** Fax.: (0 / +49) 6841 - 16 3369 *
* Innere Medizin III                         ***********************************
* D - 6650 Homburg / Saar                    ** email:                         *
* ~~~~~~~~~~~~~~~~~~~~~~~                    ** becker@sbuvax.cs.uni-sb.de     *
********************************************************************************

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 91 13:10:17 GMT
From:      fjr@NISC.SRI.COM
To:        comp.protocols.tcp-ip
Subject:   Networked Printers


I am looking for suggestions on how I can place distributed printers on
a TCP/IP network. Specifically, the network will have centralized RISC
workstations running a flavor of UNIX and PC's running TCP/IP. I would
like to be able to place existing printers (serial/parallel) out in the
work areas so that users can send their printouts from the UNIX boxes
and their PCs to these printers. I know that I could use an LPD daemon
on a dedicated PC for each printer, but this seems like an expensive
proposition. Is there any software available that would let me use a
terminal server to do the same job? Any other ideas would be welcome.


thanks for the help.

Frank J. Robey
fjr@mitre.org

Disclaimer: The above views are the authors' and do not represent the
views of The MITRE Corporation or its' sponsors.

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 91 14:34:15 GMT
From:      jmb@ideas.com (Jonathan M. Bresler)
To:        comp.protocols.tcp-ip
Subject:   cslip


we are running a slip connection to the internet over a 9600 baud
dial-up line into PSInet (a business that rents connnections to the 
internet).  slip is run on a mac se/30 with tenon mach ten port
of bsd unix with the mach kernel installed.

what is cslip?
how does it differ from slip?
what performance inprovement can be expected from switching protocols?

jon bresler

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 91 17:09:06 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for configuration suggestions


    The TCP/IP kit I have from Santa Cruz Operation mentions nothing about
    BOOTP.  Can I set this up on the Novell servers?  BOOTP would clearly
    be a winner here.
    
The cheapest platform you can run a BOOTP server on to date is a DOS PC,
using the server available via anonymous FTP from 'tacky.olemiss.edu'.
You'd be a while porting one of the 4bsd BOOTPDs to run on a Netware
server, but you could pick one of your Unix boxes.  The cheapest (and to
my knowlege the only) supported commercial source of a BOOTPD server is'
our PC/TCP for OS/2 product.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 91 17:56:39 GMT
From:      richb@kronos.UUCP (Rich Braun)
To:        comp.protocols.tcp-ip
Subject:   Looking for configuration suggestions

Can I use the software you mentioned to listen on more than one subnet
on a single PC?  If so this might be a winner.  Our configuration has
something like a dozen subnets, and the computer room is small (as is
my budget) so I couldn't put a separate BOOTP server on each subnet.
Thanks for your info and any more you can provide.

-rich

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 91 18:34:54 GMT
From:      gwilliam@SH.CS.NET (George Williams)
To:        comp.protocols.tcp-ip
Subject:   Re: rlogin -> character per packet ?


    Date:    24 Jul 91 12:37:20 GMT
    From:    Dewey Paciaffi <edi386!eddjp@uunet.uu.net>
    Subject: Re: rlogin -> character per packet ?

    In article <23Jul91.114841@loverso.leom.ma.us> John Robert LoVerso <john@lo
    verso.leom.ma.us> writes:
    >> > I'm doing TCP over a "slow" link (.5 second packet round trip) and the
  
    >> > typing is painfully slow.
    >> 
    >> Perhaps someone who has actually implemented (or has hacked on) a TCP
    >> implementation can give you a good solution.  Sorry,
    >
    >TELNET LineMode solves this problem.  See either the RFC and/or the
    >freely distributeable BSD telnet/telnetd programs on ucbarpa.berkeley.edu.
    >
    >The next question is why does your link have such a high delay.  If it
    >is a SLIP link, consider using CSLIP.

    Thanks to all who've replied. Telnet w/ line mode solves some of the proble
    m,
    but of course vi can`t be run.

    I'm running the TCP/IP over an SNA network, with a 19.2 serial link, half 
    duplex.

    I'm doing PU4 (Front End) emulation, in secondary mode. The software
    vendor has suggested I run Primary mode (don't wait for polls) and full
    duplex. Sounds good to me, but the SNA guys would cut my line speed
    in half (9600) to give me full duplex. Sounds like I can't win.
Hmm....


You don't need full duplex for any of the following tuning -


Ask your SNA GUYS:
1) What bracket protocols are in use, if any, for this PU type. I don't recall
   if this is any option for PU4. Using bracket protocols allow you to 
   "BID" on a per RU ( message ) basis. Thus you don't need to get permission
   to send data, you just send it with "Begin Braket" set. If it get rejected 
   the algorithm says send again based on some pre-determined interval.

   The above is an SNA alternative to polling or a " BID " to the PLU every 
   time you want to send something. 

   

2) Also check your maximum RU ( message ) and BIU ( packet ) size permitted. 
   I think ( it's been a  while ) these are VTAM or NCP ( thats you ) sysgen
   options. You may be doing fragmentation across these boundaries or one or
   them may be large causing latency and or unwanted fragmentation to occur a 
   per message basis.
  
   Rememeber SNA is not streams or byte oriented. The architecture best
   facilitates transfer of buffers or screens of data.

3) As a last resort look at "IPR" ( isolated pacing response ) interval
   and the response protocols that are in affect.

   You may be able to get by with "exception" if you are using "definite"
   response mode for each exchange.

It aint easy tuning SNA for IP but these are some of the areas that should
( and most people don't - sheer adversion I suppose ) be considered. If you 
are a PU4 you should have the power to request a ' look and see '. 

[ Disclaimer: All view and opinions mine (and short, This subject, this list) ]

Good luck,

  George Williams

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 91 18:43:09 GMT
From:      ks@rvl4.ecn.purdue.edu (Kirk Smith)
To:        comp.protocols.tcp-ip,comp.unix-wizards
Subject:   dialup PPP

Is anyone using PPP in a "on demand" dialup scenario under SunOS4.1.1?
In going through network archives, I found an apparently older SLIP
from BBN with dialup support, and a newer PPP with Van Jacobson header
compression and good performance and streams support.  It appears to me that
the BBN stuff is an older SLIP with no streams support and may not be the best
because of that.

I have not found software that supports all of the above (PPP, dialup on
demand, SunOS4.1.1 streams).

    Where should I be looking?
    Please respond via mail.

					Kirk Smith
					ks@ecn.purdue.edu

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 91 19:53:59 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: rlogin -> character per packet ?

In article <k2.680344319@woodstock> k2@bl.physik.tu-muenchen.de (Klaus Steinberger) writes:
> The newest telnet versions (Bsd reno) introduces a new line mode, which
> does the correct switching between raw and line mode. The distribution
> includes a patch for BSD unix, which is needed for the server side.
> The client side can be implemented without the OS patch.

No!

When the SunOS 4.0.3 telnet talks to the BSD 4.3-Reno-and-later telnetd
in line mode, the protocol simply fails. Whenever the tty changes mode,
echo fails. Job control keystrokes are not passed through. The only
solution is to turn off line mode. Conclusion: The client side must be
patched as well.

Even when both client and server support line mode, TIOCSTI is not
passed through. So, for instance, you can't edit the headers in standard
UCB Mail.

Given these incompatibilities, I expect a growing flood of complaints
from users as more and more line mode servers are installed. This is not
the recipe for a successful protocol: no matter how much line mode might
reduce the network load, most users will learn to do ``mode character''
rather quickly.

---Dan

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      25 Jul 91 21:17:32 GMT
From:      ejohnson@wolf.cs.washington.edu (Eric Johnson)
To:        comp.protocols.tcp-ip
Subject:   Adding a host

I have just been given the reposibility of adding an Altos 5000 system to our
network. I did all the configurations and whatnot, and most everything 
works fine. The problem I have now, though, is that from the Altos I can 
rlogin, telnet, or whatever anywhere on our net just fine, but when I 
try to rlogin (or telnet) TO the Altos, I get the usual login prompts, but
after I enter username and password, the system says:

Terminal is disabled - See Account Administrator

I know this is probably a simple problem, but I am new at this and I would
appreciate any insights into getting this problem fixed. Everything else
works fine (i.e. ping is ok, so is FTP). Thanks in advance. Please respond 
via E-mail.

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 91 07:16:28 GMT
From:      smart@manta.mel.dit.csiro.au (Robert Smart)
To:        comp.protocols.tcp-ip
Subject:   Usage accounting problems

I have just read the Internet draft on accounting. I don't think
IP accounting can be done correctly without a minor change to IP.
Since a new version of IP will be needed soon (more address bits)
it is a good time to be thinking about what else we need.

First some observations

1. Any accounting for IP packets which is designed to report on
usage, particularly if that reporting may influence charging,
should report packets as they _leave_ the public network. Not fair
to count packets dropped internally in the public network.
[Previous sentence no verb.]*

2. Network suppliers need to be able to charge the users of
international links more than they charge people who only use
local links in their own city. This can be achieved with a
minor variation on flat-fee payment. The idea is to get the user
to estimate her use of International and long-line National
links and then charge her on the basis of her estimate. If
usage reporting disagrees with the estimates then the user and
supplier can either renegotiate or look for the problem (such
as NS loop).

3. But for (2) to work we need some way to distinguish for each
packet whether it should be counted as belonging to the sending or 
to the receiving network.

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

The proposed extensions to IP are:

1. An IP packet can include a "reverse charge grant option" plus a
random "magic number". The details of this are noted by the router/METER
of the public network.

2. Subsequently the host that receives the  "reverse charge grant"
can include a "reverse charge" option which quotes that magic
number. This will modify the accounting of the METER as the packet
exits the public network.

3. Magic numbers time out if not refreshed for a while. If they
have timed out the router returns an ICMP "reverse charge no longer
valid" error [and the packet doesn't leave the public network so
isn't counted].

4. A reverse charge call is initiated by sending a packet with a
reverse charge option and a magic number of 0. The router/METER that
connects the public network to the destination may or may not be
configured to allow that reverse charge packet: presumably according
to the arrangement between the recipient and the network company.
The recipient host may be able to tell the router which sources addresses
should be able to initiate reverse charge calls in this way.

So why would anyone bother to send a "reverse charge grant"? Suppose
the major anonymous ftp sites refused to accept anonymous ftp unless
the request packet came with a reverse charge grant? Software 
supporting the reverse charge grant would then spread like wildfire
through the Internet.

The nice thing about this system is that it lets hosts continue to
do nice things like provide anonymous ftp services and act as an
e-mail gateway/hub without the usage being docked against their
network.

Bob Smart <smart@mel.dit.csiro.au>

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 91 12:18:05 GMT
From:      scanlon@interlan.Interlan.COM (Mike Scanlon)
To:        comp.protocols.tcp-ip
Subject:   Re: Networked Printers

Yo daemon,

Racal Interlan's NTS 200 has exactly the function you are looking for.
This terminal server when one of its ports (the printer connection) is
configured for tcp print queueing (it also does LAT print queueing) works
with configured Unix Host's lpd to provide an integrated network printing 
solution with as many Unix host systems as you like.  Racal provides a simple
output filter which you will use when you set up your host lpd.  If you are
interested call 1-800-LANTALK (Racal's customer hotline) for more details.
				Mike Scanlon

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 91 13:52:03 GMT
From:      stev@FTP.COM (stev knowles)
To:        comp.protocols.tcp-ip
Subject:   Re: Can you drop the packet that caused the ARP?


    From RFC1122:
    
             2.3.2.2  ARP Packet Queue
    
                The link layer SHOULD save (rather than discard) at least
                one (the latest) packet of each set of packets destined to
                the same unresolved IP address, and transmit the saved
                packet when the address has been resolved.
                           
                DISCUSSION:
                     Failure to follow this recommendation causes the first
                     packet of every exchange to be lost.  Although higher-
                     layer protocols can generally cope with packet loss by
                     retransmission, packet loss does impact performance.
                     For example, loss of a TCP open request causes the
                     initial round-trip time estimate to be inflated.  UDP-
                     based applications such as the Domain Name System are
                     more seriously affected.
    
    ``SHOULD'' means ``this is what we recommend, but you're not required
    to comply''.

actually, it is a bit more complex than that. MUST means you have to do
something, not matter what. this is viewed as the minimum accecptable
behavior. i fyou dont do one of the MUSTs, you can not say you follow the
RFC. some people refer to this as "conditionally" compliant. the next level
is SHOULD, things that you really, honestly, should do to have a reasonable
product. as an example, a routing protocol is not necessary for a router in
the absolute sense, alot of people run large networks without routing
protocols (we did here until recently). but, to have a reasonable router,
you really gotta have a routing protocol, so SHOULD is there. machines that
follow the SHOULD guidelines are "unconditionally compliant".


are more verbose explanation happens in the router requirements draft, at
the usual places, in the internet-drafts directory, with a name like:
draft-ieft-rreq.txt.00.


    

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 91 14:12:53 GMT
From:      juanra@dit.upm.es (Juan Ramon Velasco Perez)
To:        comp.sys.novell,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   EXCELAN 205T



Hello,


We have a lan with several PC's and UNIX workstations. PC's use NOVELL netware
2.15, and UNIX ws. TCP-IP.

The ethernet board we have in the PC's is WD8003E and we use BYU packet driver
to integrate both NOVELL and TCP-IP.

Then, our autoexec.bat's seem like:


WD8003E param1 param2 ... paramn            ; The Western Digital PD
IPXPD					    ; The BYU IPX PD
NET3					    ; Novell shell.

Now we have got several PC's with EXCELAN EX0S 205T lan cards, and we want to
integrate them in that network. The problem we have is that we can not find
any packet driver for this card (we have looked at Clarkson, and several other
sites, but we didn't find any).

Does anybody know where can we find it?

Thanks a lot in advance

Juan R. Velasco

============================================================================
Juan R. Velasco         	     	       e-mail:   jvelasco@dit.upm.es
Assistant Professor             	  		
Dpto. Ing. Sis. Telematicos                 
ETSI Telecomunicacion	 	               tel: +34 1 5495700 (ext. 368)  
Ciudad Universitaria			            +34 1 5495762 (ext. 368)  
E-28040  MADRID               		       fax: +34 1 5432077
SPAIN                       		       tlx: 47430 ETSIT E
............................................................................
	       HH
	       HH     
      OOOOOOOOOHH>>>>>swords are always worse than words>>>>>>>>>>
               HH 
	       HH
============================================================================

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 91 15:17:15 GMT
From:      mckee@SMILEY.MITRE.ORG ("H. Craig McKee")
To:        comp.protocols.tcp-ip
Subject:   Configuration Management

I would appreciate any pointers to a software configuration management
package that runs on a VAX 4000 w/VMS.  The package would be used by
the SysAdmin to show location, wiring, configuration, and version 
information of the VAX 4000, 5 terminal servers, and 40 user stations.  
Each station has a VT-320, and printer.

Thanks - Craig

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 91 16:10:54 GMT
From:      root@utoday.com
To:        comp.protocols.tcp-ip,comp.protocols.nfs,comp.protocols.iso,comp.infosystems,comp.groupware,comp.dcom.lans,comp.protocols.misc,alt.test,comp.unix.misc
Subject:   Question for net.views column in UNIX Today!


QUESTION #6:

	What are the key interoperability issues facing users today?


------------------------------------------------------------------------
	This question is being posted to gather responses for a regular
column in UNIX Today! called "net.views". The purpose of the column
is to generate user response to questions of importance in the Unix
industry. 
	By sending an e-mail reply to the above question, you are
granting UNIX Today! permission to consider your comments for
publication. A summary of *all* e-mail responses to this post will be
posted in this two weeks from today.
	/* Please include a daytime telephone number! */
------------------------------------------------------------------------

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 91 17:29:18 GMT
From:      matt@zeuswtc.sbi.com (Matthew Gutherz ISG)
To:        comp.protocols.tcp-ip
Subject:   behavior when receiving >1 ARP REPLY


I seem to recall that a host is supposed to keep the last ARP REPLY it
receives when it receives more than one reply to a request.  I've looked
through a number of RFCs but can't find a reference to this.  Could
someone out there provide me with a reference either for or against.

Thanks

Matt	matt@zeus.sbi.com	gutherz.jove.rutgers.edu

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 91 18:47:54 GMT
From:      volkoff@isi.ethz.ch (Serge Volkoff)
To:        comp.mail.misc,comp.protocols.tcp-ip,comp.unix.misc,comp.unix.wizards
Subject:   TALK (Unix-to-Unix, Unix-to-VMS)

Don't know if this is a local problem or not.  When I type
"talk user@host.domain.edu" it displays a split screen, then says
"No connection yet", then "Checking for invitation on caller's machine",
and stops there.  No requests appear on the other end.  I have tried
this with a number of machines, running both Unix and VMS (I am using
Unix here) and the result is always the same.  Telnet works fine with
all of the machines I tried to connect to using TALK.  But it works
locally and is supposed to work over Internet!

What is wrong with the TALK here?

Thanks,
--Serge

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 91 18:59:26 GMT
From:      jbvb@ftp.com (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for configuration suggestions

One if the powers of BOOTP (vs. RARP) is that in a subnetted environment
you don't need a server on each net.  This depends on the IP Routers for
each subnet knowing where the server(s) are, and forwarding the BOOTP Request
broadcasts from each individual subnet to the servers.  High-end routers can
be expected to do this, low-end routers may not.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 91 19:34:29 GMT
From:      jdeitch@jadpc.cts.com (Jim Deitch)
To:        comp.protocols.tcp-ip
Subject:   Help with Wollongong WIN/TCP

I am having a problem with WIN/TCP v4.0.1 when trying to read from or
write to a socket.  Here is what happens:

I tried to compile Smail 3.21 and got everything to compile correctly.
I invoke the daemon and it runs.  When another machine tries to write
to the port, I get an error like this:

421 ncr_tower  Lost input channel

The port opens correctly, I get the smtp banner.  I get the same error
when trying to deliver mail through the port.  As long as the other
system doen't write anything back to this machine, all is well.

The target system is an NCR Tower 32/600.  It is running SystemV
3.0.1.  If anyone knows of something that is amiss or different in the
Wollongong TCP, please pass it along.

I don't get this group here, so if you would please e-mail your
response, I would be grateful.  I will summarize to the net if asked.

Thanks,
Jim

-- 
ARPANET:    jadpc!jdeitch@nosc.mil
INTERNET:   jdeitch@jadpc.cts.com
UUCP:	    nosc!jadpc!jdeitch
FIDONET:    Jim_Deitch@f723.n202.z1.fidonet.org  (1:202/723)

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 91 22:56:07 GMT
From:      barmar@think.com (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: behavior when receiving >1 ARP REPLY

In article <569@zeuswtc.sbi.com> matt@zeuswtc.sbi.com (Matthew Gutherz ISG) writes:
>I seem to recall that a host is supposed to keep the last ARP REPLY it
>receives when it receives more than one reply to a request.  I've looked
>through a number of RFCs but can't find a reference to this.  Could
>someone out there provide me with a reference either for or against.

This follows from the original ARP specification in RFC826.  Whenever you
receive an ARP packet you are supposed to update your ARP cache with the
information it contains.  This can happen even if you haven't sent an ARP
request (some systems broadcast an ARP reply when they boot, and if a
system has an interface that supports changing the hardware address it's
probably a good idea to broadcast an ARP reply when doing this).
-- 
Barry Margolin, Thinking Machines Corp.

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

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 91 23:45:51 GMT
From:      coates@UC780.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   DuBois

DuBois references literally hundreds of Egyptolologists, anthroplogists and
archeaologists in "The World and Africa". It does not surprise me you do not
see the doctor listed.
In fact, the above mentioned text would be something many would want to
suppress and not want to believe the info therein.

Again, DuBois' statements are based on studying hundreds of experts, what are
your assertions that Egypt had no major impact on the world based on? [And that
means there are literally hundreds of footnotes in "The World and Africa"]

Also, DuBois acknowledged that a mature civ in Asia Minor or other civs may have
preceded that in Egypt but he and others assert on the basis of evidence that
the Egyptian civ was a direct progenitor of mature European civ. As I quoted
him writing in my message.

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      26 Jul 91 23:55:42 GMT
From:      coates@UC780.UMD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: DuBois

OOoops! This subject obviously shouldn't have been posted here.
Please excuse.
Thanks.

-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 91 01:42:18 GMT
From:      eps@toaster.SFSU.EDU (Eric P. Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: rlogin -> character per packet ?

>The newest telnet versions (Bsd reno) introduces a new line mode, which
 
>There are not very much systems which have implemented it yet.
>The only ones I know: BSD reno, BSD4.4 and CRAY.

Add NeXT to your list.

					-=EPS=-

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 91 04:20:19 GMT
From:      bgodot@pro-smof.cts.com
To:        comp.protocols.tcp-ip
Subject:   Where can one find TCP-IP and OSI specs?

Recently, I've been involved in (actually, been dragged into)
compu-tech discussions about system interconnectivity.  I have been
beaten about the head with the terms TCP-IP and OSI.

Where can I find the specs or at least detailed definitions of TCP-IP
and OSI?
Are they available via ftp?

Please e-mail responses because I do not have direct access to this
newsgroup.

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 91 14:05:00 GMT
From:      CSYSMAS@MVS.OAC.UCLA.EDU (Michael Stein)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: behavior when receiving >1 ARP REPLY

> This follows from the original ARP specification in RFC826.  Whenever you
> receive an ARP packet you are supposed to update your ARP cache with the
> information it contains.

Except perhaps on IBM source routed token ring.  In that case
there may (will) be multiple paths which result in multiple ARP
replies.  Taking the last of the group results in "slowest (and
perhaps longest) source route" preference.

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      27 Jul 91 18:43:08 GMT
From:      mike@gordian.com (Michael Thomas)
To:        comp.protocols.tcp-ip
Subject:   TCP Urgent data


-- 


  I have an implementation question about the TCP Urgent Data pointer,
which I have tried to figure out from the RFC's but still couldn't resolve.
When you see that the Urgent bit is set in the TCP header and the Urgent
data pointer is set such that the urgent data starts at a yet unreceived
part of the stream, what are you supposed to do with the data in between?
Clearly if you have buffering for say 4k and the urgent pointer is set for
8k in the future this poses a real difficulty for buffering the data stream.
Are you supposed to ditch the data, and read up to where the urgent data 
starts, or is there some other mechanism that I'm not seeing? 


		Michael Thomas	(mike@gordian.com)
		USnail: 20361 Irvine Ave
		        Santa Ana Heights, Ca,
			92707-5637
		PaBell: (714) 850-0205
			(714) 850-0533 (fax)
		____________________________________________
		
	        "I don't think Bambi Eyes will get you that
		 flame thrower..."  -- Hobbes to Calvin

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 91 21:13:01 GMT
From:      jtw@lcs.mit.edu (John Wroclawski)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

In article <15335@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:

	 If I understand the question, I don't believe the answer I saw is true.
   If we're talking about TCP buffering, the important point is that urgent data
   is delivered out of order.

Um, I must disagree. TCP urgent data does -not- provide a separate
out-of-order data channel. A valid urgent data pointer (URG bit set in
the TCP packet) points to the last byte of data -in the regular data
stream- that is "urgent".

When urgent data is present, the receiving TCP layer is responsible
for notifying its application of this fact as soon as possible. The
-application-, upon receiving this indication, may choose to go into
an "urgent mode", reading through the TCP data stream as fast as
possible, perhaps discarding data it would have otherwise used, until
it has processed all of the urgent data. The TCP must provide a way
for the application to determine that it has reached the end of the
urgent data.

It is entirely up to the application how to process data read from the
TCP stream when it is in urgent mode. Typically the receiving
appication discards most of the transmitted data, but still pays
attention to any command information transmitted by the sender, so
that it won't be confused when it comes out of urgent mode. The TELNET
protocol's use of urgent data and the telnet Data Mark to do output
buffer flushing is a good example.

4.2BSD contained code which attempted to use the urgent data pointer
as a pointer to a single byte of out-of-band data, which was pulled
out of the middle of the data stream and delivered separately. Among
other problems, this did not work because the arrival of later packets
could move the urgent pointer at any time, and the Berkeley code treated
only the current value of the urgent pointer as urgent data. Protocols
which attempted to use this code failed when a second urgent message
was sent before the first was processed at the receiver. 

Later versions of BSD added the SO_OOBINLINE option to the socket
interface. This option allows TCP urgent data to be handled correctly.

Summary: TCP is responsible for delivering an -indication- of the
presence of urgent data to the application. TCP is responsible for
telling the application how much urgent data there is. The application
is responsible for reading all data, in order, from the data channel,
and processing urgent data in any way it desires. No data is delivered
to the application out of order. No data is thrown away by TCP. Urgent
data has no real effect on the buffering or flow control of the TCP
data stream.

The host requirements RFC (1122), section 4.2.2.4, describes some fine
points pretty well.

				-john

John Wroclawski
MIT Lab for Computer Science
jtw@lcs.mit.edu

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 91 21:19:58 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

In article <148@gordius.gordian.com> mike@gordian.com (Michael Thomas) writes:
>When you see that the Urgent bit is set in the TCP header and the Urgent
>data pointer is set such that the urgent data starts at a yet unreceived
>part of the stream, what are you supposed to do with the data in between?

Whatever you think is most appropriate.  The answer is application-specific.

>Clearly if you have buffering for say 4k and the urgent pointer is set for
>8k in the future this poses a real difficulty for buffering the data stream.

Yup.  If you can't afford to buffer it and can't afford to throw it away,
you're using the Urgent facility when you should be using some other method,
e.g. having a separate TCP connection for urgent traffic.
-- 
Arthritic bureaucracies don't tame new  | Henry Spencer @ U of Toronto Zoology
frontiers. -Paul A. Gigot, WSJ, on NASA |  henry@zoo.toronto.edu  utzoo!henry

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      28 Jul 91 22:42:02 GMT
From:      js3b+@andrew.cmu.edu (James Vincent Schultz)
To:        comp.protocols.tcp-ip
Subject:   ftpd (unix -> mac)?


Does there exist a mac application to emulate a ftp server, so that
from a unix box I could ftp to my mac and get/put files?

Thanks,

James
js3b@andrew.cmu.edu

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 00:59:51 GMT
From:      gray@hawkmoon.MN.ORG (Bill Gray)
To:        comp.unix.xenix.sco,comp.dcom.lans,comp.preotocols.tcp-ip
Subject:   Re: Implementing ftp and telnet under SCO Xenix.

daveh@marob.uucp (Dave Hammond) writes:

>We are interested in setting up ftp and telnet services between two 386
>machines running SCO Xenix 2.3.2.  Given that we have no experience with
>implementing network services (other than uucp), can someone recommend a
>software package, interface cards and wiring scheme which would be simple
>to install and configure, reliable and relatively inexpensive?
 
>Information about software and components to avoid would also be
>appreciated.

Try not to wind up with Excelan Ethernet cards, because software to drive them
under SCO Xenix is hard to get.  (I think the cards are discontinued, so
unless you deal with closeout specialists, you're probably ok.)

Western Digital and 3COM both make "dumb" Ethernet cards for which SCO has
drivers available.

BTW:  There's nothing wrong with the Excelan card.  But Excelan sold the
Unix software to Novell, who discontinued it.  SCO has a new TCP/IP product
in beta test that is supposed to drive the Excelan card, but as of ten days
ago, a friend who is a beta tester said it isn't there yet.

If you do already have Excelan cards, it is possible to get the discontinued
Excelan software on the Novell label.  It's called LAN WorkPlace for SCO
Xenix V/386 (or something very close to that).  I understand it can be
obtained from a company called Federal Technologies.  Idunno where they are
or whether they are any fun to deal with.  I was even told that Novell
can be persuaded to part with a copy, but you really gotta grovel and accept
that there ain't gonna be no support.  Ever.

Where I work, there is a major development project running with the Excelan
205T and SCO Xenix.  It seems to work ok for most things.  But you can kiss
NFS goodbye forever if you use SCO Xenix.  SCO Unix supports it, but SCO
has apparently capped Xenix development except for bug fixes and so on.

Good luck.

Bill
gray@hawkmoon.mn.org

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 02:00:53 GMT
From:      vanepp@newsserver.sfu.ca (Peter Van Epp)
To:        comp.protocols.tcp-ip
Subject:   LPR driver for HP plotter

Anyone know of a LPR (or other Unix type!) plotter driver (or a more
suitable list to ask this on!)? We have an HP draftmaster II currently
driven from a mainframe and are moving over to Unix and need to be able
to spool plots to the plotter from a TCP/IP network, preferably being
able to queue plots with different paper sizes and with different pen
selections.

Peter Van Epp / Peter_Van_Epp@cc.sfu.ca

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 02:19:28 GMT
From:      vanepp@newsserver.sfu.ca (Peter Van Epp)
To:        comp.protocols.tcp-ip
Subject:   Re: LPR driver for HP plotter


Lets try this again, since the first one only seems to contain my
signature! We are interested in a driver that can spool plots from a
TCP/IP network (from Unix boxes Macs and PCs) to a HP draftmaster II
plotter. I would guess that LPR would be the best choice but we need to
be able to spool plots for different paper sizes and different pen
selections (or at least we would like to be able since we do now!)
to be released by the operators when the plotter is set up. I would
appreciate even directions to a better group (if there is one!) to ask
this question in as well as any responses. Thanks in advance.

Peter Van Epp / Peter_Van_Epp@cc.sfu.ca
_

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 02:22:09 GMT
From:      bmiller@CABELL.VCU.EDU (Bryan Miller)
To:        comp.protocols.tcp-ip
Subject:   (none)


Several months ago someone posted some information on a program
that would show active tcp connections, along with the port numbers
and user accounts.  I think the program was called pff or something 
like that.  At the time, I got a copy of the program and compiled it.

Since then, we have added a DEC 5500 running Ultrix 4.2 and want to
once again run this same program.  However, I deleted the source coude
and can't remember where I got it from....can someone help me?

Thanks,

Bryan Miller

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 02:49:28 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data


	If I understand the question, I don't believe the answer I saw is true.
If we're talking about TCP buffering, the important point is that urgent data
is delivered out of order. It doesn't matter if there is buffered data on
either the send or receive side-- the urgent data should be sent and delivered
promptly. The rest stays in buffers on either side until the consumer reads
enough for the buffers to empty. So, first of all, the sender need not wait
until he has emptied all data earlier in the sequence space from his send
buffer before sending the urgent data (in fact, it shouldn't wait) and the
receiver likewise need not and should not wait until it has consumed all data
in the receive buffer space before processing the urgent data. Further, the
receiver is required to be able to handle at least one byte of urgent data
even if the window is completely closed.
	Urgent data also implies PUSH, which is supposed to empty buffers as
quickly as possible, but that doesn't mean dropping anything. The only time
you should have any trouble is when you have more urgent data itself than you
can buffer, but the normal data stream all goes through the window constraints
and is unaffected by urgent data. Since urgent data is generally 1 byte (esp.
since BSD machines can't receive or generate more than 1 byte of urgent data),
as long as the application handles the urgent data before more comes in, the
urgent data and all the rest of the data stream is delivered intact, and
reliably.
[Begin blatant plug]
	Check out Chapter 15 of "Internetworking with TCP/IP volume II" Comer &
Stevens, Prentice-Hall 1991, for a detailed description of an implementation of
urgent data handling, along with a (IMHO) reasonable interpretation of those
parts of the RFC that are vague or unspecified.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 05:09:40 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

Something I've always wondered about:

Are there any applications which actually benefit from TCP's out-of-band
(rather, out-of-band indicator) facilities?

I know, most TELNET implementations *use* urgent data, but they don't
*benefit* from it---the queue length is, in practice, never long enough
that OOB data gets delivered measurably faster than normal data.

Are there other applications where this isn't true---where there is so
much data flowing back and forth that OOB actually makes a difference?
I've never understood why TCP had all this complexity when there were no
obvious benefits.

``All this complexity?'' you smirk. ``It's a trivial feature.'' Maybe
so, but it's been responsible for a lot of interoperability problems and
even more confusion. Also, whenever someone is deluded into believing
that it provides large gains, his code ends up not only unportable, but
unusable over different communications mechanisms. What proven advantage
justifies these problems?

---Dan

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 06:09:22 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

In article <JTW.91Jul28211301@mercury.lcs.mit.edu>, jtw@lcs.mit.edu (John Wroclawski) writes:
> Um, I must disagree. TCP urgent data does -not- provide a separate
> out-of-order data channel. A valid urgent data pointer (URG bit set in
> the TCP packet) points to the last byte of data -in the regular data
> stream- that is "urgent".

	If you assume that urgent data is all data between RCV.NXT and the
urgent pointer, then you're right. But, if you assume the urgent data is some
(potentially) smaller piece, and your TCP user interface has a mechanism for
reading the data out of order, then the application is not required to process
or discard pending "normal" data prior to the urgent data.
	In other words, it is only "application specific" if your TCP user
interface makes it so. The Berkeley interface, which certainly has other
problems, allows asynchronous *processing* of urgent data, and so the
application never *has* to synchronously process, as you said it does. You
can argue that it isn't TCP, but rather the Operating System, that is giving
you the asynchronous processing, but the point is that you still don't have
to discard pending normal data, which was the original question. In effect,
the Operating System is choosing how the applications can treat urgent data,
which makes it implementation-specific, but NOT application-specific.
	In my implementation, you can process urgent data asynchronously,
with multiple bytes of urgent data, or you can process it synchronously, by
reading all the intervening "normal" data. This doesn't differ from either
RFC 793 or RFC 1122 and doesn't *require* an application to discard data or
process it synchronously; urgent data can be delivered and processed promptly
whether or not the sender and/or receiver buffers are full of normal data.
	Only if you're using the vanilla example TCP user interface, or
interpreting all pending data as urgent data while in urgent mode, is what
you've described necessary, and I know of at least two implementations (BSD
and mine) that don't require it.
	From the user's point of view, asynchronous processing via out-of-
order delivery is much more useful.

-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 07:36:10 GMT
From:      emv@OX.COM (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   list of IETF working groups in compact format (1wg-compact-summary)

Suitable for grepping through, this is derived from the working group
summary nnsc.nsf.net:/ietf/1wg-summary.txt.  If I can find a similar
source of information for the RIPE groups I will post.

Consider this a very draft list, which should expire on 1 September
1991 if not otherwise updated.  It should be recreatable from
1wg-summary but I couldn't whip up the code to pick out the group
areas so handily; if those are marked a little better in that document
the next version of this will be a little shell script for you to
create it for yourself.

-- 
Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
       MSEN, Inc. 628 Brooks Ann Arbor MI 48103 +1 313 741 1120

ietf.applications.chronos	Distributed Scheduling Protocol 
ietf.applications.smtpext	Internet Mail Extensions 
ietf.applications.822ext	Internet Message Extentions 
ietf.applications.netdata	Network Database 
ietf.applications.netfax	Network Fax 
ietf.applications.nntp		Network News Transport Protocol 
ietf.applications.npp		Network Printing Protocol 
ietf.applications.telnet	TELNET 
ietf.internet.cip	Connection IP 
ietf.internet.dhc	Dynamic Host Configuration 
ietf.internet.appleip	IP over Appletalk 
ietf.internet.fddi	IP over FDDI 
ietf.internet.mmb	Multi-Media Bridging 
ietf.internet.pppext	Point-to-Point Protocol Extentions 
ietf.internet.rdisc	Router Discovery 
ietf.internet.rreq	Router Requirements 
ietf.internet.shr	Special Host Requirements 
ietf.net-manage.bridge	Bridge MIB 
ietf.net-manage.charmib	Character MIB 
ietf.net-manage.decnetiv	DECnet Phase IV MIB 
ietf.net-manage.fddimib	FDDI MIB 
ietf.net-manage.hubmib	IEEE 802.3 Hub MIB 
ietf.net-manage.acct	Internet Accounting 
ietf.net-manage.msi	Management Services Interface 
ietf.net-manage.oim	OSI Internet Management 
ietf.net-manage.rlanmib	Remote LAN Monitoring 
ietf.net-manage.snmp	Simple Network Management Protocol 
ietf.net-manage.x25mib	X.25 Management Information Base 
ietf.osi.osinsap	Assignment of OSI NSAP Addresses 
ietf.osi.noop	Network OSI Operations 
ietf.osi.osids	OSI Directory Services 
ietf.osi.osigen		OSI General 
ietf.osi.osix400	OSI X.400 
ietf.osi.oda		Office Document Architecture 
ietf.osi.x400ops	X.400 Operations 
ietf.operations.bmwg	Benchmarking Methodology 
ietf.operations.ddniwg	DDN Interconnectivity 
ietf.operations.njm	Network Joint Management 
ietf.operations.opstat	Operational Statistics 
ietf.operations.tewg	Topology Engineering 
ietf.operations.ucp	User Connectivity 
ietf.routing.bgp	Border Gateway Protocol 
ietf.routing.iplpdn	IP over Large Public Data Networks 
ietf.routing.isis	ISIS for IP Internets 
ietf.routing.idpr	Inter-Domain Policy Routing 
ietf.routing.mospf	Multicast Extentions to OSPF 
ietf.routing.ospf	Open Shortest Path First IGP 
ietf.security.cipso	Commercial Internet Protocol Security Option 
ietf.security.cat	Common Authentication Technology 
ietf.security.spwg	Internet Security Policy 
ietf.security.snmpsec	SNMP Security 
ietf.security.ssphwg	Site Security Policy Handbook 
ietf.transport.dfs	Distributed File Systems 
ietf.transport.dns	Domain Name System 
ietf.transport.svrloc	Service Location Protocol 
ietf.user-services.disi	Directory Information Services Infrastructure 
ietf.user-services.userglos	Internet User Glossary 
ietf.user-services.noctool2	NOC-Tool Catalogue Revisions 
ietf.user-services.nisi	Network Information Services Infrastructure 
ietf.user-services.uswg	User Services 
ietf.general		Internet Engineering Task Force
ietf.iesg		Internet Engineering Steering Group

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 10:17:08 GMT
From:      roes@phcoms.seri.philips.nl (Aloys Roes)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   "421 <service name> Service not available ..." from Excelan software.

I know the Excelan hardware/software is old stuff by now but we still have
several systems with their TCP/IP. On our site we have 2 VAXes, one with an
EXOS 204 and one with a 304 board. Everything works fine on the EXOS 204
system. The EXOS 304 system however has the problem that only one 
incoming connection to one of the servers in the server.dat file is
accepted i.e. only one incoming FTP or SMTP or RSH connection is accepted.
All subsequent requests get the message "421 <service> Service not
available, closing transmission channel" Incoming telnet is ok (not done via
server.dat file).

We have had this problem for some time but since it was impossible to get
proper support for Excelan and nobody really complained, I didn't bother too
much. But now another system manager in our company told me that he had this
exact similar problem but for the fourth incoming connection.

Has anybody experienced the same problem and is there a fix. We have VMS 5.1
and Excelan (or Lan-service) release 3.5. Any help will be appreciated.

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

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 13:14:00 GMT
From:      dmbarton@ralvmm.vnet.ibm.com ("Daniel M. Barton")
To:        comp.protocols.tcp-ip
Subject:   behavior when receiving >1 ARP REPLY

This depends on the media, but in general the first reply is used, and
a short timer is used to prevent additional replies from replacing the
first reply.

This is especially important for IBM Token Ring, using source-routed
bridges.  Hosts will send an ARP Request with All routes broadcast,
single route return.  The destination host will reply to all the ARP
Requests it receives through all the different paths through the bridged
token ring network.  In our network, the destination could receive up
to 8 possible paths.  The sender will then receive 8 ARP Replies, and
must pick the most efficient path.

The first reply is assumed to be the best, and use the fewest number of
bridges.  Some of our code would use the last reply received, which
naturally was the worst, and could potentially travel through 10 bridges
instead of just 4.

Daniel

=====-=====-=====-=====-=====-=====-=====-=====-=====-=====-=====-=====-=====

Daniel M. Barton
TCP/IP Development
IBM Research Triangle Park, NC

Internet:  dmbarton@ralvmm.vnet.ibm.com
           dmbarton%ralvmm@vnet.ibm.com

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 14:09:11 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: SLIP vs CSLIP? (was Re: rlogin -> character per packet ?)

In article <1991Jul26.173038.13939@apertus.mn.org> rayk@apertus.mn.org (Ray Kinnamon) writes:
   What's the word on SLIP vs CSLIP?  I haven't heard of it before.
   Where would one look for information on CSLIP or comparisons
   between the two?

Serial Line IP (SLIP) is a nonstandard but widely-used IP packet
encapsulation scheme described in RFC 1055.  It has been obsoleted by
the Internet standard Point to Point Protocol (PPP), described in RFCs
1171 and 1172.  See the Deficiencies section of 1055 and the
Introduction of 1171 for a comparison.

"CSLIP" usually refers to a SLIP implementation that incorporates VJ's
TCP header compression algorithm, described in RFC 1144.  Most PPP
implementations also incorporate header compression.

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 15:01:08 GMT
From:      smb@ulysses.att.com (Steven Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

In article <22858.Jul2905.09.4091@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> Something I've always wondered about:
> 
> Are there any applications which actually benefit from TCP's out-of-band
> (rather, out-of-band indicator) facilities?
> 
> I know, most TELNET implementations *use* urgent data, but they don't
> *benefit* from it---the queue length is, in practice, never long enough
> that OOB data gets delivered measurably faster than normal data.

You've never tried using a version of TCP without it, obviously.  I have...

Yes, you need it.  You'd be surprised at how much longer it takes to get
the remote end to shut up when you hit INTR if you don't have out-of-band.

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 16:03:24 GMT
From:      jjensen@convex.UUCP (James Jensen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

In article <22858.Jul2905.09.4091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>Something I've always wondered about:
>
>Are there any applications which actually benefit from TCP's out-of-band
>(rather, out-of-band indicator) facilities?
>
>I know, most TELNET implementations *use* urgent data, but they don't
>*benefit* from it---the queue length is, in practice, never long enough
>that OOB data gets delivered measurably faster than normal data.
>
>Are there other applications where this isn't true---where there is so
>much data flowing back and forth that OOB actually makes a difference?
>I've never understood why TCP had all this complexity when there were no
>obvious benefits.
>
>``All this complexity?'' you smirk. ``It's a trivial feature.'' Maybe
>so, but it's been responsible for a lot of interoperability problems and
>even more confusion. Also, whenever someone is deluded into believing
>that it provides large gains, his code ends up not only unportable, but
>unusable over different communications mechanisms. What proven advantage
>justifies these problems?
>
>---Dan

It is quite possible to take advantage of urgent data to make telnet
more robust, easier to read, and more responsive. Unfortunatly bsd4.2 didn't 
follow the rfcs.  This means that every subsequent implementation has to
contain the same work arounds. 

I believe that the interoperability problems can almost all be traced to
4.2`s failure to follow the rfc, and an amiguity in the IP spec for
where the urgent pointer is supposed to point.

Jim Jensen - jjensen@convex.com

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 16:32:57 GMT
From:      freeman@ux1.cso.uiuc.edu (Jay Freeman)
To:        comp.protocols.tcp-ip
Subject:   Re: ftpd (unix -> mac)?

js3b+@andrew.cmu.edu (James Vincent Schultz) writes:


>Does there exist a mac application to emulate a ftp server, so that
>from a unix box I could ftp to my mac and get/put files?
 
>Thanks,
 
>James
>js3b@andrew.cmu.edu

Yes NCSA Telnet is available for the Mac. I'm not sure where you can get it,
however (sorry :() as our copy came with our Gatorbox (Appletalk-ethernet bridge).  

-- 
*************************************************************************
* 73 de Jay, WT9S     Internet: freeman@ux1.cso.uiuc.edu                *
*                     Packet:   wt9s@n9hhi.il.usa.na                    *
*************************************************************************

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 17:32:46 GMT
From:      bob@MorningStar.Com (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

In article <22858.Jul2905.09.4091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
   ...the queue length is, in practice, never long enough that OOB
   data gets delivered measurably faster than normal data.

Queue lengths tend to be longer in the thinwire world than in T3-land.
Never say "never."

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 17:41:23 GMT
From:      chip@chinacat.unicom.com (Chip Rosenthal)
To:        comp.protocols.tcp-ip
Subject:   wanted - simple lp client

I'm looking for a stripped down tool which will talk to a remote lp
server.  I don't particularly need an entire BSDish lp system; this
is something I'd like to throw into a SysVish printer interface script
to punt the job across the network to a system which understands the
lp protocol.  Any pointers?  Send mail; I'd be glad to summarize if
there's interest.
-- 
Chip Rosenthal  512-482-8260  |  Lotus 1-2-3 for UNIX...it's a product
Unicom Systems Development    |  you don't have to support.
<chip@chinacat.Unicom.COM>    |    - recent Lotus 1-2-3 advert

-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 17:42:23 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

In article <15339@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>In article <JTW.91Jul28211301@mercury.lcs.mit.edu>, jtw@lcs.mit.edu (John Wroclawski) writes:
>> Um, I must disagree. TCP urgent data does -not- provide a separate
>> out-of-order data channel. A valid urgent data pointer (URG bit set in
>> the TCP packet) points to the last byte of data -in the regular data
>> stream- that is "urgent".
>
>	If you assume that urgent data is all data between RCV.NXT and the
>urgent pointer, then you're right. But, if you assume the urgent data is some
>(potentially) smaller piece, and your TCP user interface has a mechanism for
>reading the data out of order, then the application is not required to process
>or discard pending "normal" data prior to the urgent data.

I have to agree with Mr. Wroclawski, the TCP Urgent mechanism is not
an out-of-band data stream, it is an out-of-band *indication* of (the
trailing end of) in-band urgent data.  Certainly, the authors of RFC929
also agree when they say:
	As we currently understand it, TCP's URGENT feature provides an
	INband signal rather than a true out-of-band signal (and at
	least one of us deeply regrets this).  The actual URGENT bit is
	sent out-of-band, but it contains an URGENT pointer which
	relates the URGENT to its position in the data stream.

This is also the view taken in RFC983, where ISO TP expedited data
(which *is* out-of-band) is implemented over TCP by using a second TCP
connection, to avoid having
	                     ... the TSAP peer manage a set of buffers
	independent from TCP.  The peer would, upon indication of TCP
	urgent information, have to buffer all preceeding TPKTs until the
	TCP buffer was empty.  Expedited data would then be given to the
	TS-user.  When the expedited data was flushed, then the buffered
	(non-expedited) data could be passed up to the receiving user.

	

>	In my implementation, you can process urgent data asynchronously,
>with multiple bytes of urgent data, or you can process it synchronously, by
>reading all the intervening "normal" data. This doesn't differ from either
>RFC 793 or RFC 1122 and doesn't *require* an application to discard data or
>process it synchronously; urgent data can be delivered and processed promptly
>whether or not the sender and/or receiver buffers are full of normal data.

If you want to give the receive side the added ability to pull urgent data out
of sequence, no one should flame you, although since the beginning of urgent
data is not marked in the stream I don't understand how such a scheme can
handle the RFC1122 requirement that:

	 A TCP MUST support a sequence of urgent data of any length.

In general, the application *has* to read sequentially to find where the
urgent data begins.

I think it is clear that even if the out-of-band option is offered,
the receiving TCP must also be able to process in-band, otherwise
how could one implement the Telnet requirement (RFC1123)

         When it receives "urgent" TCP data, a User or Server Telnet
         MUST discard all data except Telnet commands until the DM (and
         end of urgent) is reached.

Also, if the reading of some data out of order is allowed, several places
in RFC793 insist that the urgent indication must persist until the reader
consumes all the normal data preceding it.  That is, the position of the
urgent pointer must still be remembered even if the urgent data is
read out-of-order.

Finally, the transmit side policy suggested above, and explicitly
described in an earlier posting from the same source:

    >So, first of all, the sender need not wait
    >until he has emptied all data earlier in the sequence space from his send
    >buffer before sending the urgent data

is not correct.  The sender sends urgent data in sequence.
When SEND call processing is described in RFC793, page 56,
the only difference between urgent and non-urgent data transmission
is this bit of post-processing:

      If the urgent flag [i.e., parameter to the SEND call] is set,
      then SND.UP <- SND.NXT-1 and set the urgent pointer in the
      outgoing segments.

If this permits out-of-order transmission for urgent data then
it must permit it for non-urgent data, too.

>	From the user's point of view, asynchronous processing via out-of-
>order delivery is much more useful.

As Henry Spencer suggested, if you want out-of-order delivery you should
use a second connection.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 18:18:17 GMT
From:      mmoini@HNS.COM (Mike Moini)
To:        comp.protocols.tcp-ip
Subject:   timing of the ICMP messages


Hi all;
Does anybody know if it is faster/slower to use ICMP messages, for
example echo request, over a simple TCP or UDP send? If so by roughly how much?

thanks
Mike Moini (mmoini@hns.com)

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 19:00:27 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data


	Though it certainly isn't clearly stated in RFC 793, it does indicate
that RCV.NXT is the beginning of the urgent data:

  "This mechanism permits a point in the data stream to be designated as
  the end of urgent information.  Whenever this point is in advance of
  the receive sequence number (RCV.NXT) at the receiving TCP, that TCP
  must tell the user to go into "urgent mode"; when the receive sequence
  number catches up to the urgent pointer..."

	This means the same as SEG.SEQ when taken in the context of the
assumption for the purposes of the RFC description that packets are delivered
to TCP in sequence order, but most implementations in fact process segments in
the order delivered. Thus, using RCV.NXT is inappropriate, but SEG.SEQ of the
packet containing the urgent pointer is the beginning, and the urgent pointer
itself is the end of urgent data. An interpretation that says "RCV.NXT even in
out of order processing" would result in the sender having no control over
what is urgent data and what is not! This is one of the "reasonable
assumptions" that I was talking about-- that out-of-order *TCP* processing
results in the same user-level stream as if the packets were deliver in-order.
	Now, a TCP that processes the segments out of order, rather than
sequencing them prior to delivering them to TCP, has two choices on receipt
of the urgent data. It can notify the application and sit on it until it
comes up in the normal data stream (no choice, if the user interface has only
a read() mechanism and no out-of-order delivery mechanism), or it can deliver
it separately to the user via an extended TCP interface that allows urgent data
to be read promptly, without requiring every application to redo the TCP
buffering at the application level.
	My implementation, and Berkeley's, provides the mechanism for getting
the urgent data promptly without disrupting the normal stream.

	Now, if an implementation delivers urgent data promptly, as likely
the most common one does (4BSD), sending the urgent data regardless of the
windowing constraints is the desirable thing to do. This obviously isn't a 
gross violation of the intent, since:

  "However, even when the receive window is zero, a TCP must
  process the RST and URG fields of all incoming segments."

	Clearly, this line wouldn't make sense if in all cases the urgent
data had to be inside the window, which disagrees directly with your statement
that urgent data is subject to window constraints. Then the appropriate action
would be to drop the segment without processing the URG field.
	I stand by my interpretation, and while I agree that the TCP RFC's
don't require it, it is a poor implementation that doesn't allow an application
to receive and process urgent data asynchronously. Either way, my
implementation will still interoperate with those that treat urgent data
differently, since it'll end up in the window, eventually, and be retransmitted
if you dropped it the first time around. The differences is that applications
using asynchronous delivery will actually get the benefits of prompt delivery
that is the intent in the first place.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 19:37:06 GMT
From:      oberman@ptavv.llnl.gov
To:        comp.protocols.tcp-ip
Subject:   Re: ftpd (unix -> mac)?

In article <1991Jul29.163257.5734@ux1.cso.uiuc.edu>, freeman@ux1.cso.uiuc.edu (Jay Freeman) writes:
> 
> Yes NCSA Telnet is available for the Mac. I'm not sure where you can get it,
> however (sorry :() as our copy came with our Gatorbox (Appletalk-ethernet bridge).  
 
Get NCSA Telnet V2.4 from ftp.ncsa.uiuc.edu. It is BINHEXed and STUFFITed and
comes in two flavors, one for use with MacTCP (I recommend that one) and one
that runs without it. The latter may not interact well with other software
doing IP.

Also on line is teh complete doc set (in WORD) and the sources. The software is
PD. (Yes, really PD. Says so right up front.)

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.

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 21:18:18 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

In article <15367@mentor.cc.purdue.edu> dls@mentor.cc.purdue.edu (David L Stevens) writes:
>
>	Though it certainly isn't clearly stated in RFC 793, it does indicate
>that RCV.NXT is the beginning of the urgent data:
>
>  "This mechanism permits a point in the data stream to be designated as
>  the end of urgent information.  Whenever this point is in advance of
>  the receive sequence number (RCV.NXT) at the receiving TCP, that TCP
>  must tell the user to go into "urgent mode"; when the receive sequence
>  number catches up to the urgent pointer..."
>
>	This means the same as SEG.SEQ when taken in the context of the
>assumption for the purposes of the RFC description that packets are delivered
>to TCP in sequence order, but most implementations in fact process segments in
>the order delivered. Thus, using RCV.NXT is inappropriate, but SEG.SEQ of the
>packet containing the urgent pointer is the beginning, and the urgent pointer
>itself is the end of urgent data.

I think you are responding to me here, so I will have another kick at
the cat:

Obviously we don't see eye to eye about the meaning of this section.
The simple implementation described in RFC 793 does not provide any
system buffering on the receive side, so RCV.NXT above really refers
to "the point up to which the application has read".  This is supported
elsewhere in the RFC, where it says

	The receiving TCP will signal
	the urgent condition to the receiving process if the urgent
	pointer indicates that data preceding the urgent pointer has not
	been consumed by the receiving process.

Now, if there is system buffering, it clearly makes no sense to associate
the receiving application's read point with the start of urgent data.

Also, I think that it is unsafe to treat segment boundaries as "record
marks", particularly when

	The sending TCP ... may repackage segments on the
	retransmission queue.

and considering that the urgent data may be arbitrarily large, so may
span several maximum-size segments.  Even if it doesn't, it is still the
case that

	The method employs a urgent field which is carried in all segments
	transmitted.

and not just in segments that actually contain urgent data.  I'm afraid I
can't agree that SEG.SEQ is a reliable indicator of anything meaningful.

Instead, I suggest re-reading the first sentence of your extract above.
The mechanism communicates the position of *one* end-point of the urgent
data.  It simply doesn't tell you where the start is.  In fact, if more than
one hunk of urgent stuff is sent, it only tells you where the last one ends.
If you need to know more than that, you have to use in-band markers to
indicate the boundaries.

>	Now, if an implementation delivers urgent data promptly, as likely
>the most common one does (4BSD), sending the urgent data regardless of the
>windowing constraints is the desirable thing to do. This obviously isn't a 
>gross violation of the intent, since:
>
>  "However, even when the receive window is zero, a TCP must
>  process the RST and URG fields of all incoming segments."
>
>	Clearly, this line wouldn't make sense if in all cases the urgent
>data had to be inside the window, which disagrees directly with your statement
>that urgent data is subject to window constraints.

OK, I misinterpreted you.  I thought you were talking about sending the
urgent data with an out-of-sequence sequence number (if you catch my drift).
I would, however, amend your statement to "send the urgent *indicator*
regardless of the windowing constraints".  The indicator and the data
do not have to be in the same segment.  And, if you send out-of-window data,
the receiving TCP must process the URG field and urgent pointer, but would
be perfectly justified in throwing the data away.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 21:23:16 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

In article <15222@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes:
> You've never tried using a version of TCP without it, obviously.  I have...
> Yes, you need it.  You'd be surprised at how much longer it takes to get
> the remote end to shut up when you hit INTR if you don't have out-of-band.

I haven't used a TCP without urgent data, but my (pre-1123) TELNET
implementations don't use it. When you hit INTR, they send IP, then (by
default) flush all data until the server responds up to DM. There are no
surprises, because as far as the user can tell, the server shuts up
instantly. (I was happy to see that RFC 1123 recommended this practice.
The user can turn off the flushing, of course, but what sane user would
want to do so? In fact, what sane TELNET client implementation would do
anything other than flush data as soon as it sent IP?)

Several people have used this example already. I wonder how many of them
have actually implemented TELNET, and how many of them are simply
repeating the common dogma that OOB makes a difference.

I ask again: Are there any applications where OOB is beneficial?

---Dan

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      29 Jul 91 21:27:13 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

In article <BOB.91Jul29133240@volitans.MorningStar.Com> bob@MorningStar.Com (Bob Sutterfield) writes:
> In article <22858.Jul2905.09.4091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>    ...the queue length is, in practice, never long enough that OOB
>    data gets delivered measurably faster than normal data.
> Queue lengths tend to be longer in the thinwire world than in T3-land.
> Never say "never."

I regularly work over a cross-country connection which approximately 10%
of the time provides throughput under 3KB/sec. What most people don't
seem to understand is that it's the *client* queue length, *not* the
server queue length, which matters for TELNET IP and AO. Do you type
3KB/sec?

---Dan

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 00:25:18 GMT
From:      jjensen@convex.UUCP (James Jensen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

In article <11062.Jul2921.23.1691@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>Several people have used this example already. I wonder how many of them
>have actually implemented TELNET, and how many of them are simply
>repeating the common dogma that OOB makes a difference.
>
>I ask again: Are there any applications where OOB is beneficial?
>
>---Dan

I implemented telnet on the Gould(now Encore) real time OS.  I used
Urgent data, and upon discovering that bsd-4.2 didn't had to retrofit.

If telnet does it's own buffering then urgent data is unnecessary.
At first I didn't have to buffer the reads from the client.  Then
I did.  Not earth shattering, but urgent data can be beneficial, I think.

Jim Jensen - jjensen@convex.com

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 06:00:29 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: (none)

In article <9107290222.AA22106@cabell.vcu.edu> bmiller@CABELL.VCU.EDU (Bryan Miller) writes:
> Several months ago someone posted some information on a program
> that would show active tcp connections, along with the port numbers
> and user accounts.  I think the program was called pff or something 
> like that.  At the time, I got a copy of the program and compiled it.
> Since then, we have added a DEC 5500 running Ultrix 4.2 and want to
> once again run this same program.  However, I deleted the source coude
> and can't remember where I got it from....can someone help me?

Yes. pff is part of my kernel-reading package, kstuff. Version 0.18 of
the package is available for anonymous ftp from stealth.acf.nyu.edu
(which is down at the moment) in pub/hier/kstuff. One of the extant
versions of ofiles (not the comp.sources.unix version) can also locate
network connections, as can any version of fstat, but pff is more
flexible, more powerful, more port-able, and more port-ed than ofiles or
fstat. Version 0.20 is taking shape; it includes a MORE/BSD port, an
Encore port from Icarus Sparry, an AOS port from Timothy Miller, several
new features, a noticeably faster pff, and some new applications.

---Dan

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 08:24:43 GMT
From:      anthes@geocub.UUCP (Franklin Anthes)
To:        comp.protocols.tcp-ip
Subject:   Sub standard FTP implementation


The company I work for has acquired FTP software that doesn't implement
the CWD, LIST or NLST commands. This seems to me to be a sub standard
implementation and causes a lot of problems with FTP clients that want
to be nice to the user (Macintosh point and click style).

I looked through RFC959 trying to find a place where a mandatory set of commands
would be defined. The only thing RFC959 seems to say is that some commands
are optional (CDUP,SMNT, etc.), but none seem to be mandatory. Not even
STOR or RETR!

Have I missed something, or was this left out of the RFC on purpose?

-- 

	Frank Anthes-Harper :  Bien le bonjour de la France
	anthes@geocub.greco-prog.fr

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 12:46:37 GMT
From:      cei@took.enet.dec.com
To:        comp.protocols.tcp-ip
Subject:   Applications do benefit from TCP's out-of-band dat

TELNET certainly DOES benefit from urgent data.  My TELNET CLient
implementation is capable of sending commands (e.g. IP, AO,etc.) with
or without urgent.  WHAT A DIFFERENCE - with urgent is much faster!

Carol Iturralde

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 13:58:12 GMT
From:      ZZT@STC10.CTD.ORNL.GOV (Jon Tischler, Solid State Div.)
To:        comp.protocols.tcp-ip
Subject:   Re: ftpd (unix -> mac)


James Schultz writes:

> Does there exist a mac application to emulate a ftp server, so that
> from a unix box I could ftp to my mac and get/put files?
>  
> Thanks,

The NCSA Telnet (available from zaphod.ncsa.uiuc.edu) is available for the
Macintosh and besides telnet, it supports ftp in the server mode only.  


    Jon Tischler         zzt@ornl.gov

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 14:38:54 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data


    ... if you have buffering for say 4k and the urgent pointer is set for 8k
    in the future this poses a real difficulty for buffering the data stream.
    Are you supposed to ditch the data, and read up to where the urgent data 
    starts, or is there some other mechanism that I'm not seeing? 

Your TCP shouldn't offer a Window larger than you have buffering for.  The
other end can't send data (even if it is Urgent) beyond the Window you offer.
The TCP also doesn't have any guarantee you'll actually get the data until it
has it in hand, and it isn't supposed to pass data up until it has been ACKed,
which means that you need all the data ahead anyway.

So, the application remains unaware until 1) the Urgent pointer is within
the Window offered by the TCP, 2) the data is actually received, and 3) any
missing segments in the current receive window are retransmitted so the
TCP can ACK at or beyond the Urgent pointer.  Whether or not the application
reads the Window worth of data immediately ahead of the Urgent pointer is
a local (application, API) matter.

Apropos of the question asked later, I am not aware of any generally used
combination of application, segment size, TCP Window and round-trip-time
which makes Urgent worth the effort...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 14:43:55 GMT
From:      ejackson%sedofis%sed@CUNYVM.CUNY.EDU
To:        comp.protocols.tcp-ip
Subject:   INFO



REQUESTING 30 Q/A FOR WEEK.

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 15:10:02 GMT
From:      mcitron@phad.hsc.usc.edu (Mark Citron)
To:        comp.protocols.tcp-ip
Subject:   net14 redirector

Is anyone using the DOS based net14 redirector to redirect int14 to
a tcp/ip network. I am not sure I fully understand what it is supposed
to do.

Thanks
Mark Citron
~
-- 
Mark Citron
mark@neurosci.usc.edu

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 16:31:29 GMT
From:      mike@gordian.com (Michael Thomas)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

In article <15339@mentor.cc.purdue.edu>, dls@mentor.cc.purdue.edu (David L Stevens) writes:
[stuff deleted]
|> 	If you assume that urgent data is all data between RCV.NXT and the
|> urgent pointer, then you're right. But, if you assume the urgent data is some
|> (potentially) smaller piece, and your TCP user interface has a mechanism for
|> reading the data out of order, then the application is not required to process
|> or discard pending "normal" data prior to the urgent data.
|> 	In other words, it is only "application specific" if your TCP user
|> interface makes it so. The Berkeley interface, which certainly has other
|> problems, allows asynchronous *processing* of urgent data, and so the
|> application never *has* to synchronously process, as you said it does. You
|> can argue that it isn't TCP, but rather the Operating System, that is giving
|> you the asynchronous processing, but the point is that you still don't have
|> to discard pending normal data, which was the original question. In effect,
|> the Operating System is choosing how the applications can treat urgent data,
|> which makes it implementation-specific, but NOT application-specific.
|> 	In my implementation, you can process urgent data asynchronously,
|> with multiple bytes of urgent data, or you can process it synchronously, by
|> reading all the intervening "normal" data. This doesn't differ from either
|> RFC 793 or RFC 1122 and doesn't *require* an application to discard data or
|> process it synchronously; urgent data can be delivered and processed promptly
|> whether or not the sender and/or receiver buffers are full of normal data.
|> 	Only if you're using the vanilla example TCP user interface, or
|> interpreting all pending data as urgent data while in urgent mode, is what
|> you've described necessary, and I know of at least two implementations (BSD
|> and mine) that don't require it.
|> 	From the user's point of view, asynchronous processing via out-of-
|> order delivery is much more useful.
|> 
|> -- 
|> 					+-DLS  (dls@mentor.cc.purdue.edu)

 I agree that, normally, not all of the data in between the current stream
head and the urgent pointer are likely to be Urgent, however, I don't see
where your're argument spares *any* application from the nessesity of having
buffer the data in between RCV.NXT and RCV.NXT+Urgent *if* it doesn't desire
to lose bytes. In the case of urgent data, the maximum amount "out of band"
extra buffering you would need is (64k - open-queue-size) Per occurrence of
urgent data, glech. 
 Sadly this just seems to be a deficiency in TCP -- trying to get out-of-band
from a mechanism that just ain't up to the job...

-- 


		Michael Thomas	(mike@gordian.com)
		USnail: 20361 Irvine Ave
		        Santa Ana Heights, Ca,
			92707-5637
		PaBell: (714) 850-0205
			(714) 850-0533 (fax)
		____________________________________________
		
	        "I don't think Bambi Eyes will get you that
		 flame thrower..."  -- Hobbes to Calvin

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 16:56:05 GMT
From:      mike@gordian.com (Michael Thomas)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

In article <11062.Jul2921.23.1691@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
|> In article <15222@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes:
|> > You've never tried using a version of TCP without it, obviously.  I have...
|> > Yes, you need it.  You'd be surprised at how much longer it takes to get
|> > the remote end to shut up when you hit INTR if you don't have out-of-band.
|> 
|> I haven't used a TCP without urgent data, but my (pre-1123) TELNET
|> implementations don't use it. When you hit INTR, they send IP, then (by
|> default) flush all data until the server responds up to DM. There are no
|> surprises, because as far as the user can tell, the server shuts up
|> instantly. (I was happy to see that RFC 1123 recommended this practice.
|> The user can turn off the flushing, of course, but what sane user would
|> want to do so? In fact, what sane TELNET client implementation would do
|> anything other than flush data as soon as it sent IP?)
|> 
|> Several people have used this example already. I wonder how many of them
|> have actually implemented TELNET, and how many of them are simply
|> repeating the common dogma that OOB makes a difference.
|> 
|> I ask again: Are there any applications where OOB is beneficial?
|> 
|> ---Dan

-- 

The reason that your response is normally instantaneous is that you 
(the typist) typically don't have much of a problem with overflowing the
telnetd's receive queue (window). If data path congestion were a problem
(suppose you had a send window size of say 10 bytes) then you would be 
screwed, ie the sending TCP wouldn't be able to send your IP telnet command
which would lead to a kind of deadlock situation. 
  Where I am actually coming from on this entire issue is having a telnet
command which can provide say modem status and control. Here the problem
*really* does exist since the sending TCP (ie the host system) is constantly
bumping against the slower (modems) receive window. Here it is probably 
unacceptable to say "I'll hangup the modem whenever he gets around to reading
it...". For getting status the problem is even worse, since you probably don't
want to disturb the data stream (especially if you are just checking up on it)
but you Do want to be insured the response is deterministic. A true out-of-band
mechanism is really what is nessasary here, (or maybe SNMP??).


		Michael Thomas	(mike@gordian.com)
		USnail: 20361 Irvine Ave
		        Santa Ana Heights, Ca,
			92707-5637
		PaBell: (714) 850-0205
			(714) 850-0533 (fax)
		____________________________________________
		
	        "I don't think Bambi Eyes will get you that
		 flame thrower..."  -- Hobbes to Calvin

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 17:04:37 GMT
From:      kenn@intrbasintrbas.UUCP (Kenneth G. Goutal)
To:        comp.protocols.tcp-ip
Subject:   another networked-printer question

I didn't see the original question in the recent "networked printers" thread,
but from the replies it sounds different from my question...

I have an HP-UX box (one of three) that has no printer and no print queue.
We have several Suns and several Apollos that have printers attached
and print queues or spoolers or whatever to go with them.

Is there a straigthforward way I can set things up so that I can say
something like "lpr <filename>" on the HP and have it come out on the
Apollo's or Sun's printer?

-- Kenn Goutal

Interbase Software Corporation
209 Burlington Road			...!linus!intrbas!kenn
Bedford  MA  01730  USA			...!mcsun!uunet!intrbas!kenn
617.275.3222				kenn@interbase.COM

                All standard network disclaimers apply.

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 17:17:47 GMT
From:      kenn@intrbasintrbas.UUCP (Kenneth G. Goutal)
To:        comp.protocols.tcp-ip
Subject:   anonymous ftp via mail

This probably isn't the best group in which to post this, but I can't figure
out a better one, and an article posted here made me think of it.  I would
welcome a suggestion of a better group in which to post this.

I see many articles go by that say things like "foo is available via
anonymous ftp from bar@gag.dom.dom".  However, we are not (yet) on the
"connected Internet" (as Comer calls it).  I have heard that many such sites
have something set up so that one can send email via uucp,
requesting that the file be sent via return email.
Can anyone provide a list of sites that do this?
Is there essentially just one protocol for doing this,
and, if so, what is it?

Thanking you for your patience,
-- Kenn Goutal

Interbase Software Corporation
209 Burlington Road			...!linus!intrbas!kenn
Bedford  MA  01730  USA			...!mcsun!uunet!intrbas!kenn
617.275.3222				kenn@interbase.COM

                All standard network disclaimers apply.

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 18:30:55 GMT
From:      bstring@MAINZ-EMH2.ARMY.MIL (BOB STRINGFIELD)
To:        comp.protocols.tcp-ip
Subject:   MMDF Checkque Definition

Could someone explain facts, particulars and circumstances causing
the output of the enclosed file.  File was obtained by running
a checkque of MMDFII Ver S04-01-00 as I wanted to see what mail
was queued since the system is currently experiencing severe
connectivity problems.  

Incidentally I am not the SA but an Analyst in the Info Mgt Ofc.
As such I have become accustomed to the benefits of networking but
since last Wed it has been impossible to access anyone except
some MILNET sites and not all of them as the enclosed will verify.
Any ideas or clues as to what causes this problem.  


Tue Jul 30 10:07:  17 queued msgs / 1984 byte queue directory
		   22 Kbytes in msg dir


  0 msgs    0 Kb (local   ) local           :  Local Delivery
		  deliver start             :  Tue Jul 30 10:05
		  deliver message           :  Tue Jul 30 10:05
		  deliver end               :  Tue Jul 30 10:05 / 0 hours

  0 msgs    0 Kb (list    ) list            :  Mailing List Processor
		  deliver start             :  Tue Jul 30 09:57
		  deliver message           :  Tue Jul 30 09:57
		  deliver end               :  Tue Jul 30 09:57 / 0 hours

 16 msgs   13 Kb (smtp    ) smtp            :  SMTP channel
		  deliver start             :  Tue Jul 30 10:05
		  deliver message           :  Tue Jul 30 10:00
		  deliver end               :  Tue Jul 30 10:00
		  pickup start              :  Tue Jul 30 08:28
		  pickup message            :  Tue Jul 30 08:35
		  pickup end                :  Tue Jul 30 08:35 / 1 hour
  *** INCOMPLETE **
  *** WAITING **  First message             :  Wed Jul 24 06:07
    vm1.nodak.edu                    (  6)  :  Wed Jul 24 07:14  ** BLOCKING **
    pucc.princeton.edu               (  2)  :  Wed Jul 24 06:07  ** BLOCKING **
    indycms.iupui.edu                (  3)  :  Wed Jul 24 07:43  ** BLOCKING **
    ben-harris-onet.army.mil         (  1)  :  Thu Jul 25 07:19  ** BLOCKING **
    merit.edu                        (  1)  :  Wed Jul 24 10:31  ** BLOCKING **
    ucbvax.berkeley.edu              (  1)  :  Wed Jul 24 12:41  ** BLOCKING **
    pentagon-bcn.army.mil            (  1)  :  Thu Jul 25 08:05  ** BLOCKING **
    westpoint-emh2.army.mil          (  1)  :  Thu Jul 25 08:24  ** BLOCKING **
*****NOTE:  Hardware is Sperry 5000/80 running the military version
of Unix 5.3.  

In addition since we are have connectivity problems no list mail
since Wed 24 Jul 91 so please route all responses to me at my
alternative address - bstring%mainz-emh2.army.mil@wsmr-simtel20.army.mil


***********************************************************************
Robert (Bob) L. Stringfield, Computer Systems Analyst
Mainz Army Depot
Directorate, Management Information Systems (D/MIS)
ATTN:  SDSMZ-I
APO NY 09185
COML (No ETS or Autovon available): 06131-696328 (Germany)
FAX: 06131-696467
Electronic Mail:  bstring@mainz-emh2.army.mil
Alternative:  bstring%mainz-emh2.army.mil@wsmr-simtel20.army.mil
Truth:  IGNORANCE hates knowledge....

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 19:15:24 GMT
From:      donp@na.excelan.com (don provan)
To:        comp.protocols.tcp-ip
Subject:   Re: Sub standard FTP implementation

In article <3625@geocub.UUCP> anthes@geocub.UUCP (Franklin Anthes) writes:
>I looked through RFC959 trying to find a place where a mandatory set
>of commands would be defined. The only thing RFC959 seems to say is
>that some commands are optional (CDUP,SMNT, etc.), but none seem to be
>mandatory. Not even STOR or RETR!

RFC-959, section 5.1, "Minimum Implementation", Page 43.  The
mandatory commands are user, quit, port, type, mode, stru, retr, stor,
and noop.  So an implementation without list and nlst is legal, just
not very useful.
						don provan
						donp@novell.com

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 19:58:04 GMT
From:      beame@maccs.dcss.mcmaster.ca (Carl Beame)
To:        comp.protocols.tcp-ip
Subject:   Re: Networked Printers

In article <9107251310.AA06400@dec-netman-k.mitre.org> fjr@NISC.SRI.COM writes:
>
>I am looking for suggestions on how I can place distributed printers on
>a TCP/IP network. Specifically, the network will have centralized RISC
>workstations running a flavor of UNIX and PC's running TCP/IP. I would
>like to be able to place existing printers (serial/parallel) out in the
>work areas so that users can send their printouts from the UNIX boxes
>and their PCs to these printers. I know that I could use an LPD daemon
>on a dedicated PC for each printer, but this seems like an expensive
>proposition. Is there any software available that would let me use a
>terminal server to do the same job? Any other ideas would be welcome.
>
>
>thanks for the help.
>
>Frank J. Robey
>fjr@mitre.org
>
>Disclaimer: The above views are the authors' and do not represent the
>views of The MITRE Corporation or its' sponsors.
>
>

	You could solve this by using a background LPD daemon running on
PCs over the network. I known of two background LPDs.

	1) PC-NFS from Sun has a background LPD. it supports multiple printers
	   and takes an additional 130K of DOS memory.

	2) BW-NFS from Beame & Whiteside Software Ltd. has a background LPD
	   which supports only one printer, but only takes 6K of memory.


 Over vendors have LPDs, but I'm not sure whether they run in the backgournd.

- Carl Beame
Beame & Whiteside Software Ltd.

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 21:00:22 GMT
From:      pds@CS.CMU.EDU (Peter Stout)
To:        comp.protocols.tcp-ip
Subject:   Communication Failure Rates

I am looking for information on the packet loss rates for wide area
networks, in particular, how these rates compare to local area
networks.  Please mail any citations to (pds+@cs.cmu.edu).  If others
are interested in the information, let me know and I will post a summary.

					Thank you,

					Peter Stout

-- 
Peter D. Stout, +1 412 268-3066
School of Computer Science, Carnegie Mellon, Pittsburgh, PA 15213-3890
Internet: pds+@cs.cmu.edu		Uunet: ...!seismo!cs.cmu.edu!pds+
Csnet: pds+%cs.cmu.edu@relay.cs.net	Bitnet: pds+%cs.cmu.edu@carnegie

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      30 Jul 91 21:06:08 GMT
From:      henry@zoo.toronto.edu (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous ftp via mail

In article <247@intrbas.UUCP> kenn@intrbasintrbas.UUCP (Kenneth G. Goutal) writes:
>... I have heard that many such sites
>have something set up so that one can send email via uucp,
>requesting that the file be sent via return email.
>Can anyone provide a list of sites that do this?

The first question to ask is not "what sites do this?" but "do my uucp
neighbors permit such bulk traffic to flow over their modems?".  Connections
provided for mail are *not* necessarily suitable for FTP.  Assuming that
they are, without asking, is a serious mistake that can cause your
neighbors a lot of headaches.
-- 
Arthritic bureaucracies don't tame new  | Henry Spencer @ U of Toronto Zoology
frontiers. -Paul A. Gigot, WSJ, on NASA |  henry@zoo.toronto.edu  utzoo!henry

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 00:33:29 GMT
From:      jason@hpcndjdz.CND.HP.COM (Jason Zions)
To:        comp.protocols.tcp-ip
Subject:   Re: IEEE standards

The 10BaseT spec was developed by IEEE 802.3i. You'll need to use it in
conjunction with a copy of IEEE 802.3. You can get IEEE standards from:

	IEEE Standards Sales
	445 Hoes Lane
	P.O. Box 1331
	Piscataway, NJ  08855-1331
	(908) 562-3800
	1-800-678-IEEE

The IEEE has in the past published the addenda to 802.3 in a separate
volume; I expect this practice will continue.

Jason Zions

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 02:49:01 GMT
From:      rvg@pandora.cs.wayne.edu (Rahul Vijay Garg)
To:        comp.protocols.tcp-ip,alt.sys.sun,comp.os.misc
Subject:   NFS, RFS and RPC, performance statistics wanted.


Could someone please direct me to some discussion, or reports on the
comparative statistics of the performance of the NFS, RFS and sun RPC
protocols.

Direct email would be much appreciated, and if requested will summarize.

Thanks.


--
-rahul garg

Internet:rvg@cs.wayne.edu   UUCP:...umich!wsu-cs!rvg
voice: (313) 832-2382

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 06:55:02 GMT
From:      craig@sics.se (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Re: Sub standard FTP implementation

In <1991Jul30.191524.2577@novell.com> donp@na.excelan.com (don provan) writes:

>In article <3625@geocub.UUCP> anthes@geocub.UUCP (Franklin Anthes) writes:
>>I looked through RFC959 trying to find a place where a mandatory set
>>of commands would be defined. The only thing RFC959 seems to say is
>>that some commands are optional (CDUP,SMNT, etc.), but none seem to be
>>mandatory. Not even STOR or RETR!
 
>RFC-959, section 5.1, "Minimum Implementation", Page 43.  The
>mandatory commands are user, quit, port, type, mode, stru, retr, stor,
>and noop.  So an implementation without list and nlst is legal, just
>not very useful.

You need to look in Host Requirements (RFC 1123)!  NLST and LST
are required.  From pages 34 & 35:

     4.1.2.13  Minimum Implementation; RFC-959 Section 5.1

	The following commands and options MUST be supported by
	every server-FTP and user-FTP, except in cases where the
	underlying file system or operating system does not allow or
	support a particular command.

	     Type: ASCII Non-print, IMAGE, LOCAL 8
	     Mode: Stream
	     Structure: File, Record*
	     Commands:
		USER, PASS, ACCT,
		PORT, PASV,
		TYPE, MODE, STRU,
		RETR, STOR, APPE,
		RNFR, RNTO, DELE,
		CWD,  CDUP, RMD,  MKD,  PWD,
		LIST, NLST,
		SYST, STAT,
		HELP, NOOP, QUIT.

Craig Partridge

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 11:38:30 GMT
From:      leisner.henr801c@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Instructions wanted on getting mac NCSA onto a MAC


Can I have some instructions on how to get NCSA Telnet from my sun to my mac?

I'm a PC/Unix expert, know nothing about MACs except they're different.

I'd like instruction about what to get (from where)
What to run in which order
How to transfer files from my Sun SS2 to a MAC.

thanks,

marty
(Knowledge is useful in the Information Age)
(Software is mindstuff.  It is the hardest activity created by man)
ARPA:	leisner.henr801c@xerox.com
NS:  leisner:henr801c:xerox
UUCP:	hplabs!arisia!leisner

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 11:53:56 GMT
From:      tkevans@fallst.UUCP (Tim Evans)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   Looking for Network Research "Fusion" Users

We use a very old network software package called "Fusion" (tm)
from a company called Network Research.  About two-thirds of
our network (500 hosts) use Fusion XNS, while the rest use
various TCP/IP implementations.  To enable, XNS-to-TCP/IP
connectivity, Network Research has a dual-stack package.  The
documentation we have for the latter is practcically nil,
and the vendor who sold it to us is gone from the scene.

Network Research has now officially dropped support for its
XNS products, and we're kinda left adrift.  Is anyone else
using these products, particularly the dual-stack package?
It'd be Real Nice to be able to share experience, and maybe
even get additional documentation.

Thanks.
-- 
UUCP:		{rutgers|ames|uunet}!mimsy!woodb!fallst!tkevans
INTERNET:	tkevans%fallst@wb3ffv.ampr.org
Tim Evans	2201 Brookhaven Ct, Fallston, MD 21047

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 13:26:15 GMT
From:      bmiller@CABELL.VCU.EDU (Bryan Miller)
To:        comp.protocols.tcp-ip
Subject:   Network printers


Can anyone give me any hints/suggestions on network printers.  By that
I mean a printer that can attach directly to Ethernet, be assigned
an IP address, and then be able to receive printed output.  We are
looking towards this as an alternative to purchasing terminal servers
each time we need to connect a remote printer.

Thanks,

Bryan Miller

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 14:50:05 GMT
From:      prakash@beast.sme.siemens.com (Veera Prakash)
To:        comp.protocols.tcp-ip
Subject:   Remove from mailing list

Please remove my name from your mailing list.

Thanks

prakash@sme.siemens.com

-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 17:56:49 GMT
From:      clynn@BBN.COM (Charles Lynn)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP Urgent data

James,

You say:
   "So, the application remains unaware until 1) the Urgent pointer is
    within the Window offered by the TCP, 2) " ...

Maybe I misunderstand what "the application remains unaware" of, but
isn't it the case that the receiving application should be notified of
Urgent Data when receiving TCP receives a PDU containing the Urgent
Bit set, and won't that happen as soon as the sending TCP sends its
next PDU after being informed by the sending application that Urgent
Data exists, even if that PDU is A) a retransmission (of something in
the window), B) an ACK (of data flowing in the reverse direction), or
C) a "zero window" probe (I won't mention XXXXXXXXXs as they are not
part of the TCP Specification :-).

The "catch-22" is that since the Urgent Pointer is relative to the
PDU's sequence number, it cannot be expressed if the Urgent Data ends
more than 65K bytes in the future (of the PDU) (but an good
implementer can probably figure out how to "get the Urgent Indication
through"; there is a lot of space between common window sizes and 65K,
even more with Large Windows.

Charlie

-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 18:24:47 GMT
From:      mckenzie@bbn.com (Alex McKenzie)
To:        comp.protocols.tcp-ip
Subject:   Re: Sub standard FTP implementation

In article <3625@geocub.UUCP> anthes@geocub.UUCP (Franklin Anthes) writes:

>I looked through RFC959 trying to find a place where a mandatory set of
>commands would be defined. The only thing RFC959 seems to say is that
>some commands are optional (CDUP,SMNT, etc.), but none seem to be
>mandatory. Not even STOR or RETR!
>
>Have I missed something, or was this left out of the RFC on purpose?

My recollection (and it was more than 15 years ago) was that as we
designed the FTP we imagined that there might be read-only file transfer
sites (e.g. a card reader) and write-only sites (e.g. a line printer)
that one would want to do FTP to (especially using the "three party FTP"
feature), so we should not _require_ both STOR and RETR.  I guess if we
weren't going to require those we didn't see the point in requiring
anything else. 

Alex McKenzie
 

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 18:27:36 GMT
From:      brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Applications do benefit from TCP's out-of-band dat

In article <9107301244.AA01755@mts-gw.pa.dec.com> cei@took.enet.dec.com writes:
> TELNET certainly DOES benefit from urgent data.  My TELNET CLient
> implementation is capable of sending commands (e.g. IP, AO,etc.) with
> or without urgent.  WHAT A DIFFERENCE - with urgent is much faster!

Hold on. *What* is much faster?

Do you mean the speed of IP taking effect, as visible to the user? If
there is *any* delay between your client sending IP and it beginning to
flush data, then the user should be complaining about the slow flushing,
not about how fast IP traverses the network. I agree that in that case
the user will see data stop much sooner if Urgent is used. However, if
the only use of Urgent is as a patch for implementations which wait for
the other side to say ``okay, start flushing,'' then I suggest that it's
a pointless kludge.

If you start flushing data immediately, then I don't understand what's
much faster. The Urgent shouldn't cause either client or server to
change its behavior in this case.

---Dan

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 19:36:37 GMT
From:      thomson@hub.toronto.edu (Brian Thomson)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent data

In article <9107301438.AA09668@ftp.com> jbvb@ftp.com writes:
>
>The TCP  ...
>  ... isn't supposed to pass data up until it has been ACKed,

There is no such requirement.
Delayed ACKs exist in many implementations, for good reasons and
with good results.

On the contrary side, there are people who will argue that the
data should be ACKed only after it has been successfully passed up,
to make the ACK as "end-to-end" as possible (an argument that has
its good and bad points).

>So, the application remains unaware until 1) the Urgent pointer is within
>the Window offered by the TCP, 2) the data is actually received, and 3) any
>missing segments in the current receive window are retransmitted so the
>TCP can ACK at or beyond the Urgent pointer.

What do you mean by "unaware"?  The application should be notified as
soon as the Urgent pointer moves ahead of the current read point.
Window size and amount of received data have nothing to do with this.

Missing data shouldn't really matter either, but the way the RFC is written
it does, because "Segments with higher begining sequence numbers may be
held for later processing", and the later processing includes URG bit
processing.  In spite of this, I don't see any good reason why an
implementation shoudn't process URGs (and RSTs, and ACKs, for that matter)
of segments-from-the-future as soon as they are received.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 19:46:39 GMT
From:      fyang@nysnet.nys.GOV (Frank Yang)
To:        comp.protocols.tcp-ip
Subject:   need source code for finger

Hi NetExperts :
 
 Anyone knows where I can get the source code of "finger" program. The reason
I need it is that the current one we're using (came with AT&T TCP/IP WIN/3B
software package, only executable programs) shows only 5 chars in the field
TTY when you type "finger" without any argument, but in our machine, we have
6 chars for TTY's name. So I wonder if I can get the finger's source code and
get the truncated character back.
 I know "finger -i" will give me more chars in the TTY field and I can write
a small shell script to do cut-and-paste to fix it, but that's not the way I
want to (it'll slow down). 

 Any suggestion/comments/pointing with be appreciated !
 Thanks

 Frank

 fyang@nysnet.ny.gov
 uunet!nysnet!fyang

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 20:20:00 GMT
From:      josevela@mtecv2.mty.itesm.mx (Jose Angel Vela Avila)
To:        comp.protocols.tcp-ip
Subject:   Re: Networked Printers

beame@maccs.dcss.mcmaster.ca (Carl Beame) writes:

>In article <9107251310.AA06400@dec-netman-k.mitre.org> fjr@NISC.SRI.COM writes:
||
||I am looking for suggestions on how I can place distributed printers on
||a TCP/IP network. Specifically, the network will have centralized RISC
||workstations running a flavor of UNIX and PC's running TCP/IP. I would
||like to be able to place existing printers (serial/parallel) out in the
||work areas so that users can send their printouts from the UNIX boxes
||and their PCs to these printers. I know that I could use an LPD daemon
||on a dedicated PC for each printer, but this seems like an expensive
||proposition. Is there any software available that would let me use a
||terminal server to do the same job? Any other ideas would be welcome.
||

 Well not exactly, you could use one PC for feed 2,3,4 printers ....

 Also your printer daemon is FREE !!

 Yes !, it is on tacky.cs.olemiss.edu in pub/lpd/nos ....

 Well on a terminal server it is posible too ...

 One maner could be with a TCP redirector ..... ( send or write from stdin-out
   to a socket on a host )...

 Bye..

Jose A. Vela Avila. 

-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 20:25:17 GMT
From:      rogers@LEGO.GSFC.NASA.GOV (Scott W. Rogers)
To:        comp.protocols.tcp-ip
Subject:   Re: anonymous ftp via mail

> From tcp-ip-relay@NISC.SRI.COM Wed Jul 31 15:45:27 1991
> Date: 30 Jul 91 17:17:47 GMT
> Sender: <tcp-ip-relay@NISC.SRI.COM>
> From: agate!linus!intrbas!kenn@ucbvax.Berkeley.EDU  (Kenneth G. Goutal)
> Organization: gds
> Subject: anonymous ftp via mail
> Message-Id: <247@intrbas.UUCP>
> To: tcp-ip@nic.ddn.mil
> 
> Thanking you for your patience, > -- Kenn Goutal
> Interbase Software Corporation
> 209 Burlington Road			...!linus!intrbas!kenn
> Bedford  MA  01730  USA			...!mcsun!uunet!intrbas!kenn
> 617.275.3222				kenn@interbase.COM

Send mail to "SERVICE@NIC.DDN.MIL"
Use a subject line of "HELP".

This is an automated mail service, it will send you a list of valid
commands.  Usually the request is in the subject line, or the first
line in the text portion (body) of the mail message.

Many documents and indexes can be retrieved this way, including
RFCs, IEN's, etc.

Also try (may/not work):
	service@uunet.uu.net
	service@uu.psi.com

-- 
------------------------------------------------------------------------
Scott W. Rogers	<rogers@dftsrv.gsfc.nasa.gov> FTS 888-1377, 301-286-1377
NASA Goddard Space Flight Cntr ADFTO/NSI Code 930.4  Greenbelt, MD 20771
NASA Science Internet Network Information Center (NSINIC)
------------------------------------------------------------------------

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 20:57:25 GMT
From:      CMSEDORE@mh.syr.edu ("Christopher M Sedore")
To:        comp.protocols.tcp-ip
Subject:   Re: net14 redirector

>Date:       Tue, 30 Jul 1991 15:10:02 GMT
>Reply-to:   tcp-ip@nisc.sri.com
>From:       tcp-ip-relay@nisc.sri.com
>Subject:    net14 redirector
>To:         Christopher M Sedore <CMSEDORE@SUVM.BITNET>
 
>Is anyone using the DOS based net14 redirector to redirect int14 to
>a tcp/ip network. I am not sure I fully understand what it is supposed
>to do.
>
>Thanks
>Mark Citron
>~
>--
>Mark Citron
>mark@neurosci.usc.edu


Yes I have used one that I picked up from Waterloo.  It works quite well.
An int 14 redirector intercepts IBM PC bios calls and sends the data
elsewhere.  In the case of a INT 14->TELNET redirector, the redirector opens
up a telnet connection with a specified host and makes it look like a serial
connection to a program like kermit.

I can give you the info on where to get it if you like (I don't have it
handy at the moment) or more info on how it works if you like.

My email address is cmsedore@rodan.acs.syr.edu

--Chris

Christopher M Sedore
Systems Programmer
Syracuse University

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 21:14:43 GMT
From:      jbvb@FTP.COM (James B. Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: Sub standard FTP implementation


    I looked through RFC959 trying to find a place where a mandatory set of
    commands would be defined. The only thing RFC959 seems to say is that
    some commands are optional (CDUP,SMNT, etc.), but none seem to be
    mandatory. Not even STOR or RETR!
    
RFC 1123 remedies that lack - see the section on FTP.  I myself haven't
seen software that didn't implement LIST or NLST since 1987, and it was
out of date at that time.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 21:21:01 GMT
From:      jonson@SERVER.AF.MIL (1Lt Matthew W. Jonson)
To:        comp.protocols.tcp-ip
Subject:   Re: Sub standard FTP implementation

<Franklin Anthes writes>
> Subject: Sub standard FTP implementation
> Message-Id: <3625@geocub.UUCP>
> 
> The company I work for has acquired FTP software that doesn't implement
> the CWD, LIST or NLST commands. This seems to me to be a sub standard
> implementation and causes a lot of problems with FTP clients that want
> to be nice to the user (Macintosh point and click style).
> 
>I looked throughRFC959 trying to find a place where a mandatory set of commands
> would be defined. The only thing RFC959 seems to say is that some commands
> are optional (CDUP,SMNT, etc.), but none seem to be mandatory. Not even
> STOR or RETR!

RFC 1123 clearly defines CWD, LIST and NLST as commands that MUST be
implemented.  Take a look at that document for all your application level
needs!  Chances are that a deficient FTP comes with a deficient Telnet, etc.

/matt

-- 

Lt Matthew W Jonson       jonson@server.af.mil  snail-mail:
Network Systems Engineer     205-279-4075       SSC/SSMT
USAF DDN Program Office      AV: 596-4075       Gunter AFB, AL  36114

Technically just an opinion, not a Government Official View.

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 21:36:12 GMT
From:      gutman@felix.UUCP (Andrew Gutman)
To:        comp.protocols.tcp-ip
Subject:   conformance/interoperability/performance


	Hello,

	Are there tools (e.g., test suites) available for testing a 
	particular (UNIX-based) tcp/ip implementation for conformance 
	and/or interoperability with other implementation ??  

	I am also looking for information regarding throughput
	for tcp & udp-style connections. I suspect this might
	be vendor-prejudiced; has any independent source tallied
	this information? 

				Thanks,
				AndyG.

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 21:59:19 GMT
From:      nguyent@hpcc01.HP.COM (Ted Nguyen)
To:        comp.protocols.tcp-ip
Subject:   FTP return code

Help! Does any body know if there is a way to capture the return code
from FTP. I'm trying to write a C-shell script on HP9000s300 to ftp a file
to a host machine. After that, I like to check the return status
to see if the transmission was successful or not. Is this
possible?

Thanks.
Ted Nguyen
993-4879

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      31 Jul 91 23:04:46 GMT
From:      steveo@world.std.com (Steven W Orr)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.dcom.lans,comp.dcom.sys.cisco
Subject:   Need help to base decision on Wellfleet vs. Cisco Router.

Hello all. We are about to purchase network routers to connect a
couple of dozen computers in the US to a couple of dozen computers in
Tokyo. We had been planning on using Wellfleet routers, but the issue
was just presented to us that the Cisco product should alse be
considered. 

I need to get a feel from as many people as possible on (at least)
two issues: 

1. What are the practical fieldie type issues that have come up that
   have caused you to say good or bad things about either product?

2. (Related to item 1) Which product comes with 'better' network
   management facilities? This last seems to be key, since our
   cursory look-see seems to yield that the two are functionally nose
   to nose.

All computers in the system will be running [34]86 based SCO Unix.

I can't tell from what I wrote, whether you all can tell that I
barely know what I am talking about. (I just learned what a router is
a few months ago.) If I'm not asking the right questions or not
asking enough questions, please let me know that too.

My perception is that the selection of a router for _anybody_ is a
critical decision. At least in our case, it is. If you have something
to say and you just sort of don't feel like it, PLEASE don't hit the
'n' key; let me know anyway!  Please email me or post if you think it
is of enough general interest.

Many thanks in advance.
 
-- 
----------Time flies like the wind. Fruit flies like bananas.------------------
Steven W. Orr      steveo@world.std.com     uunet!world!steveo
----------Everybody repeat after me: "We are all individuals."-----------------

END OF DOCUMENT