The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1989)
DOCUMENT: TCP-IP Distribution List for October 1989 (492 messages, 248232 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1989/10.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 Oct 89 01:04:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent Data Handling

Bob,

The most sensible implementation of URGENT POINTER is to mark the
byte just past the end of the urgent message. If the message is
broken into segments, one could continue to set URG=1 and
UP="byte number 1 past the last byte of urgent data". Resetting
URG and UP is OK, too, so long as the recipient remembers UP
until the received in sequence bytes exceed the last byte of
urgent data.

The implementation which sets UP to just past the data of each
segment isn;t necessarily broken, but it seems unnecessary
to implement in that fashion. 

The question of first or last byte of an urgent message caught
me by surprise. At the TCP level, the only thing you can
specify is where the urgent data ends, not where it starts.
The interface between the process wanting to send urgent 
information and the kernel TCP service needs to have a way for
the process to say where the urgent data ENDS, since that is
the information that the TCP can convey.

The receiving process will need clues in addition to those provided
by TCP to distinguish the urgent from non-urgent information -
these semantic and syntactic matters were left to the protocol
layer above TCP to deal with.

Vint

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 89 01:55:39 GMT
From:      qureshi@WSU-ENG.ENG.WAYNE.EDU (Imran U. Qureshi 7-0108)
To:        comp.protocols.tcp-ip
Subject:   (none)

Hi..
Is it possible to stop the udp packets (generated by PC-NFS) from going onto thebackbone using a retix 2244 bridge ?
If not, is there a cheap way of doing it ?

cofiguration:
 
___________________________
________________ backbone_
             |
             |
        retix bridge
             |
             |
        SERVER 386i
             |
             |
            PC
             |
            PC
             |
            PC

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 89 02:49:07 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Comment on RFC1124 (?)

Roy,

The problem you had was apparently spooler-specific, since the file printed
without mishap on both our lasers and spoolers and the RFC editor's lasers
and spoolers. However, the DP software did make rather rash assumptions
and took naughty liberties in the file format. With help from my friends,
including you, I found the problem and manually massaged the file, which
is now in the archives. I apologize for your inconvenience and any others
who snarfed the file during the first couple of days after its appearance and
promise to be ever vigilant in future submissions.

Dave

-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 89 03:26:13 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Comment on RFC1124 (?)

John (and others),

I have a serious dillema. My students and I work with several text, image
and statistics systems, all of which produce PostScript. My advice has been
to use the best technology currently available to maximize research
productivity and exposure in the many scientific and engineering archives
available to us, including RFCs. Unless a document is in fact pure text, this
usually means PostScript. This is how we submit articles for publication
in conference proceedings, archive journals and even our dear own Computer
Communication Review. For the reasons mentioned in my recent message, we are
not prepared to render every document in ASCII, regardless of content, and
are not prepared to maintain documents in more than one form. Thus, the real
question is whether PostScript submissions will be allowed in the RFC
archives or whether they will be published elsewhere and not appear in the
RFC archives at all.


I am a stout supporter of the RFC process and would hope that our community
can be viewed as a leader in technology of electric publishing, archiving
and distribution. Just as CCR is viewed as a pioneer in print publishing
by encouraging article submission in electric form (currently PostScript),
I would hope our community can show that it is possible to save the production
cost and even a few trees by remote access of the archives, while preserving
the full capabilities of print media.

There are lots of things that PostScript does not provide and that may
become available in future, including ODA. When the standards have stabilized,
when software is available and when such capability has spread even to the
sites that have no PostScript printers now, I promise to become a zealot.

Dave

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Sun, 1 Oct 89 11:02:49 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        CERF@a.isi.edu, Mills@udel.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  PostScript Versus ASCII
Postscript is the ointment.  I perceive a fly:

We may recall that people used to refer, rather simply, to having
their software run on "Unix".  These days, people are a little more careful
to indicate the specific FLAVOR of Unix that it runs on.

I use WordPerfect, at home, and am going through some wars to get it
to print a postscript file on a non-directly attached and non-Apple
postscript engine.  No luck.  Wordperfect apparently produces a file
that is a) broken and b) tailored specifically to the Apple.  Even if I
have some details wrong, my point is that we need to have VERY precisely
specified details about what Postscript is acceptable and, I believe,
we will then find that much/most Postscript-generating software is
marginally non-compliant.

There can be no reasonable question about the benefit of being able to
use mixed text/graphics for document production and it seems remarkable
that there is still a barrier to doing it.  I suspect that there needs to
be a coordinated effort to get a sufficiently universal and consistent
mechanism, particularly if you wish to avoid excessively favoring any
single word-processing/publishing-package vendor.

Dave
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 89 07:28:43 GMT
From:      LARSON@CRVAX.SRI.COM (Alan Larson)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)


  I think the writer who proposed that IAB buy us all PostScript
equipment had a good point.  As Vint Cerf pointed out, the last host
count was over 100,000 hosts - and a large number of us do not have
Postscript displays that let us search, cut, paste, as well as display.

  With real ascii, we can include excerpts cut from the RFCs in
messages (like this one) that we send to vendors who are delivering
non-conforming software.

  With real ascii, I can search through the directory of RFCs for
the text string I remember, find it, and paste it (with good old-
fashioned tools like emacs) into a message.  Just imagine what this
message would have looked like with a paragraph or two of postscript
included.

        Alan
-------

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 89 15:45:19 GMT
From:      rick@UUNET.UU.NET (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re:  PostScript Versus ASCII

All of the text processing programs I regularly use (*roff on
unix and ms-word on the Macintosh) have the capability to produce a
pretty reasonable looking text only version from the original input
IN ADDITION to the intended fancy postscript output. I believe a filter
is also available for TeX to produce reasonable ASCII.

What systmes are you using that cant produce ASCII output? Granted
it won't be of the same quality as the postscript, but it certainly
will have the content necessary for the text only people.

Producing both text and postscript would be absolutely no problem for me.
I would not have to maintain a second source file. Perhaps these
"powerful" CAP systems you are using aren't as powerful as you were
lead to believe.


How about examples of the inadequate systems you are complaining about.

--rick

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 89 15:55:19 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

Vint:

>       I assume that your tongue was firmly in cheek in proposing
>       to have the IAB acquire a PostScript printing/display
>       capability for every Internet site. The last host count
>       was 118,000+ and growing.

Yes.  I did, however, require a surgical procedure to have it removed.

>       The principal reason for considering PostScript as an
>       allowable publishing medium was the belief that it is
>       widely available already. Is it the case that your site
>       has no PostScript capability at all?

The technically accurate response is that we do have a PostScript capability;
however, the problem is accessability.  The PostScript capable printers are
on classified systems which cannot be connected to the Internet.  In order
to print an RFC on those systems, I would have to modify the document to
include the required "U N C L A S S I F I E D" banner at the top and bottom
of each page and may have to include the "(U)" at the beginning of each para-
graph unless, of course, the author has already done that for me.  Should I
fail to do that, I will get the system's default banner and be required to
secure the document in a vault when not in use.

The basic problem is that we have two different views of the "Information
Age".  There are those, like myself, who envision a world where paper is
the exception rather than the rule.  We want to be able to display the in-
formation at a terminal, obtain the information that we require, and get
on with business.  Desktop publishing is an anachronism.

Or is it the future for those whose performance is measured by the printed
word?  For this group desktop publishing is the future.  Their ideas and
observations can be rapidly distributed over the electronic medium with the
publishing costs being absorbed by the target audience.

The basic problem is that the first group wants the information but does
not want the description of how the information is displayed on the printed
page.  How do we resolve this problem?  From my perspective, the information
is not in a usable form.

Merton

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 89 16:58:29 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  PostScript Versus ASCII

Rick,

We use ?roff and MS-Word, as well as Ventura, LaTeX and everything else as
well. The problem is not simply ASCIIfying the text, but rendering images,
figures, graphs and whatnot that are difficult or impossible to ASCIIfy and
are the reason to select PostScript in the first place. When we produce
text-only documents we do exactly as you do - ASCIIfy with readily
available conversion utilities.

Dave

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 89 18:02:49 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  PostScript Versus ASCII

Postscript is the ointment.  I perceive a fly:

We may recall that people used to refer, rather simply, to having
their software run on "Unix".  These days, people are a little more careful
to indicate the specific FLAVOR of Unix that it runs on.

I use WordPerfect, at home, and am going through some wars to get it
to print a postscript file on a non-directly attached and non-Apple
postscript engine.  No luck.  Wordperfect apparently produces a file
that is a) broken and b) tailored specifically to the Apple.  Even if I
have some details wrong, my point is that we need to have VERY precisely
specified details about what Postscript is acceptable and, I believe,
we will then find that much/most Postscript-generating software is
marginally non-compliant.

There can be no reasonable question about the benefit of being able to
use mixed text/graphics for document production and it seems remarkable
that there is still a barrier to doing it.  I suspect that there needs to
be a coordinated effort to get a sufficiently universal and consistent
mechanism, particularly if you wish to avoid excessively favoring any
single word-processing/publishing-package vendor.

Dave

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 89 18:11:06 GMT
From:      kratz@bnrgate.bnr.ca (Geoff Kratz)
To:        comp.protocols.tcp-ip
Subject:   Re: Thinwire vs. Thickwire

In article <8909291306.AA06775@jvnca.csc.org>, aggarwal@JVNCA.CSC.ORG (Vikas Aggarwal none) writes:
> 
> Just to collect one's views on Thinwire ethernet vs Thickwire ethernet,

What about Unshielded Twisted Pair (UTP)?  We are using this exclusively now, and
we have found a number of advantages:

    - extremely cheap (uses existing 4-wire in the building)
    - MAUs cost much less than transceivers
    - You can use the BIXX cross-connects to simplify moves of workstations
      (a move requires moving jumper wires from one cross-connect to another)

The disadvantage, of course, is the distance.  UTP is only good to about 400 meters.
Within a building, though, this is usually adequate.  Another thing is the tolerance
on the clock crystals.  We found a number of workstation manufacturers who's specs on
the clock were less than adequate, thus causing a lot of jams or CRC's.  However, for
our site (1000+ workstations in 5 buildings with constant workstation moves), UTP
gives us more benefits in topology planning, installation and $$$.

And yes, we run at full ethernet (10 Mbps).

Anyone else out there using UTP for their ethernets?
-- 
Geoff Kratz         Bell-Northern Research, Ltd.    Ph: (613) 763-5784
Internet Systems      P.O. Box 3511, Station C      FAX:(613) 763-3283
                    Ottawa Ontario Canada K1Y 4H7
BITNET: kratz@bnr.ca

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 89 19:12:16 GMT
From:      rick@UUNET.UU.NET (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re:  PostScript Versus ASCII

Great. Then there is no reason not to produce text only version as well
with the notation that some figures may olny be found in the postscript
versions.

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 89 19:44:36 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: PostScript Versus ASCII

In article <8910011258.aa16514@huey.udel.edu>, Mills@UDEL.EDU writes:
> The problem is not simply ASCIIfying the text, but rendering images,
> figures, graphs and whatnot that are difficult or impossible to ASCIIfy and
> are the reason to select PostScript in the first place.

	I'd find it useful even if only the text were available in ASCII
form. If your concern is the wasted time generating a complete document, I
agree and I'd say "don't bother." If you make the text available, then
I can use RFC's as (many are) intended-- as references. That's what
distinguishes them from many papers, where the overall meaning is more
important than the details.
	Being able to search and quote text from a standard is certainly an
important part of having the standard-- to have a "judge" when implementations
differ. It's clearly more time consuming to use a paper (or even on-screen
display PS) document and either type in the text or say "section X, about
page YY, if you're using a Z-point font," etc. etc. when sending e-mail to
point out why an implementation isn't quite right.
	I just want ASCII for search and reference text and agree with all of
your (and other's) points about moving towards easier preparation, higher
quality and greater expressive power.
	Just leave a hacked partial paper around to be used as a full index
and not as a duplicate or replacement for the PS version and I, at least, will
be happy.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 89 20:04:00 GMT
From:      WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   Comment on RFC1124 (?)

Dave,

I think you answered your own dilemma: all instances you cited, except
for RFCs, are in the print (paper) domain.  Publishing in the paper
domain is not what RFCs are all about - just expand the name.

Note that this discussion is not about electronic publishing; it is
about RFCs - to be able to cite and debate them in an electronic media
- not about printing them.  The RFCs should never have been made
available in printed form - they should have been put on disk, tape,
or even CD-ROM, not on paper for distribution outside the Internet
access world.  We have enough trouble with vendor implementations of
network software without giving them yet another excuse - not being
able to read them because they can't print them.

--Frank

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 89 21:10:58 GMT
From:      chris@cs.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re: Checksum Byte Order...What is it?

Barry Margolin notes that
>There's a rigorous proof (which I don't know) that this always produces
>the right result.  I think the end-around carry is the part of the
>checksum algorithm that does it ...

It is.  In fact, the whole thing becomes obvious (hence not needing
anything other than rigorous handwaving :-) ) if you view the bits
as being wrapped around a 16-segment cylinder.  When carries out of
slot 15 are added back to slot 0, it becomes clear that all the bits
are treated identically, and the whole thing is isomorphic under
arbitrary rotations (as long as the input and output have the same
rotation, that is).

Chris

-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 89 23:01:13 GMT
From:      vaf@VALINOR.STANFORD.EDU (Vince Fuller)
To:        comp.protocols.tcp-ip
Subject:   YP and the domain system

A while ago, there was a discussion of the pitfalls involved in setting-up a
YP system in the Internet environment. Specifically, the discussion described
the scenario under which YP can (and does) cause Internet domain servers to
be flooded with bogus requests. Does a summary of this discussion exist?

	Thanks,
	Vince Fuller, Stanford Networking

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Oct 89 23:04:01 GMT
From:      epsilon@wet.UUCP (Eric P. Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: PostScript Versus ASCII

The ability to quote from RFCs into text-only mail is something
I hadn't considered, and a valid point.  So far the best
suggestion I've seen is { complete PS, plain ASCII, illustrations
} .  Then we don't have to upgrade 118K+ sites.
Just NIC.DDN.MIL.  :-)

I don't know how things are where you live, but in California if
you don't have PostScript capability "at home" you go to the
local copy shop with a diskette.  Since they make a healthy
profit on laser printing, having a "just the illustrations"
package appeals to the save-every-nickel types.  For text-only
material, I still want the PostScript.  For a small example, look
at the Internet Resource Guide files on NNSC.NSF.NET.
Everything's in both forms, the information's identical, but the
PostScript is much easier on the eyes.

Rather than argue about how widespread PostScript is, why not
support software such as FSF's GhostScript that will make it
unquestionably available to the neo-Luddites?

					-=EPS=-

P.S. Authors don't need to assume responsibility for mailing
hardcopies when the NIC already provides this service.

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 02:28:43 GMT
From:      ilham@ATHENA.MIT.EDU (Ilhamuddin Ahmed)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote Printer Protocol?


After getting quite a few requests for the Palladium documents (from
people without FTP access), these documents are now available from an
archive server. For those who sent me mail to me sometime back asking
for these documents, I apologise for the delay.

The postscript documents are split up so that it can be sent by mail.
The files are as follows:

-rw-rw-r--  1 ilham       88047 Oct  1 07:56 pddesign.PS.aa
-rw-rw-r--  1 ilham       66876 Oct  1 07:56 pddesign.PS.ab
-rw-rw-r--  1 ilham       77142 Oct  1 07:56 pddesign.PS.ac
-rw-rw-r--  1 ilham       74688 Oct  1 07:56 pddesign.PS.ad
-rw-rw-r--  1 ilham       71521 Oct  1 07:56 pddesign.PS.ae
-rw-rw-r--  1 ilham       67539 Oct  1 07:56 pddesign.PS.af
-rw-rw-r--  1 ilham       59250 Oct  1 07:56 pddesign.PS.ag
-rw-rw-r--  1 ilham       58862 Oct  1 07:57 pddesign.PS.ah
-rw-rw-r--  1 ilham       54262 Oct  1 07:57 pddesign.PS.ai
-rw-rw-r--  1 ilham       63651 Oct  1 07:57 pddesign.PS.aj
-rw-rw-r--  1 ilham       57012 Oct  1 07:57 pddesign.PS.ak
-rw-rw-r--  1 ilham        6098 Oct  1 07:57 pddesign.PS.al

-rw-rw-r--  1 ilham       52046 Oct  1 07:51 usenix.PS.aa
-rw-rw-r--  1 ilham       23549 Oct  1 07:52 usenix.PS.ab
-rw-rw-r--  1 ilham       21601 Oct  1 07:52 usenix.PS.ac
-rw-rw-r--  1 ilham       15461 Oct  1 07:52 usenix.PS.ad
-rw-rw-r--  1 ilham       14021 Oct  1 07:52 usenix.PS.ae
-rw-rw-r--  1 ilham       28561 Oct  1 07:52 usenix.PS.af
-rw-rw-r--  1 ilham       12252 Oct  1 07:52 usenix.PS.ag

To get one of these documents, send a mail messages to :

	archive@athena-dist.mit.edu

with a message of :    send palladium usenix.PS.aa

and so on with all the split files. If you ask to send more than one
file in one mail message request, it will shar those requests togther
and send it in one mail message back to you.

						- Ilham Ahmed
						  Project Athena, MIT.

-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 02:44:06 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: PostScript Versus ASCII

In article <8910011912.AA05858@uunet.uu.net> rick@UUNET.UU.NET (Rick Adams) writes:

   Great. Then there is no reason not to produce text only version as well
   with the notation that some figures may olny be found in the postscript
   versions.

Or use some PostScript interpreter to put the figures into a well-known
bitmap format, like X11 bitmaps, or GIF images.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
Live up to the light thou hast, and more will be granted thee.

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 03:30:30 GMT
From:      geoff@FERNWOOD.MPK.CA.US (the terminal of Geoff Goodfellow)
To:        comp.protocols.tcp-ip
Subject:   NNTP/USENET netnews feeds available at INTEROP 89.

If you're exhibiting on the "Show and Tel-Net" at INTEROP 89 next week and
would like an NNTP USENET netnews connection, they are available for the
the asking.  We will have a some MIPS systems in our booth (#214) and would
be happy to provide a feed/access.  

Bring your nifty news client and show it off.

Geoff Goodfellow
Anterior Technology
"Anterior-EndTable.ShowNet.Com" @ INTEROP 89.
-------

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Oct 89 08:39:13 EDT
From:      Jack Haverty <haverty@BBN.COM>
To:        Mills@udel.edu
Cc:        CERF@a.isi.edu, haverty@BBN.COM, tcp-ip@nic.ddn.mil
Subject:   Re:  PostScript Versus ASCII
Another idea into the fray:

MCIMail has a capability which allows me to send it a message for paper
delivery, by running any program on my Macintosh and "Print"ing to a
special output device which creates a file instead of actual output
(i.e., a pseudo-device).   I then tell MCIMail that this is an "image"
message, which causes it to laser-print it and deliver the hardcopy.

I'm not sure whether the "image" is actually postscript.  It's also a
bit clunky since I have to send any particular message twice - once to
recipients who can accept it electronically and deal with it (i.e. they
have a Mac), and once to recipients who need hadcopy.  

It does work however, and demonstrates that there *could* be a server
somewhere on the Internet to which the sender, or receiver, of a
document could send that document and get a hardcopy delivered.  It
might make sense to even offer two qualities of output (QOS bits at
layer 7!), one for laser-print, and one for FAX (which could be
delivered to most people directly as well).

Comments?  Anyone got something like this working yet?

Jack
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 11:29:59 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: PostScript Versus ASCII

> I don't know how things are where you live, but in California if
> you don't have PostScript capability "at home" you go to the
> local copy shop with a diskette.

Do they accept either cpio or tar-format disks or cartridges? No? Well,
I'll just use my personal computer. How about 16-sector hard-format CP/M
diskettes, or AmigaDOS 880K floppies? This is only an option if you have
an IBM-clone (running Messydos, to boot) or a Mac in-house.

> Everything's in both forms, the information's identical, but the
> PostScript is much easier on the eyes.

1245(yes)P
1960(Postscript)P
128(is)P
2250(much)P
196(easier)P
1747(to)P
456(read)P
6(.)P

> Rather than argue about how widespread PostScript is, why not
> support software such as FSF's GhostScript that will make it
> unquestionably available to the neo-Luddites?

Matter of opinion. From my point of view folks who want to tie us down in
the paper age are the Luddites. I have enough slaughtered trees floating
around my office as it is. Hardcopy, to me, means "time to order another
bloody filing cabinet".

And I have a question about GhostScript. The support files and fonts in
this package fall under the Copyleft. If RMS and his buddies are being
consistent, that makes anything printed with GhostScript a derivitive work
and subject to the Copyleft. Is this so, or is RMS making a special
exception for the sake of expediency?
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"That is not the Usenet tradition, but it's a solidly-entrenched            U
 delusion now." -- brian@ucsd.Edu (Brian Kantor)

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 12:39:13 GMT
From:      haverty@BBN.COM (Jack Haverty)
To:        comp.protocols.tcp-ip
Subject:   Re:  PostScript Versus ASCII

Another idea into the fray:

MCIMail has a capability which allows me to send it a message for paper
delivery, by running any program on my Macintosh and "Print"ing to a
special output device which creates a file instead of actual output
(i.e., a pseudo-device).   I then tell MCIMail that this is an "image"
message, which causes it to laser-print it and deliver the hardcopy.

I'm not sure whether the "image" is actually postscript.  It's also a
bit clunky since I have to send any particular message twice - once to
recipients who can accept it electronically and deal with it (i.e. they
have a Mac), and once to recipients who need hadcopy.  

It does work however, and demonstrates that there *could* be a server
somewhere on the Internet to which the sender, or receiver, of a
document could send that document and get a hardcopy delivered.  It
might make sense to even offer two qualities of output (QOS bits at
layer 7!), one for laser-print, and one for FAX (which could be
delivered to most people directly as well).

Comments?  Anyone got something like this working yet?

Jack

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 14:35:48 GMT
From:      tcs@BRL.MIL (Terry Slattery, SECAD)
To:        comp.protocols.tcp-ip
Subject:   Re:  PostScript Versus ASCII

There seems to be a consensus in this thread.  With few exceptions, the
requests have been to retain an ascii version of RFCs.  Vint stated that we
should declare a goal and begin working towards it.  The most reasonable
goal seems to be the one stated by Marc Gibian.

> 1.  always, always provide an ASCII version of all RFCs, since
>     as much as we wish it were different, not everyone has a
>     workstation, or even a PC, on their desktop.
> 
> 2.  provide an ODIF version of all RFCs to support interchange
>     of the complex, multimedia, form of the documents.

For ASCII versions of the RFCs, most people have been willing to compromise
on having pictures as text and are willing to accept a pointer to the
postscript image.  This seems reasonable for all parties.  Someone (the
NIC?) could keep track of CAP systems that support ODIF (listed in a file in
the info directory, or in a "How to write an RFC" file), and we could
encourage vendors to begin working on ODIF.

Until ODIF (or equivalent) is widely available, we still need ascii versions
for interchange.

	-tcs
 ps.  I've been wrestling with many of these same issues for my
publications.  There are problems with Postscript only files, vendor
specific CAP system formats, and markup languages.  Long lived publications
(like RFCs) will need to be ported to each new release of a CAP or become
obsolete (Dave, are you and your people planning on keeping your CAP files
current with each vendor's supported product?).  I'm currently using vendor
independent markup languages for text and CAP for producing figures, etc as
a compromise.

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Mon, 2 Oct 89 16:23:08 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re:  Comment on RFC1124 (?)

In article <8909302326.aa13204@huey.udel.edu> Mills@UDEL.EDU writes:
>I would hope our community can show that it is possible to save the production
>cost and even a few trees by remote access of the archives, while preserving
>the full capabilities of print media.

Remote access to the archives does not save trees -- indeed, it worsens
tree mortality -- if the archives are in a form which is print-only (not
readable on-line) for a good many sites.  Never mind the issue of software
that understands PostScript; a good many of us don't have the bitmapped
displays to show it on even if we had the software.  Agreed that this puts
us somewhat behind the times, but saying that will not buy us new hardware.
-- 
"Where is D.D. Harriman now,   |     Henry Spencer at U of Toronto Zoology
when we really *need* him?"    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 16:53:37 GMT
From:      eric@lcc.la.Locus.COM (Eric Peterson)
To:        comp.protocols.tcp-ip
Subject:   Re: Thinwire vs. Thickwire

In article <8909291306.AA06775@jvnca.csc.org> aggarwal@JVNCA.CSC.ORG (Vikas Aggarwal none) writes:
>
>Just to collect one's views on Thinwire ethernet vs Thickwire ethernet,
>I am listing what I know about the topic:
>
>THINWIRE
>
>	Flexible, Low cost ( app. $3.00 per meter ), 10 Mb bandwidth,
> 	Max segment length - 185 meters (30 nodes per segment), One 
>	multiport repeater can handle upto 8 segments

	From past experience, I recommend this for only very small or 
	temporary nets.  The cable is fragile, and the cable -> BNC
	connection is especially susceptible to breakage (we once had
	a janitor vacuuming the floor accidentally hit the cable and 
	yank it out of the BNC connector, he noticed the damage and
	managed to push the cable back into the connector - needless
	to say, it was a poor connection and that whole floor of the
	building suffered from intermittent Ethernet problems for 
	several days while we looked for the problem).

>THICKWIRE
>
>	More resilient for running through floors and ceilings,	Higher 
>	cost (app $11.00 per meter), 10 Mb bandwidth, Max segment 
>	length - 500 meters
>
>Based on the above, I would choose thickwire ONLY if the length of the
>segment had to be more than 500 mts or if the wire was going to run 
>through adverse areas.

	I feel that any area with users in it is "adverse."

>Any comments ??
>-vikas

	Another solution is to use multiport transceivers to disribute
	the Ethernet.  It is much less susceptible to damage (or I should
	say, if damage _does_ occur, it doesn't propagate throughout the
	network.)  I believe the spec allows xcvr cable runs up to 50
	meters away, and the multiports that I've seen allow up to two 
	levels of stacking the xcvrs.  Another advantage is that some
	Ethernet boards do not have the built-in thin wire BNC connector.

	A disadvantage is that manufacturers haven't seem to 
	standardize on their method of attaching the 15 pin connector
	(mechanically) to the board (grrrr).

Eric
-- 
Eric Peterson,	Locus Computing Corporation
lcc.eric@seas.ucla.edu;	{randvax,sdcrdcf,ucbvax,trwspp}!ucla-se!lcc!eric
{gryphon,turnkey,attunix,oblio}!lcc!eric	(213) 337-5153

-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 17:32:59 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re:  PostScript Versus ASCII

Rick Adams--
   Not only is there no reason for Dave not to furnish an ASCII, unpretti-
fied version, there's a rather good reason for him not to attempt to stand
by his offer to send hardcopy to all requesters of same: he can no more
afford the P**3 (Paper, Postage, Personnel) than Vint can afford to give
all requesters appropriate "iron"....
   justtryingtohelp cheers, map
-------

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 17:58:13 GMT
From:      perry@Morgan.COM (Perry Metzger)
To:        comp.protocols.tcp-ip
Subject:   Re: PostScript Versus ASCII

In article <629@wet.UUCP> epsilon@wet.UUCP (Eric P. Scott) writes:
>I don't know how things are where you live, but in California if
>you don't have PostScript capability "at home" you go to the
>local copy shop with a diskette.

Sorry, but here in New York, things are different. I still want ASCII,
if you don't mind. The beauty of ASCII is that everyone can in fact
read it. Most RFC's even convert pretty well into EBCDIC with simple
tools. 

>Rather than argue about how widespread PostScript is, why not
>support software such as FSF's GhostScript that will make it
>unquestionably available to the neo-Luddites?

What about people who want to read their RFC's today? So far as I
know, GhostScript has no outline fonts and doesn't drive any laser
printers that I own. Besides, it is written in C. What happens to
those people who are using machines other than Unix boxes? Since when
did they become second class citizens? What happened to people without
laser printers? Not everyone has them, you know.

The point here is this. PostScript may claim to be the new ASCII, but
in fact ISO Latin 1 is the new ascii :-).

Perry

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 18:03:07 GMT
From:      frg@jfcl.dec.com (Fred R. Goldstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

As long as we're all dumping on PostScript -- and I'll not contradict
the will of the masses and approve of posting only PostScript -- I'll
throw in another complaint.

Some PostScript documents are prepared "last page first", which works
on Apple LaserWriters and other printers that don't put the pages facing
the right way up.  The first time I printed the OSPF IGP spec, I got
a heap of pages in the wrong order.  I just got a new .PS RFC-draft, and
at least this time I knew to tell the LPS40
/param=(data=post,output_tray=face_up).

So much for a de facto "standard"!  While I don't dislike .PS files
so long as there's a .txt to play with too, they should indicate, in the
very beginning or somewhere like that, that they're backwards.
     fred

-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 18:57:56 GMT
From:      car@trux.UUCP (Chris Rende)
To:        comp.dcom.lans,comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.i386,comp.sys.ibm.pc
Subject:   Unix based PC networking

We will be implementing a fairly large, multi-server/multi-site network.

Systems to be networked include PC's (>100) and several unix systems (~6).
The PC's need access to file servers, 3270 gateways, and direct access
to other unix systems on the network.

We want a unix-based network OS and are currently looking at Banyan Vines
to run on a 386 box or a Banyan server.

Does anyone have any experience to share regarding Vines or similar products?

Any input regarding Token Ring vs. Ethernet would also be appreciated.

Please reply via E-Mail and I will post a summary.

car.
-- 
Christopher A. Rende           Central Cartage (Nixdorf/Pyramid/SysV/BSD4.3)
uunet!edsews!rphroy!trux!car   Multics,DTSS,Unix,Shortwave,Scanners,StarTrek
 trux!car@uunet.uu.net         Minix,PC/XT,Mac+,TRS-80 Model I: Buy Sell Trade
       "I don't ever remember forgetting anything." - Chris Rende

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 19:01:00 GMT
From:      FILLMORE@EMRCAN.BITNET
To:        comp.protocols.tcp-ip
Subject:   Experience with Netronix Ethermaster 13000 bridge


  We need some Ethernet bridges and I have been looking at what's available.
I have some information on the Netronix Ethermaster 13000 bridge and it
sounds very good - inexpensive and high performance (25,000 pps filtering).
Has anybody had any experience with this box yet?
  One of requirements is a security requirement - we have to be able to
prohibit passing of packets based on source and/or destination address,
with separate sets of rules for each direction through the box.  Apparently
third-party software is available for this box to perform this function.
Has anyone had experience with this software?
  How reliable is Netronix equipment in general?  Who services it?
  Any information would be much appreciated.
________________________
Bob Fillmore, Systems Software & Communications   BITNET:  FILLMORE@EMRCAN
  Computer Services Centre,                       Voice:   (613) 992-2832
  Energy, Mines, & Resources Canada               BIX:     bfillmore
  588 Booth St., Ottawa, Ontario, Canada  K1A 0E4

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 19:20:09 GMT
From:      sl@van-bc.UUCP (Stuart Lynne)
To:        comp.protocols.tcp-ip
Subject:   Re:  PostScript Versus ASCII

In article <8910021348.AA26853@ucbvax.Berkeley.EDU> haverty@BBN.COM (Jack Haverty) writes:
>Another idea into the fray:
>
>MCIMail has a capability which allows me to send it a message for paper
>delivery, by running any program on my Macintosh and "Print"ing to a
 
>might make sense to even offer two qualities of output (QOS bits at
>layer 7!), one for laser-print, and one for FAX (which could be
>delivered to most people directly as well).

Yes, lots of people are working on these types of services. Canada Post has
a Fax/Mail delivery service that will send your message (received by fax or
at a post office) to a remote fax machine or laser printed and hand
delivered.

AT&T Mail has fax delivery (and I think mail delivery as well).

X.400 of course will handle it. It's referred to as a Physical Delivery
Option.

Our fax product has a Unix Mail gateway to allow you to send mail via fax.
Just give an address like ...fax!1-800-555-1234!fred and off it goes.

It would be fairly easy to setup a server to offer these types of services
on the Internet. The hard part would getting someone to fund it. Until we
get secure mail services its very hard to bill back to the originator.

I would suspect that you'll see many sites offerring these services to their
own users, but not allowing remote access.

-- 
Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 19:26:07 GMT
From:      slf@well.UUCP (Sharon Lynne Fisher)
To:        comp.protocols.tcp-ip
Subject:   A year after the Internet worm -- what's changed?


I'm doing an article on what changes have been made as a result of the
Internet worm.  What changes have you noticed?  Are vendors better 
about fixing reported bugs?  Is your installation more secure?  I'm especially
interested in hearing from people who have large PC installations and have
seen changes there, even though the Internet worm didn't affect them.

Please respond to me via e-mail at:

sharon@asylum.sf.ca.us

or

slf@well.sf.ca.us

or send me your phone number and we can talk offline

or find me at Interop.  I'll be there Wednesday through Friday.

Thanks!
-- 
"Goldfish are quiet, under the water.
Girls who keep goldfish are often quite noisy."
                          -- The Jazz Butcher

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 20:22:21 GMT
From:      mep@AQUA.WHOI.EDU (Michael E. Pare)
To:        comp.protocols.tcp-ip
Subject:   Thick or Thin


You've seen pros and cons of both.  The biggest problem with both is in trying
to run wiring from the host to the 'backbone' whatever it may be.  Thick is
a pain if you have several machines in the same area, each requires a drop
using bulky transceiver cable, and you can quickly run out of space on the
cable (2.5m between transceivers) unless you use a multiport transceiver,
but you are still stuck with bulky transceiver cables.  An entire backbone
of Thinnet is clumsy and can easily lead to wiring faults and hard to trace
network problems, and has severe node limitations.

One escape may see a thick ethernet backbone with thick-to-thin repeaters
used to hook up local groupings of hosts.  One repeater can support say 8
areas, with each area supporting several machines (or just one).  This
provides better fault isolation and enables a large node installation.

I would definitely suggest you look into twisted pair format (as someone
mentioned).  This can be the least costly to install if the twisted pairs
(just one using 3COM's system, or two for Synoptics or eventually the 
10BASET standard) are already available.  You can even install the twisted
pairs separately for a lower cost than trying to run a lot of coax.  This
method provides for the best fault isolation and is the easiest to support
if people move around, as well as allowing for a large node installation.

I've installed and supported all three and twisted pair wins hands down.
By the way, 3COM's twisted pair ethernet is based on thinnet technology
while Synoptics is more based on thick.

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 22:05:39 GMT
From:      gwh@volcano.Berkeley.EDU (George William Herbert)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

Quick question: what are the locations that the RFC's are available
from anon ftp wise?  

Thanks,
george william herbert

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      2 Oct 89 23:23:21 GMT
From:      pvm@VENERA.ISI.EDU (Paul Mockapetris)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?) / OSI Transition

Most of the arguments to date have focused on two issues:

	Freedom to print RFCs
and
	Freedom to GREP RFCs

I personally think that the first should be guaranteed by the IAB or
whoever calls the shots, and that vanilla Postscript plus FAX, or
some other compromise should be made.  I think that the second freedom
is desirable but has to strike a balance against progress.  I can't
imagine RFCS about X, multimedia, or several other topics without
graphics.

I also wanted to add that we could view the passing of the second
freedom as a step in the transition to OSI.  I suggest the following
sequence:

1	Text RFCs.
2	Text and PS RFCs which are less accessible.
...
7	Copyrighted RFCs with ISO/CCITT numbers which must be purchased.

paul

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 89 02:45:43 GMT
From:      ccoombs@pilot.njin.net (Cliff Coombs)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   pt200 term. emulator over TCP/IP


Netlanders,
	I need a little help, direction, advise with a problem I'm
sure someone out there can shed some light on.

Backround:
	We are using thick Ethernet to connect +60 pc's in three
attached buildings (read logically 1 building) to 2 Netware file
servers.  Sytek 4140 multi-protocol cards are installed in all the 
pc's except for the micro-channel machines, where Western Digital
etherplus/a cards are installed.  Sytek (now Hughes LAN Systems),
installed a bridge and fiber optic repeater to attach this to the campus
fiber backbone.  Attached to the other end of the fiber is one of the
schools five Prime mini-computers.  Sytek also provided it's version of FTP
inc.'s TCP/IP software.  I have been able to attach to the Prime using
the fiber and vt100 emulation over telnet.  

Problem:
	Some of the software on the Prime has been customized to only
work with Prime pt200 and pt250 terminals.  (Don't bother asking why,
It's a long story... I just have to make it work).  

Question(s):
	Does anyone make a pt200 TCP/IP emulation product?  Is there a
'generic' emulation product I should try?  If I provide a termcap file
can a product be made?  If so by whom?  Can I get C code and adapt it
myself?  Since the vice-president wants this right away should I look
for another job?

Thanks in advance,  Digitally, 
			Cliff
-- 

   Cliff Coombs                                           VOICE (201) 527-2729 
   Network Coordinator	 	 	 		    FAX (201) 355-5143
   Kean College of New Jersey, Union, NJ, USA, Earth.   ccoombs@pilot.njin.net
     Disclaimer: You can't quote me, I'm still on lunch...

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 89 07:19:42 GMT
From:      gary@dgcad.SV.DG.COM (Gary Bridgewater)
To:        comp.protocols.tcp-ip
Subject:   Re: PostScript Versus ASCII

In article <45f40447.18268@apollo.HP.COM> marc@apollo.HP.COM (Marc Gibian) writes:
>This has been a very interesting discussion, but everyone seems to
>have missed what seems to me to be the real problem.  Let me give
>it a try ...

Nice try, too.  A standard, actual, honest data interchange format as opposed
to a proprietary, multi-versioned pseudo-standard.
Wrong.

Postscript looks OK but I think we are really missing an opportunity here.

We have a chance to solve two problems at once.  The new, improved CMIDEF -
Cloistered Monk Illuminated Document Exchange Format.

Surely all of us have a monastery near by which would be all to happy to produce
great looking, hand-lettered (in black and red) copies of the RFCs with
illuminated capitals, gilt edges, all solidly bound on vellum with pure
leather binders.  The data can be conveyed between the monasteries with a few
simple dial up lines provided by helpful local sites.  Or, even better, at last
something for all those homeless burros in Arizona to do - ferrying the
originals from site to site.

Their income would be supplemented and you would have something to treasure
for the rest of your life.  Just the index alone would be suitable for framing!
Special Illumination Groups could spring up - we could trade them like baseball
cards since each one would be unique.  Bind Or Frame sessions could be held at
Interop.

Paper?  Hell No - Vellum Forever !!

;->
-- 
Gary Bridgewater, Data General Corp., Sunnyvale Ca.
gary@sv4.ceo.sv.dg.com or 
{amdahl,aeras,amdcad,mas1,matra3}!dgcad.SV.DG.COM!gary
No good deed goes unpunished.

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 89 11:41:22 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

In <506@jfcl.dec.com> frg@jfcl.nac.dec.com.UUCP (Fred R. Goldstein) writes:
> Some PostScript documents are prepared "last page first", which works on
> Apple LaserWriters and other printers that don't put the pages facing the
> right way up.

	My feeling on this one is that *all* PS documents should be "first
page first".  It's the job of the spooler software to determine if page
reversal is appropriate for a particular printer, and if so, do it during
the spooling/printing process.  We've got both face-up and face-down
printers here; whichever order you put the pages in, the document is going
to be wrong for at least some printers, so you might as well use the
canonical ordering.

	And yes, I agree with Fred, if you absolutely, positively, must
produce pre-page-reversed documents for distribution, at least there should
be some easy way to tell what order the pages are in.  Do the normal PS
document formatting conventions provide some standardized %%line for this?
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 89 13:56:00 GMT
From:      Plummer@DOCKMASTER.NCSC.MIL
To:        comp.protocols.tcp-ip
Subject:   PostScript vs. ASCII

The RFC mechanism is meant to dessiminate information.  It is ONLY a
publishing and archiving mechanism.  Authors should consider their
choice of language and its effect on the size of their audience.
PostScript, ASCII, Cantonese, strange encoding, ...  -- Bill Plummer,
Plummer -at DOCKMASTER, (508)967-4870

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 89 16:23:02 GMT
From:      ian@lassen.wpd.sgi.com (Ian Clements)
To:        comp.protocols.tcp-ip
Subject:   Re: Thick or Thin

In article <8910022022.AA09420@aqua.whoi.edu>, mep@AQUA.WHOI.EDU (Michael E. Pare) writes:
> 
> ...This can be the least costly to install if the twisted pairs
> (just one using 3COM's system, or two for Synoptics or eventually the 
> 10BASET standard) are already available.  

 I disagree.  Remember that you need one transceiver for each workstation
regardless of whether or not you use thick, thin or twisted pair (assuming that
no workstation already has a thinnet xcvr installed).  I'm calling the xcvr
costs a wash even though there is a $50 difference between thin and twisted
pair (thin being least expensive and twisted pair most expensive).  So we can 
assume that all that is being compared is transmission medium and associated 
equipment, correct?  
 
 Following that assumption, the cost to acquire backbone cable for thick
or thin costs $1.25/ft and $.29/ft respectivly.  Twisted pair cable costs 
$.05/ft.  The twisted pair cable it self is much cheaper however, to make 
the whole thing work you need this box (commonly refered to as an Active 
star repeater) that can cost somewhere around 8k for more than 10 connections.

 Admittedly, once the twisted pair system is up and running, maintenance,
additions and other changes are far easier to deal with.  One can almost 
always install more twisted pair cable than either thick or thin backbone
and drop cables for the same costs.  Here at SGI for example, every office and
cube gets a 4 port data block.  From that block you can have Ethernet, 
PhoneNET (AppleTalk) and serial connections.

 Then of course there is the issue of the 10BASET spec which is to be 
released soon.  What does that mean to those of us with large twisted pair
installations?


	Cheers,

	Ian

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 89 16:31:52 GMT
From:      gww@EBAY.SUN.COM (Gary Winiger)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

In article <5446@asylum.SF.CA.US> karl@asylum.SF.CA.US (Karl Auerbach) writes:
>
>I propose that we ban postscript RFCs.
>
	Here!  Here!  PostScript is wonderful for making good looking paper
output, but useless for reading online or searching.  If an RFC is to be 
offered in PostScript, let's also have the text version available.

Gary..

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 89 17:04:43 GMT
From:      ihm@NRC.COM (Ian H. Merritt)
To:        comp.protocols.tcp-ip
Subject:   Re:  Comment on RFC1124 (?)

bkc@OMNIGATE.CLARKSON.EDU (Brad Clements) says:
>Karl Auerbach has proposed that postscript RFC's be banned, presumably because
>trying to index keywords in a postscript file is a pain, and not because 
>he feels that postscript printers are too obscure. (is that right?)
>
>I don't mind postscript format, but I think the question of keyword indexing
>should be addressed. 
>
>It would be useful if authors of any document that is shipped in postscript
>were to add a postscript prologue to the file with the proper keyword indexes.
>
	.
	.
	.

I agree that a keywords section might be useful, but this would not
address the main issue.  When searching an RFC, you may not be looking
for a keyword that is likely to appear in such a list.  For example,
probably the most common grep searches I make of the RFC directory
look for some phrase or tag that I remember reading in the past, but
can't quite recall the document from which it came.  In this case, the
context of the line around the hit is also useful to help separate
likely matches vs. coincidences.

Like one of the earlier postings said, I too bring up RFC's in EMACS
more often than any other method of viewing.  The ASCII-text pictures,
while maybe a bit difficult to create, have the advantage that they
can be viewed in this context.  This is very handy.

One other, perhaps less significant point is that many sites archive
these online locally to avoid the necessity to continually transfer
them over the net.  PostScript images are BIG!  Since grep isn't
particularly useful on them anyway, I keep the PostScript ones
compressed.  Even so, they are still larger than most RFC's
uncompressed.

	184 -rw-r--r--  1     172667 Sep 15 09:27 rfc1119.ps.Z
	120 -rw-r--r--  1     109731 Sep 20 14:06 rfc1124.ps.Z

If RFC's were available in dual formats (i.e. a .ps file and a .txt
file), I would definitely keep the .txt file online.  The .ps file,
however, I might be inclined to leave behind.

	-i

-- 
US Snail:	2380 Rose Avenue; Oxnard, CA  93030  U.S.A. tel. 805-485-2700
InterNet:	ihm@NRC.COM

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 89 18:19:09 GMT
From:      hak@cooper.cooper.EDU (Jeff Hakner )
To:        comp.protocols.tcp-ip
Subject:   Telnet options RFC?


	Perhaps an RFC numbers wizard (Jon Postel, are you out there?)
can help me.  I need the RFC which contains a list of all the currently
registered telnet option codes and a description of them.  If they
are not in a single RFC, then I need the list of such RFCs.  N.B.:
I AM NOT talking about RFC854 or 855.

Thanks a lot, thanks a whole lot.

Jeff Hakner
Cooper Union 
Computer Center

hak@meagan.cooper.edu

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 89 21:26:15 GMT
From:      gamiddleton@WATMATH.WATERLOO.EDU (Guy Middleton)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

In article <[A.ISI.EDU]30-Sep-89.19:47:54.CERF> you write:
> I assume that your tongue was firmly in cheek in proposing
> to have the IAB acquire a PostScript printing/display
> capability for every Internet site. The last host count
> was 118,000+ and growing.

I think it fascinating that anybody can actually come up with a count of sites
on the Internet.  Can you tell me how the number was arrived at?

 -Guy Middleton, University of Waterloo

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 89 21:40:15 GMT
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: refernces for recently published papers on tcp/ip.

In article <8909231906.AA10915@hub.eng.wayne.edu> qureshi@WSU-ENG.ENG.WAYNE.EDU (Imran U. Qureshi 7-0108) writes:
>Does any one know of any recently published papers on tcp/ip.
>I need some references (1988 -1989).

Check out my article "The Experimental Literature of the Internet:
An Annotated Bibliography" in ACM SIGCOMM Computer Communication Review
19:1, January 1989.  Many of the cited papers were published in 1988.

Also check the "Bibliography of Recent Publications in Computer
Networking" printed in most issues of CCR.

-Jeff

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      3 Oct 89 21:52:29 GMT
From:      childers@avsd.UUCP (Richard Childers)
To:        comp.protocols.tcp-ip
Subject:   Re: YP and the domain system

vaf@VALINOR.STANFORD.EDU (Vince Fuller) writes:

>A while ago, there was a discussion of the pitfalls involved in setting-up a
>YP system in the Internet environment. Specifically, the discussion described
>the scenario under which YP can (and does) cause Internet domain servers to
>be flooded with bogus requests. Does a summary of this discussion exist?

I would also be interested in seeing such a recapitulation ...

>	Vince Fuller, Stanford Networking

-- richard

-- 
 *    "Domains constitute a futile attempt to defeat anarchy and otherwise    *
 *     retard progress." (Steve Bellovin, Peter Honeyman, pathalias(l))       *
 *                                                                            *
 *        ..{amdahl|decwrl|octopus|pyramid|ucbvax}!avsd.UUCP!childers         *

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 89 00:01:47 GMT
From:      dave@fps.com (Dave Smith)
To:        comp.protocols.tcp-ip,comp.bugs.4bsd
Subject:   rwhod protocol and >42 users

Has there been any thought given to extending the rwhod protocol so that
more than 42 (1024/sizeof whoent (==24)) users on a system will be reported 
correctly?  This limit is entirely too small for today's systems.

If I read the sources to rwhod correctly, if I define a new revision of the
protocol, rwhod's with different versions of the protocol will discard
the packets.  Is this correct?  Will anyone have a fit (ok, I know _someone_
will have a fit, will anyone _important_ have a fit?) if I arbitrarily
define a new revision of the protocol?

David L. Smith
FPS Computing, San Diego
ucsd!celerity!dave or dave@fps.com
"Repent, Harlequin!," said the TickTock Man

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 89 02:12:12 GMT
From:      ecf_hap@jhunix.HCF.JHU.EDU (Andrew Poling)
To:        comp.protocols.tcp-ip
Subject:   Re: Thick or Thin

In article <42457@sgi.sgi.com> ian@lassen.wpd.sgi.com (Ian Clements) writes:
[...]
> I disagree.  Remember that you need one transceiver for each workstation
>regardless of whether or not you use thick, thin or twisted pair (assuming that
>no workstation already has a thinnet xcvr installed).  I'm calling the xcvr
>costs a wash even though there is a $50 difference between thin and twisted
>pair (thin being least expensive and twisted pair most expensive).


I've been watching this discussion go by and I want on.  Over and over I've
been muttering to myself, "But they've probably already bought a thinnet
xcvr - whether they know it or not".

Fact is, a whole bunch of workstations come from the factory with a xcvr on
board and that cute little BNC connector on the back.  And what about
PCs/compatibles?  Almost EVERY ethernet card that I've laid eyes on for PCs
has both thick and thinnet interfaces.  Some machines are even available ONLY
with thinnet interfaces (DEC VS2000's come immediately to mind - there must
be others, though).  In order to put a machine like this on thicknet or
twisted-pair, you must insert a $1,000-or-so repeater of some sort.  Uh-oh,
kinda makes those sweeping generalizations start looking like expensive
oversights.

When considering the relative costs of thicknet, thinnet, and twisted-pair,
you have to consider that alot of machines come thinnet ready.  If we're
figuring the costs of putting such machinery on alternate cable types, we
have to admit that we're buying two xcvrs for each machine and leaving one
idle.  We may also end up jacking up our repeater-count converting from one
cable type to another.

We've been using thinnet more and more, recently, for in-building wiring
for several reasons:
	1) it's smaller in diameter and more flexible and thus easier to
		put in place than thicknet (twisted-pair likewise)
	2) thinnet cable termination is a breeze compared to xcvr cable
		termination (we're talking about putting a connector on
		the end of the cable - fabricating custom-length cables)
	3) when we want to put several machines in one room, we can
		daisy-chain
	4) people with thinnet-ready equipment save money - no additional
		cost for a xcvr
	5) people with DB-15 interfaces spend less because thinnet costs
		considerably less than xcvr cable per foot and we can put
		the thinnet xcvr very close to the machine

We still use thicknet for the "backbone" (inter-building cabling) and for
some "building risers" for mostly obvious reasons:
	1) greater allowable cable length - important with our geography
		and layout
	2) greater (perceived at least) durability under the sometimes
		adverse conditions encountered - I'm not sure that there
		isn't sufficiently sturdy thinnet cable available nowadays;
		in fact, I'm sure there probably is
	3) the best reason of all - alot of our cabling of this type
		predates the wide availability and usage of thinnet


I mostly wanted to point out some easily overlooked "hidden" costs.  It's
amaizing how fast the costs can climb when you start figuring in repeaters
and pairs of xcvrs.

-Andy

--
Andy Poling                              Internet: andy@gollum.hcf.jhu.edu
Network Services Group                   Bitnet: ANDY@JHUVMS
Homewood Academic Computing              Voice: (301)338-8096    
Johns Hopkins University                 UUCP: mimsy!aplcen!jhunix!gollum!andy

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 89 14:22:07 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Thick or Thin

In <2781@jhunix.HCF.JHU.EDU> andy@gollum.hcf.jhu.edu (Andy Poling) writes:
> We still use thicknet for the "backbone" (inter-building cabling) and for
> some "building risers" for [...] greater (perceived at least) durability
> under the sometimes adverse conditions encountered

	I suppose the thick trunk cable is pretty tough, and the way the
typical vampire tap xciever connects to the cable is pretty good, but the
stupid D-15 connectors for the xciever drop cable is a disaster.  The
xciever ends don't give us any trouble because they are hidden away in a
ceiling or wall where nobody can touch them, and we have the drop cable
firmly lashed to the trunk cable with 2 or 3 nylon cable ties to keep them
from shifting.  On the other hand, the connection from the xciever cable to
the workstations is our single most common cause of network failures.  You
just can't take a stiff heavy cable and expect it to stay attached to a
flimsy slide-lock widget, especialy where the cable and/or the workstation
are capable of being moved by accident.

	The Sun 3/50 is about the worst in this respect.  We've totally
given up on thick cable for PC's too.  Our DEC, Kinetics, and TCL gear
seem to have somewhat better designed slides, but still suffer from the
inherent absurdity of the basic design.  Our UB gear has the slide locks
replaced with screws.  It makes for a non-standard cable, but at least it
doesn't fall out (this is, by the way, about the only good thing I can
think to say about our UB ethernet bridges).  We have a few machines in one
office suite on thin (with a DEC DESPR thick-to-thin repeater) and have
never had any trouble with the connections at all.
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 89 15:31:41 GMT
From:      jfinke@itsgw.rpi.edu (Jon Finke)
To:        comp.protocols.tcp-ip
Subject:   Re: Thick or Thin

In <4028@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>	I suppose the thick trunk cable is pretty tough, and the way the
>typical vampire tap xciever connects to the cable is pretty good, but the
>stupid D-15 connectors for the xciever drop cable is a disaster.  The
>xciever ends don't give us any trouble because they are hidden away in a
>ceiling or wall where nobody can touch them, and we have the drop cable
>firmly lashed to the trunk cable with 2 or 3 nylon cable ties to keep them
I have had cables like this cause problems when someone else pulls
a wire throught the ceiling, or opens the ceiling for any other reason.

>from shifting.  On the other hand, the connection from the xciever cable to
>the workstations is our single most common cause of network failures.  You
>just can't take a stiff heavy cable and expect it to stay attached to a
>flimsy slide-lock widget, especialy where the cable and/or the workstation
>are capable of being moved by accident.

We also found this to be our most common ethernet failure at RPI.
It is now standard practice here to replace slide lock hardware
with screw lock hardware for all installations.  We mostly use
thinnet, but enough equipment comes through with the DB15s
that we still convert when it arrives.   About half the equipment can
be modified without opening the covers.   I don't think we have had
a failure of a screw lock connected DB15.  We also make a lot of our
own drop cables, that way we can get the correct hoods and hardware
for them.  Some cables can also be modified for screwlock hardware.
This does preclude the use of right angle cables, but that seems a 
small price to pay for the greatly increased reliability.

-- 
Jon Finke                              jfinke@itsgw.rpi.edu
Network Systems Engineer               USERB239@RPITSMTS.BITNET
Information Technology Services        518 276 8185 (voice)
Rensselaer Polytechnic Institute       518 276 2809 (fax)

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 89 16:46:33 GMT
From:      kincl@IAG.HP.COM (Norm Kincl)
To:        comp.protocols.tcp-ip
Subject:   Re: Thinwire vs. Thickwire

You forgot to mention twisted-pair (IEEE 802.3 10BaseT).  In some
situations---especially office type environments---this can be the best
solution.  I forget the exact specs on it, but we run twisted pair from a patch
pannel to all the offices.  In addition to not having to have to string coax
around to everyone (just pull it along with the phone wire), it gives us the
flexibility to quickly patch any office into any subnet or bridged segment.
This is useful for us as people constantly move their office, yet not the
disckless cluster they are a part of.

-Norm Kincl
 Informatin Architecture Group
  Hewlett-Packard

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 89 17:41:49 GMT
From:      melanie@ph-meter.beckman.uiuc.edu (Melanie Anderson)
To:        comp.protocols.tcp-ip
Subject:   Re: Thinwire vs. Thickwire

In article <68@lcc.la.Locus.COM>, eric@lcc.la.Locus.COM (Eric Peterson) writes:
> 
> In article <8909291306.AA06775@jvnca.csc.org> aggarwal@JVNCA.CSC.ORG
(Vikas Aggarwal none) writes:
 
enough thinwire bashing, already.

im coming into this debate late; but let me throw in my 2pence anyhow:

some background:

the beckman institute is a research lab/think tank at the uofi. we have over
300,000 sqare feet on five floors plus a basement. the building is designed
to house over 700 researchers in all types of research settings from offices
to computer labs to chemistry and mri. the building is not yet at capacity
and we already have over 300 computers on site ranging from zenith laptops
to vaxes, ardents and apollos to a 32K processor connection machine. 

the design goal of the network was to provide high connectivity to 
every office, lab, conference room and public area.  therefore every room in
the building (excluding bathrooms and kitchens!) has at least one
connection to the building network. this presented some interesting cable
design problems, resulting in (if you dont belive me do the math) the
discovery that it would be 1. enormously expensive 2. very difficult 3.
would not meet connectivity requirements to use thick ethernet.

the entire building is wired with thinwire ethernet, close to 16 miles of
it, in fact. the cabling design is a rib-and-spine approach. areas of the
building were carved into logical ethernets (ribs) and each rib connects,
via cabletron thin repeaters,  to a 100Mbit beckbone (good pun, huh?) built
out of network systems en641 routers.

it WORKS, it works GREAT. i have had zero problems with the wiring, ~zero
problems with the repeaters (out of over 700 repeater ports i have had 1
fail). somebody comes in, they get a chunk of cable from central stores for
6 bucks, they come to me, i give them a new IP number and tell them what
their default gateway ip address is (for those brain-dead ips out there!),
they go up to their office, they plug in, and off they go!

in fact, this wiring scheme and these repeaters have worked so well the same
system is being used in a 400-port new installation in the psychology
building on campus, in the cedar project addition (100+ ports) and will
probably be used in other new construction.

> >
> >Just to collect one's views on Thinwire ethernet vs Thickwire ethernet,
> >I am listing what I know about the topic:
> >
> >THINWIRE
> >
> >	Flexible, Low cost ( app. $3.00 per meter ), 10 Mb bandwidth,
> > 	Max segment length - 185 meters (30 nodes per segment), One 
> >	multiport repeater can handle upto 8 segments

where are you buying your repeaters from? here at beckman i have 33 thinwire
repeaters purchased from cabletron. they support anywhere from 12 thin and
two thick connections to 84 thin segments and two thick. also, if you are
using a repeater, you only get 28 nodes a  segment. the plus to using thin
repeaters over conventional thick is that most reapeaters are smart enough
to shut down a port if it detects a  bizzare electrical condition like a
short, open or fluctuation in resistance. in exremely large networks, this
intelligence can save hours or days of time. it also fixes the problem below.

> 
> 	From past experience, I recommend this for only very small or 
> 	temporary nets.  The cable is fragile, and the cable -> BNC
> 	connection is especially susceptible to breakage (we once had
> 	a janitor vacuuming the floor accidentally hit the cable and 
> 	yank it out of the BNC connector, he noticed the damage and
> 	managed to push the cable back into the connector - needless
> 	to say, it was a poor connection and that whole floor of the
> 	building suffered from intermittent Ethernet problems for 
> 	several days while we looked for the problem).
> 

first, i would bet that a thick transciever cable would be damaged by this
kind of rough treatment, as well. also, you might want to suggest that if
someone breaks something, they report it, rather than try to fix it...

second, i would suggest you investigate who is doing your bnc terminations. i
have over 2000 terminations in this building and very few (~25) have been
demolished, usually by furniture being set on them. i would argue that you
would have the same problem with el-cheapo thick connections. i do have wall
and floor boxes installed. NO wiring should lie on a floor, be it rs-232,
power, ether or piano. 

> >THICKWIRE
> >
> >	More resilient for running through floors and ceilings,	Higher 
> >	cost (app $11.00 per meter), 10 Mb bandwidth, Max segment 
> >	length - 500 meters
> >
> >Based on the above, I would choose thickwire ONLY if the length of the
> >segment had to be more than 500 mts or if the wire was going to run 
> >through adverse areas.
> 

thin ethernet with a toughened-up pvc or teflon coating is available for
adverse-condition or plenum applications. like i said, even our long
underfloor and overhead runs are thinwire. thick is appropriate for certain 
applications. 

i strongly believe, however, that whatever your wiring application, 
that ribs-n-spine be used in any new large network. saves you much time and
effort and grief. it is flexible, reconfigurable, and expandable. try to
divvy your network up into ribs and then firewall them off from each other
so that one looney machine wont crash everyone.

whatever you do, PLAN for cut wires, smushed connectors, gonzo 
transcievers, crazy ethernet cards, and broken software. DONT assume 
all computers will play well with others. expect the worst because it 
WILL happen. 

> 
> 	Another solution is to use multiport transceivers to disribute
> 	the Ethernet.  It is much less susceptible to damage (or I should
> 	say, if damage _does_ occur, it doesn't propagate throughout the
> 	network.)  I believe the spec allows xcvr cable runs up to 50
> 	meters away, and the multiports that I've seen allow up to two 
> 	levels of stacking the xcvrs.  Another advantage is that some
> 	Ethernet boards do not have the built-in thin wire BNC connector.
> 
yeah, you have to buy a transciever for any machine that doesn have an
on-board transciever. the thin transcievers are the same price, or cheaper,
than thick. 

you can also put a delni-alike on thinwire ethernet (see above.)


Melanie Anderson			melanie@ph-meter.beckman.uiuc.edu
Beckman Institute			217/244-1079
Unversity of Illinois

-----------------------------------------------------------------------------
   "N4634X, Champaign Tower, uhh, what's that hanging off your wing?"
-----------------------------------------------------------------------------

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 89 17:49:00 GMT
From:      ljm@TWG.COM (Leo J McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   tcp-ip@nic.ddn.mil (was Re: Commenct on RFC1124 (?)



>	My feeling on this one is that *all* PS documents should be "first
>page first".  It's the job of the spooler software to determine if page
>reversal is appropriate for a particular printer...

I think this discussion is now, officially, lost in the weeds.

enjoy,
leo j mclaughlin iii
The Wollongong Group
ljm@twg.com

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 89 19:56:32 GMT
From:      zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff)
To:        comp.protocols.tcp-ip
Subject:   Re:  PostScript Versus ASCII

I vote for ascii text with postscript diagrams (that can't be done in 
ascii) tacked on to the end.  

You have just one version, you can grep through it, you till have nice
diagrams for people who can deal with cutting out and printing postscript.

Might also be nice if there was a us mail address that you could send 
off for paper copies.  

-- 
Branch Technology            |  zeeff@b-tech.ann-arbor.mi.us
                             |  Ann Arbor, MI

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      4 Oct 89 23:36:18 GMT
From:      ayres@ucs.orst.edu (Bill Ayres - UCS)
To:        comp.protocols.tcp-ip
Subject:   Wellfleet, Network Systems Contacts

I can't seem to find addresses or phone numbers for Wellfleet and
Network Systems. Can someone help me out? Thanks!

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 89 00:56:01 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  PostScript Versus ASCII

David,

Sources to RFC-1119.PS are in the compressed tar file pub/ntp/ntp.tar.Z
on louie.udel.edu. See if the files ntpr.doc and ntprh.doc come close
to what you want. They are in MS-Word format.

Dave

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 89 01:04:54 GMT
From:      manglik@bgsuvax.UUCP (Pankaj Manglik)
To:        comp.protocols.tcp-ip
Subject:   Courier (remote procedure calls) by Xerox

I am looking for some information about 'COURIER' which is the rpc package
as specified by XEROX. Can anyone tell where I might be able to find
such info. Thanks.

Pankaj Manglik

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 89 01:13:28 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  PostScript Versus ASCII

Terry,

I fully understand your desire that the CAP source files follow the
latest versions of vendor software; however, I do not have the resources
necessary to upgrade all my old submissions to follow the newest versions.
Maybe in time ODA will converge, the vendors will follow and I can get
some sleep.

Dave
Ds

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 89 02:20:39 GMT
From:      kjm@ut-emx.UUCP
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?) / OSI Transition

In article <8910022323.AA11747@venera.isi.edu>, pvm@VENERA.ISI.EDU
           (Paul Mockapetris) writes:
> Most of the arguments to date have focused on two issues:
> 
>       Freedom to print RFCs
> and
>       Freedom to GREP RFCs
> 
> [...]
> I think that the second freedom
> is desirable but has to strike a balance against progress.

Losing a powerful capability is progress?  Right...

> I can't
> imagine RFCS about X, multimedia, or several other topics without
> graphics.

Which could perfectly well be done as separate plates, as previously
mentioned.

> I also wanted to add that we could view the passing of the second
> freedom as a step in the transition to OSI.  I suggest the following
> sequence:
> 
> 1     Text RFCs.
> 2     Text and PS RFCs which are less accessible.
> ...
> 7     Copyrighted RFCs with ISO/CCITT numbers which must be purchased.

You want to make it as hard as you think you can get away with for people
to implement new Internet software, do you?

--
The above viewpoints are mine.  They are unrelated to those of
anyone else, including my wife, our cats, and my employer.

Kenneth J. Montgomery               Senior Operating System Specialist
kjm@hermes.chpc.utexas.edu          University of Texas System
                                    Center for High Performance Computing

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 89 12:30:03 GMT
From:      kratz@bnrgate.bnr.ca (Geoff Kratz)
To:        comp.protocols.tcp-ip
Subject:   Re: Thinwire vs. Thickwire

Before I start, I want to say this I do not want to bash thin-net.  The
purpose of this is more to provide an alternative for those people who
are now (will soon be) building a LARGE ethernet site.

In article <1989Oct4.174149.9451@ux1.cso.uiuc.edu>, melanie@ph-meter.beckman.uiuc.edu (Melanie Anderson) writes:
> In article <68@lcc.la.Locus.COM>, eric@lcc.la.Locus.COM (Eric Peterson) writes:
> > 
> > In article <8909291306.AA06775@jvnca.csc.org> aggarwal@JVNCA.CSC.ORG
> (Vikas Aggarwal none) writes:
>  
> enough thinwire bashing, already.
> 
> im coming into this debate late; but let me throw in my 2pence anyhow:
> 
> some background:
> 
> the design goal of the network was to provide high connectivity to 
> every office, lab, conference room and public area.  therefore every room in
> the building (excluding bathrooms and kitchens!) has at least one
> connection to the building network. this presented some interesting cable
> design problems, resulting in (if you dont belive me do the math) the
> discovery that it would be 1. enormously expensive 2. very difficult 3.
> would not meet connectivity requirements to use thick ethernet.

It would have been as trivial with UTP.  We are located in a number
of buildings, but a prototypical one would be:

      1000-2000 people
      about 1000+ machines (workstations, mainframes, PC's, Macs)
      about 4000+ ports of repeaters (on the hubs, bridges and delnis)

And we move equipment around a LOT.

Using UTP allowed us to put the backbone in a central location, and then
build a star from there.  Since we already have 4-pair cables running to
the floor, wiring was cheap.  We did find, though, that the cost per seat
was about $800 when installation of the cable was included (that includes
the prices of the twisted pair, MAU, hubs, bridges and delnis).  Cheaper,
of course, when the cable was already in place.  And it can get as good
as $400-500 per seat (depending on numbers).

> it WORKS, it works GREAT. i have had zero problems with the wiring, ~zero
> problems with the repeaters (out of over 700 repeater ports i have had 1
> fail). somebody comes in, they get a chunk of cable from central stores for
> 6 bucks, they come to me, i give them a new IP number and tell them what
> their default gateway ip address is (for those brain-dead ips out there!),
> they go up to their office, they plug in, and off they go!

We tried thin in a few locations, and got burned by poor construction (this
is probably not true of all manufacturers thing products).  Just shifting
a workstation could cause the T-connector to come off the BNC, thus causing
a break and taking out the entire segment.

We find that with UTP, a MAU can die and have no adverse affect on the net
(depends on the type of death of course.  If it just fails and stops functioning
no problem.  If it decides to transmit junk, that's a different story).

On the rare occasion that a hub decides to lose its mind, the effect can vary
(depends on where the hub is located in the topology).  At most, though,
you will lose a segment behind a bridge.  We have yet to have a bad bridge
or hub take out the entire subnet within a building.

> i strongly believe, however, that whatever your wiring application, 
> that ribs-n-spine be used in any new large network. saves you much time and
> effort and grief. it is flexible, reconfigurable, and expandable. try to
> divvy your network up into ribs and then firewall them off from each other
> so that one looney machine wont crash everyone.

Yup, same with UTP.  You use hubs to build a star, use the bridges as
traffic filters and use routers to build multiple backbones.  As well,
moves involve moving a pair of jumper wires on a BIXX block.

> whatever you do, PLAN for cut wires, smushed connectors, gonzo 
> transcievers, crazy ethernet cards, and broken software. DONT assume 
> all computers will play well with others. expect the worst because it 
> WILL happen. 

You betcha!  And expect some of the users to get "creative" too.

Large sites do present an interesting problem and an incredible opportunity
to do it right (or screw it up REAL GOOD!) whether it is thick, thin or
UTP.
-- 
Geoff Kratz         Bell-Northern Research, Ltd.    Ph: (613) 763-5784
Internet Systems      P.O. Box 3511, Station C      FAX:(613) 763-3283
                    Ottawa Ontario Canada K1Y 4H7
BITNET: kratz@bnr.ca

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Oct 89 17:08:30 EDT
From:      "Joann M. Santos" <jsantos@ccb.bbn.com>
To:        tcp-ip@nic.ddn.mil
Cc:        jsantos@ccb.bbn.com, sschultz@ccb.bbn.com
Subject:   Press Release from BBN Communications Corporation

FOR IMMEDIATE RELEASE                CONTACT:  Joann Santos (617) 873-2805
                                               Sheryl Schultz (617) 873-2479

              BBN COMMUNICATIONS RECEIVES NIST NVLAP ACCREDITATION

            TO PERFORM DoD HIGH LEVEL PROTOCOLS CONFORMANCE TESTING

               New Offerings Joins DDN X.25 on Dedicated Testbed

         CAMBRIDGE, Mass., October 4 -- BBN Communications Corporation
announced today that it has received accreditation from the National Institute
of Standards and Technology (NIST)'s National Voluntary Laboratory
Accreditation Program (NVLAP) to perform conformance testing for Department of
Defense High Level Protocols (HLP).  BBN Communications is the first, and at
this time the only, organization to provide this type of testing for HLP.
         In accordance with a memorandum issued in August 1988 by the
Assistant Secretary of Defense for C3I, all implementations of military
standard protocols procured by all military services and agencies must pass
the tests conducted by a NIST NVLAP accredited laboratory.  This requirement
specifically applies to MILSTDs 1777(IP), 1778(TCP), 1780(FTP), 1781(SMTP),
and 1782(TELNET).  The requirement for testing went into effect June 1, 1989.
         BBN received similar accreditation for X.25 testing in March.  Both
X.25 and HLP testing services are available using dedicated facilities at the
company's Cambridge, Mass. TestNetTM lab.
         According to Jack Haverty, Chief Architect at BBN Communications,
"The TestNet lab provides a realistic environment in which systems may be
configured, tested, staged and prepared for use on the DDN and other
networks.  By using BBN facilities, vendors can draw on one centralized
resource, thereby eliminating the need for sophisticated protocol experts on
their own staffs.
         "We test products the way they will be used in the field.  We can
perform standalone tests, testing against reference hosts, or testing against
real production systems," added Haverty.  "We can also assist users to
qualify new protocol implementations, stage new hosts before deployment to
the Internet, and do regression testing of software each time their host or
network software is changed."

HLP Testing on Dedicated Testbed
         The HLP conformance testing performed by BBN utilizes the TCP/IP
Upper Level Protocol Qualification Tests developed by the Defense
Communications Engineering Center.  BBN's TestNet includes a dedicated
network comprised of BBN Communications C/30TM Packet Switching Nodes (PSNs)
and PSN software, like those used in DDN/MILNET/ARPANET. The TestNet
environment also includes internet gateways and hosts running IBM and DEC
protocols as well as TCP/IP.

Protocol Testing Key to Networking Success
         In addition to the NIST-accredited DDN HLP and X.25 testing, BBN
offers a range of protocol, interface and network-oriented application
testing services, including basic X.25 testing, basic/extended
interoperability testing, and basic/extended application testing.
         BBN also offers general consulting in the areas of communications
protocols, testing, and software implementation of network protocols for
government and commercial clients.

         A wholly owned subsidiary of Bolt Beranek and Newman Inc., BBN
Communications designs and builds private wide-area communications networks
for commercial, government and international organizations.  The company also
provides network consulting, management, and other professional services.
For the fiscal year ending June 30, 1989, Bolt Beranek and Newman had sales
of $292 million.

C/30 is a trademark of BBN Communications Corporation.


1989.
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Thu, 05 Oct 89 17:16:00 EDT
From:      "Gary S. Miliefsky" <GMILIEFS@mitvma.mit.edu>
To:        tcp-ip@NIC.DDN.MIL
Subject:   RFC for MPUT and MGET in FTP . . .

======================================================================== 36


I will be implementing MPUT and MGET in an FTP Client and have not
been able to find an RFC for these two commands.  If an RFC or a
draft of some sort does exist, I would appreciate knowing about it.
If not, I would like to of your interest in the formal documentation
of these commands in a new RFC.  Comments and suggestions are most
welcome.  Thank you in advance.


Sincerely,

Gary S. Miliefsky

gmiliefs@mitvma.mit.edu
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 89 14:42:05 GMT
From:      sgrimm@sun.com (Steven Grimm)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?) / OSI Transition

Seems to me that posting an entire RFC in PostScript is like posting a Sun-3
binary to comp.sources.unix.

---
"                                                  !" - Marcel Marceau
Steven Grimm		Moderator, comp.{sources,binaries}.atari.st
sgrimm@sun.com		...!sun!sgrimm

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 89 14:59:55 GMT
From:      mkg@cci632.UUCP (Manoj K. Garg)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP code sources



	Hi folks,

		I am new to this newsgroup so this might seem like an old
	question. We have a unix box that is an older version of UNIX as
	opposed to Berkeley or the latest system V unix. I am looking for 
	companies that have TCP/IP source available for purchase that would
	be easily integratable into an older version of UNIX. i.e. it does
	not require mbufs,or berkeley sockets or even streams. I would 
	appreciate any help I could get about such companies. Thanks a lot.

							Manoj Garg.

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Thu, 5 Oct 89 15:54:13 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Thick or Thin

In article <4028@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
> The Sun 3/50 is about the worst in this respect...  Our DEC, Kinetics,
> and TCL gear seem to have somewhat better designed slides...

It's worth pointing out that the problems on the Suns are not just poor
design, they are out-and-out violations of the specs for the connector
mounting.  The connectors never get a chance to seat to their full depth.
Actually meeting the letter of the law of the specs takes work and is a
bit inconvenient; Sun didn't bother.
-- 
Nature is blind; Man is merely |     Henry Spencer at U of Toronto Zoology
shortsighted (and improving).  | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 89 16:59:49 GMT
From:      jh@tut.fi (Hein{nen Juha)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   tcp/ip terminal servers with slip support?

Our university is installing a bank of V.32 modems and would like to
connect them to a tcp/ip terminal server with SLIP support.  I know
that Cisco has such a server but are there any others?
--
--	Juha Heinanen, Tampere Univ. of Technology, Finland
	jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)

-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 89 17:25:36 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?) / OSI Transition

In article <8910022323.AA11747@venera.isi.edu>, pvm@VENERA.ISI.EDU (Paul Mockapetris) writes:
> I think that the second freedom [to have RFCs online for processing]
> is desirable but has to strike a balance against progress.
 
> I suggest the following sequence:
 
> 1	Text RFCs.
> 2	Text and PS RFCs which are less accessible.
> n	Copyrighted RFCs with ISO/CCITT numbers which must be purchased.

This is "progress", Mr. Mockapetris?

Looks like a giant step backwards to me. Why on earth is this in any way
a desirable step?
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
``I feel that any [environment] with users in it is "adverse".''           'U`
	-- Eric Peterson <lcc.eric@seas.ucla.edu>

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 89 21:08:30 GMT
From:      jsantos@CCB.BBN.COM ("Joann M. Santos")
To:        comp.protocols.tcp-ip
Subject:   Press Release from BBN Communications Corporation


FOR IMMEDIATE RELEASE                CONTACT:  Joann Santos (617) 873-2805
                                               Sheryl Schultz (617) 873-2479

              BBN COMMUNICATIONS RECEIVES NIST NVLAP ACCREDITATION

            TO PERFORM DoD HIGH LEVEL PROTOCOLS CONFORMANCE TESTING

               New Offerings Joins DDN X.25 on Dedicated Testbed

         CAMBRIDGE, Mass., October 4 -- BBN Communications Corporation
announced today that it has received accreditation from the National Institute
of Standards and Technology (NIST)'s National Voluntary Laboratory
Accreditation Program (NVLAP) to perform conformance testing for Department of
Defense High Level Protocols (HLP).  BBN Communications is the first, and at
this time the only, organization to provide this type of testing for HLP.
         In accordance with a memorandum issued in August 1988 by the
Assistant Secretary of Defense for C3I, all implementations of military
standard protocols procured by all military services and agencies must pass
the tests conducted by a NIST NVLAP accredited laboratory.  This requirement
specifically applies to MILSTDs 1777(IP), 1778(TCP), 1780(FTP), 1781(SMTP),
and 1782(TELNET).  The requirement for testing went into effect June 1, 1989.
         BBN received similar accreditation for X.25 testing in March.  Both
X.25 and HLP testing services are available using dedicated facilities at the
company's Cambridge, Mass. TestNetTM lab.
         According to Jack Haverty, Chief Architect at BBN Communications,
"The TestNet lab provides a realistic environment in which systems may be
configured, tested, staged and prepared for use on the DDN and other
networks.  By using BBN facilities, vendors can draw on one centralized
resource, thereby eliminating the need for sophisticated protocol experts on
their own staffs.
         "We test products the way they will be used in the field.  We can
perform standalone tests, testing against reference hosts, or testing against
real production systems," added Haverty.  "We can also assist users to
qualify new protocol implementations, stage new hosts before deployment to
the Internet, and do regression testing of software each time their host or
network software is changed."

HLP Testing on Dedicated Testbed
         The HLP conformance testing performed by BBN utilizes the TCP/IP
Upper Level Protocol Qualification Tests developed by the Defense
Communications Engineering Center.  BBN's TestNet includes a dedicated
network comprised of BBN Communications C/30TM Packet Switching Nodes (PSNs)
and PSN software, like those used in DDN/MILNET/ARPANET. The TestNet
environment also includes internet gateways and hosts running IBM and DEC
protocols as well as TCP/IP.

Protocol Testing Key to Networking Success
         In addition to the NIST-accredited DDN HLP and X.25 testing, BBN
offers a range of protocol, interface and network-oriented application
testing services, including basic X.25 testing, basic/extended
interoperability testing, and basic/extended application testing.
         BBN also offers general consulting in the areas of communications
protocols, testing, and software implementation of network protocols for
government and commercial clients.

         A wholly owned subsidiary of Bolt Beranek and Newman Inc., BBN
Communications designs and builds private wide-area communications networks
for commercial, government and international organizations.  The company also
provides network consulting, management, and other professional services.
For the fiscal year ending June 30, 1989, Bolt Beranek and Newman had sales
of $292 million.

C/30 is a trademark of BBN Communications Corporation.


1989.

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 89 21:16:00 GMT
From:      GMILIEFS@MITVMA.MIT.EDU ("Gary S. Miliefsky")
To:        comp.protocols.tcp-ip
Subject:   RFC for MPUT and MGET in FTP . . .


======================================================================== 36


I will be implementing MPUT and MGET in an FTP Client and have not
been able to find an RFC for these two commands.  If an RFC or a
draft of some sort does exist, I would appreciate knowing about it.
If not, I would like to of your interest in the formal documentation
of these commands in a new RFC.  Comments and suggestions are most
welcome.  Thank you in advance.


Sincerely,

Gary S. Miliefsky

gmiliefs@mitvma.mit.edu

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      5 Oct 89 23:14:04 GMT
From:      ben@val.uucp (Ben Thornton)
To:        comp.protocols.tcp-ip
Subject:   Re: PostScript Versus ASCII

perry@Morgan.COM (Perry Metzger) writes:

>What about people who want to read their RFC's today? So far as I
>know, GhostScript has no outline fonts and doesn't drive any laser
>printers that I own. Besides, it is written in C. What happens to
>those people who are using machines other than Unix boxes? Since when
>did they become second class citizens? What happened to people without
>laser printers? Not everyone has them, you know.

Hear, hear.

Postscript is very inefficient about getting something onto paper in a
hurry, so far as text is concerned.  Where is excels is its ability to
execute algorithmic procedures for plotting mathematically-defined
entities (besides the cubic-splined fonts).  Unfortunately, not very
many applications support that aspect of the language.  Oh well.


-- 

Ben Thornton             packet:  WD5HLS @ KB5PM
Video Associates Labs      uucp:  ...!cs.utexas.edu!oakhill!val!ben
Austin, TX              fidonet:  1:382/40 - The Antenna Farm BBS

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 89 07:27:44 GMT
From:      pcf@galadriel.bt.co.uk (Pete French)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: tcp/ip terminal servers with slip support?

From article <JH.89Oct5185949@korppi.tut.fi>, by jh@tut.fi (Hein{nen Juha):
> Our university is installing a bank of V.32 modems and would like to
> connect them to a tcp/ip terminal server with SLIP support.  I know
> that Cisco has such a server but are there any others?

O.K. - I give up, I have been reading this group now for 3 months so will
somebody please mai me and tell me what SLIP is please.

Apollogies for ignorance.

-Pete.

-- 
       -Pete French.               | "Love is the corpse,
  British Telecom Research Labs.   |  That crawls on dreams,
 Martlesham Heath, East Anglia.    |  Rips them apart,
All my own thoughts (of course)    |  And tears them to shreds" - SOM

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 89 09:03:19 GMT
From:      prc@erbe.se (Robert Claeson)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: tcp/ip terminal servers with slip support?

In article <JH.89Oct5185949@korppi.tut.fi> jh@tut.fi (Hein{nen Juha) writes:

>Our university is installing a bank of V.32 modems and would like to
>connect them to a tcp/ip terminal server with SLIP support.  I know
>that Cisco has such a server but are there any others?

Certainly. The Annex II terminal server has SLIP and full IP routing support.
-- 
          Robert Claeson      E-mail: rclaeson@erbe.se
	  ERBE DATA AB

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 89 10:26:19 GMT
From:      RIDOUT@ddnvx1.afwl.af.mil (Brian Ridout AFWL/SCEV (av) 244-1654 (505) 844-1654)
To:        comp.protocols.tcp-ip
Subject:   LPR print server box

Hi
I am looking for a terminal server / print server to install onto Thick
Ethernet which uses TCP/IP as the protocol and does not use permanent
circuits.  I would instead like it to support Lpr, Lpq, Lpd, ... etc.
This would allow several machines to share a printer with out the printer
being attached to a mainframe or workstation.  Serial ports out the back
of machine are at a premium around here.

Is there such a beast?

Please Email I'll post if it is intresting. 
-- 
****************************************************************************
*  Brian Ridout                     Internet: ridout@ddnvx1.afwl.af.mil    *
*  wl/scev                                                                 *
*  Kirtland AFB NM 87117            "Sorry I have nothing funny to say"    *
****************************************************************************

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 89 12:26:41 GMT
From:      scp@bpa.BELL-ATL.COM (Steve Parowski)
To:        comp.protocols.ibm,comp.protocols.tcp-ip
Subject:   TCP/IP and IBM SNA Gateway Service

I am posting this question for a second time, because I have
read some information on the NET about MYTEK client/server
hardware and software that does protocol convewrsion. 

I would like to have my 3270 terminal to have access to 
TCP/IP TELNET and FTP services. Has anyone used the Mytek product
and can you supply me with some of its on-line characteristics.

Number of simultaneous sessions?

Response time?........

Also, I have read that NIXDORF has done this emulation and it
was in the trial phases with AMDAHL.  The Hanover fair last 
March also published some information on such an application.

I would appreciate any more help???...

Steve
:w

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 89 12:55:38 GMT
From:      2012_1262@uwovax.uwo.ca
To:        comp.protocols.tcp-ip
Subject:   TCP-IP for RSX-11M

Has anyone seen TCP-IP software for an LSI-11 running RSX11M.
I would like to connect this old baby to a Unix workstation.
The only other solutions are to go serial, or to buy DMA boards
for each and write my own software. All other suggestions would
be appreciated. Thanks.-- 
Henry Leparskas
Dept. of Astronomy
Rm. 213 Physics and Astronomy
University of Western Ontario
London, On, Canada N6A 3K7
(519) 661-2009 or 661-2111 ext. 8697
H.Leparskas@uwovax.uwo.ca
H.Leparskas@uwovax.uwo.BITNET

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 89 18:48:33 GMT
From:      ilham@ATHENA.MIT.EDU (Ilhamuddin Ahmed)
To:        comp.protocols.tcp-ip
Subject:   Palladium mailing list


There is a new mailing list for the Athena Palladium Print System on
which announcements will be made. The list is palladium@athena.mit.edu.
If you wish to be added, please send mail to :

	palladium-request@athena.mit.edu

							- Ilham
							  Project Athena.

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 89 19:31:15 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: rwhod protocol and >42 users


	It isn't a protocol change to increase the max rwho packet size. It's
an implementation change. We've been running with large rwho packets for years
(our Sequents support a couple hundred users without even blinking).
	You need to increase the size in "rwho.h" and increase the max udp
packet size (udp_sendspace and udp_recvspace) in sys/netinet/udp_usrreq.c.
And FINALLY, you need to ifdef out the code that refuses to fragment broadcast
packets in sys/netinet/ip_output.c.
	All of the changes are trivial. I can provide context diffs if you
ask me.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      6 Oct 89 23:19:57 GMT
From:      baker@VITAM6.UUCP (Fred Baker)
To:        comp.protocols.tcp-ip
Subject:   thick/thin/twisted

Something I haven't seen commented on is the cost of installation.
My experience tells me that Thick is generally in a relatively accessible
place, where thin and twisted wire wants to run in conduit or in the walls.
Yes, the cost of thick cable is gimongous, but what is the cost of the guy
who places it?

Fred Baker
baker@vitalink.com

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      Sat, 07 Oct 89 11:35:03 CST
From:      Cheng-ping Chang <IIIG010%TWNMOE10.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Ask for SOCKET source code
Dear Sirs,

I am wondering whether you have the source code of the SOCKET library of
UC Berkely's 4.2 BSD UNIX or the source code of socket for XENIX system,
and, if so, should be glad to know how to get them.  Your early reply
will be highly apprepriated.  Thank you very much for your kind assistance.




C. P. Chang
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 89 16:06:42 GMT
From:      LVARIAN@PUCC.PRINCETON.EDU ("Lee C. Varian")
To:        comp.protocols.tcp-ip
Subject:   Re: Courier (remote procedure calls) by Xerox

On Thu, 5 Oct 89 01:04:54 GMT Pankaj Manglik said:
>I am looking for some information about 'COURIER' which is the rpc package
>as specified by XEROX. Can anyone tell where I might be able to find
>such info. Thanks.
>
>Pankaj Manglik

Xerox standards documents may be ordered from Xerox Systems Institute at
the following address:    Xerox Corporation
                          475 Oakmead Parkway
                          Sunnyvale, CA 94086
                          Attn: Xerox Systems Institute
                          MS: SVHQ 4
                          (408) 737-4652
I think the manual you want is "Courier: The Remote Procedure Call Protocol",
Dec. 1981, XNSS 038112, $20.  A Xerox Literature Catalog is available free.
  Lee Varian
  Princeton University

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 89 17:35:03 GMT
From:      IIIG010@TWNMOE10.BITNET (Cheng-ping Chang)
To:        comp.protocols.tcp-ip
Subject:   Ask for SOCKET source code

Dear Sirs,

I am wondering whether you have the source code of the SOCKET library of
UC Berkely's 4.2 BSD UNIX or the source code of socket for XENIX system,
and, if so, should be glad to know how to get them.  Your early reply
will be highly apprepriated.  Thank you very much for your kind assistance.




C. P. Chang

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 89 19:02:34 GMT
From:      wbe@bbn.com (Winston Edmond)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc
Subject:   Re: FTP (the company, not the protocol) required

I tried to reply to you by mail directly, but my mailer didn't like
"edvvie.at" as a domain name.

   Try:	FTP Software, Inc.
	501 Cambridge St.
	Cambridge, MA  02141
	(U.S.) 617-868-4878 [phone]

 -WBE

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 89 22:20:14 GMT
From:      madd@bu-cs.BU.EDU (Jim Frost)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc
Subject:   Re: FTP (the company, not the protocol) required

In article <46653@bbn.COM> wbe@BBN.COM (Winston Edmond) writes:
|Try:	FTP Software, Inc.
|	501 Cambridge St.
|	Cambridge, MA  02141
|	(U.S.) 617-868-4878 [phone]

They have moved, although I would be surprised if you couldn't find
out to where by either mailing or calling the old address/number.
Sorry but I don't have the new address.

jim frost
madd@std.com

-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      7 Oct 89 22:23:07 GMT
From:      earle@poseur.JPL.NASA.GOV (Greg Earle - Sun JPL on-site Software Support)
To:        comp.protocols.tcp-ip
Subject:   Re: Thick or Thin

In article <1989Oct4.153141.19593@rpi.edu> jfinke@itsgw.rpi.edu (Jon Finke) writes:
>It is now standard practice here to replace slide lock hardware
>with screw lock hardware for all installations.  We mostly use
>thinnet, but enough equipment comes through with the DB15s
>that we still convert when it arrives.

Please, people, think about what you are talking about before you post.
There is no reason a thread about Ethernet cabling and DB-15 connectors should
be cluttering up the TCP-IP mailing list (a.k.a. comp.protocols.tcp-ip).
Please take it over to comp.dcom.lans where it belongs.

(We now return you to the "ASCII vs. PostScript" 15-round title bout (^: )

--
	Greg Earle
	Sun Microsystems, Inc. - JPL on-site Software Support
	earle@poseur.JPL.NASA.GOV	(direct)
	earle@Sun.COM			(indirect)

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 89 01:01:58 GMT
From:      glen@aecom.yu.edu (Glen M. Marianko)
To:        comp.protocols.tcp-ip
Subject:   Re: Thinwire vs. Thickwire (Why 30 nodes only on thin?)

In article <8909291306.AA06775@jvnca.csc.org>, aggarwal@JVNCA.CSC.ORG (Vikas Aggarwal none) writes:
> 
> Just to collect one's views on Thinwire ethernet vs Thickwire ethernet,
> I am listing what I know about the topic:
> 
> THINWIRE
> ...
> 	Max segment length - 185 meters (30 nodes per segment)

This posting reminded me of a question I had about thin ethernet and
the 30 nodes per segment limit.  Why is this?  I thought on thin
ethernet you can have a node every .5 meters (vs. thick which is
marked for much more).  If so, then 185/.5=370 according to my
calculator with the weak battery :-).  So why couldn't I have more
than 30 workstations?    Tell ya, the only place I ever saw this in
print was in a DEC catalog.  Maybe this is a DEC restriction?
-- 

-- Glen M. Marianko  Manager, LAN Services  Glasgal Communications, Inc.
   151 Veterans Drive  Northvale, New Jersey 07647  201-768-8082
   glen@aecom.yu.edu - {uunet}!aecom!glen (Courtesy of AECOM & unaffiliated)

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Sun, 08 Oct 89 11:06:40 PDT
From:      Paul Mockapetris <pvm@venera.isi.edu>
To:        gem.mps.ohio-state.edu!wuarchive!texbell!sugar!ficc!peter@apple.com (Peter da Silva)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Comment on RFC1124 (?) / OSI Transition
> In article <8910022323.AA11747@venera.isi.edu>, pvm@VENERA.ISI.EDU (Paul Mockapetris) writes:
> > I think that the second freedom [to have RFCs online for processing]
> > is desirable but has to strike a balance against progress.
> 
> > I suggest the following sequence:
> 
> > 1	Text RFCs.
> > 2	Text and PS RFCs which are less accessible.
> > n	Copyrighted RFCs with ISO/CCITT numbers which must be purchased.
> 
> This is "progress", Mr. Mockapetris?

No, this was sarcasm.  The fact that n was 7 in the original posting
should have been a tip off, but 20 odd messages later, I find that
people took it seriously.  I can't get over the fact that standards
for "Open Systems" are not themselves open.  (I am familiar with the
usual excuses, so don't bother to round them up for me.)  I like the
TCP/IP world's method (with or without PS) much better, thank you.

paul
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 89 19:16:41 GMT
From:      nagle@well.UUCP (John Nagle)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for MPUT and MGET in FTP . . .


      Points to know about FTP history:

	1) 3-cornered FTP (source, destination, and control points on 
	   different hosts) never worked.

	2) Transferring many small files in succession tends not to work.
	   If you try to reuse the data connection immediately, it won't
	   reopen, even though the TCP spec says it should.  This is a bug
	   in the spec.  Most current FTP implementations use the PORT
	   command to get a new data connection for each file, leaving the
	   old one to time out in TIME_WAIT state.  This can result in
	   resource exhaustion when many small files are being transferred.
	   This problem can be worked around, at some cost in throughput
	   in the many-tiny-file case.

						John Nagle

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Oct 89 19:46:54 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   ether collision backoff

(I'm sorry to talk about ethernets here, but I don't think enough
knowledgable people read other forums.)

At last week's Interop, I was told that a large workstation company's
products can be configured to use non-standard retransmission-after-collision
delays.

Is this true?  Does it cause big problems, as my informant implied?
Exactly which parameter(s) is(are) changed--the exponent, the multiplier,
the algorithm?  Does it really help NFS that much?  Is there a relevant
de-facto or de-jurie standard?  Should Silicon Graphics do the same thing?
Are the Protocol Police about to squash the idea?

Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 89 00:53:56 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for MPUT and MGET in FTP . . .

In article <14005@well.UUCP> nagle@well.UUCP (John Nagle) writes:
> 	1) 3-cornered FTP (source, destination, and control points on 
> 	   different hosts) never worked.

	I'm curious as to why third-party FTP was ever invented.  It's sort
of neat, but always seemed to me to be complicated and unnecesary.  Was it
envisioned that it would be a poplular thing?
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 89 02:51:10 GMT
From:      dyer@spdcc.COM (Steve Dyer)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for MPUT and MGET in FTP . . .

In article <14005@well.UUCP> nagle@well.UUCP (John Nagle) writes:
>	1) 3-cornered FTP (source, destination, and control points on 
>	   different hosts) never worked.

I *seem* to remember 3-cornered FTP working on NCP hosts, while I was at BBN,
but then I might just be prematurely senile...

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 89 06:11:26 GMT
From:      skl@van-bc.UUCP (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for MPUT and MGET in FTP . . .

In article <14005@well.UUCP> nagle@well.UUCP (John Nagle) writes:
> 1) 3-cornered FTP (source, destination, and control points on 
>    different hosts) never worked.

I had to use it in a few past occasions and it worked for me, although
it's a bit tedious to use since I couldn't find a FTP client that will
do it and ended up talking to the two remote servers manually over a
couple of Telnet calls.

Or did you really mean "it was never a popular thing?"  (That I agree.)

...Sam
-- 
Samuel Lam     <skl@wimsey.bc.ca> or {uunet,ubc-cs}!wimsey.bc.ca!skl

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 89 13:29:00 GMT
From:      josef@ugun13.UUCP
To:        comp.protocols.tcp-ip
Subject:   Where can I get RFCs?



I am new to the block, so forgive me:

I have heard, that RFCs are freely available from some site.
What's the network address of this site and can one access it
without ftp (I'm calling from the other side of the Atlantic River).

		Josef Moellers

	paper mail:			e-mail:
c/o Nixdorf Computer AG		USA:  uunet!philabs!linus!nixbur!mollers.pad
Abt. DX-PC			!USA: mcvax!unido!nixpbe!mollers.pad
Pontanusstr.				Phone:
D-4790 Paderborn		(+49) 5251 146243
+-----------------------------------------------------------------------+
| "Many that live deserve death. And some that die deserve life.	|
|  Can You give it to them? Then do not be too eager to deal out	|
|  death in judgement"							|
|			Gandalf to Frodo in "The Fellowship of the Ring"|
+-----------------------------------------------------------------------+

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 89 16:21:54 GMT
From:      ian@lassen.wpd.sgi.com (Ian Clements)
To:        comp.protocols.tcp-ip
Subject:   Re: Thinwire vs. Thickwire (Why 30 nodes only on thin?)

In article <2525@aecom.yu.edu>, glen@aecom.yu.edu (Glen M. Marianko) writes:
> In article <8909291306.AA06775@jvnca.csc.org>, aggarwal@JVNCA.CSC.ORG (Vikas Aggarwal none) writes:
> > 
> > 	Max segment length - 185 meters (30 nodes per segment)
> 
> ...than 30 workstations?    Tell ya, the only place I ever saw this in
> print was in a DEC catalog.  Maybe this is a DEC restriction?

 Sorry, see section 10.7.1 of the IEEE Std. 802.3-1988, page 39.  It says
"A coax segment may contain a maximum of 185 m (600 ft.) of coaxial cable
and a maximum of 30 MAUs."

	Cheers,

	Ian

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 89 16:43:24 GMT
From:      jfitzger%talcott@wellflt.UUCP (Jeffrey J. Fitzgerald)
To:        comp.protocols.tcp-ip
Subject:   Re: Wellfleet, Network Systems Contacts


	Wellfleet Communications Inc.
	12 DeAngelo Drive
	Bedford, Massachusetts 01730-2204
	(617) 275-2400

	Network Systems Corporation
	7600 Boone Avenue North
	Minneapolis, Minesota 55428
	(612) 424-4888

> Can someone help me out? Thanks!

Anytime.

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 89 16:49:44 GMT
From:      jqj@RT-JQJ.STANFORD.EDU (JQ Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re:  Courier (remote procedure calls) by Xerox

Courier is documented in Xerox System Integration Standard XSIS 038112,
December 1981.  Courier: The Remote Procedure Call.  Appendix F, Bulk
Data Transfer, is an October 1982 appendix.  Courier is heavily used as
the standard for most of Xerox's network development on top of XNS transport.
However, the individual uses of Courier are not well documented:  some
RPC sets (e.g. Clearinghouse) are described in their respective XSIS
documents; others (e.g. the virtual terminal access protocol) are not
to my knowledge externally documented.  Xerox originally handcoded all
Courier applications, so there were some ambiguities in the spec and some
variations between documented interfaces and actual use.  I was the author
of one of the first (almost) complete XNS Courier compilers (for 4.3BSD); 
since that time, I believe a number of other Courier compilers have been
developed inside Xerox for various software environments.

By the way, a Courier subset compiler was developed by Eric Cooper and
distributed as part of 4.2BSD.  It used TCP streams as the transport.

Many of Courier's ideas saw a wider audience as they were borrowed by
later RPC languages, e.g. Sun's RPC and ASN.1.

JQ Johnson                              voice: 415-723-3078
Manager, Special Projects               Internet: jqj@jessica.stanford.edu
Networking and Communications Systems
Pine Hall Rm 125-A 
Stanford University
Stanford, CA 94305-4122

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 89 16:53:56 GMT
From:      nagle@well.UUCP (John Nagle)
To:        comp.protocols.tcp-ip
Subject:   Re: ether collision backoff

In article <42686@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
>
>At last week's Interop, I was told that a large workstation company's
>products can be configured to use non-standard retransmission-after-collision
>delays.
>
>Is this true?  Does it cause big problems, as my informant implied?

      The issues here are very subtle.  Hosts that use shortened backoff
delays are engaging in economic warfare with other hosts on the cable for
a bigger share of the network bandwidth.  Attempts to do this on nets with
more than a few hosts may result in congestion collapse, at the link rather
than the datagram layer.

      Packet networks are actually computational ecologies in which the hosts
are competing for resources.  Certain types of competition result in
economic instability.  Ethernet hosts contend for resources, but under a
uniform discipline that makes the contention fair.  By violating the
rules, a host can improve its share of the resource at the expense of
other hosts.  However, in doing so, it increases the number of collisions
on tries ohther than the first.  This reduces the overall capacity of the
cable, because a higher percentage of the bandwidth is lost to collisions.
Thus, the optimial strategy for the host is suboptimal for the network.
Continued pursuit of the optimal strategy for the host results in the 
network operating in a grossly suboptimal way.  In networks, we call this
congestion collapse.  In economics, it's called the "tragedy of the
commons."

      Back in 1984, somebody at Sun turned down the retransmit delay in
4.2BSD's TCP, apparently hoping to "improve performance".  The resulting
mess caused trouble in the Internet for years.  (See my paper in IEEE
Trans. on Communications, April 1987, for details.)  

      Is it Sun again?

      General advice: DON'T DO THIS unless you can establish by both
mathematical calculation and tests on large networks that you are not
introducing instability.  Operationally, the way this class of problem
manifests itself is that everything works fine until a momentary network
overload occurs, and then throughput drops while net traffic remains 
heavy.  After a while, connections fail, network traffic drops, and
things return to normal, leaving users angry and puzzled.

					John Nagle

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 89 17:44:00 GMT
From:      craig@bbn.com (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Counting Internet Hosts (and Users)

I can no longer find the original message, but someone last week asked
how the number of Internet hosts is counted.

The answer is that the NIC periodically runs a program that dumps the
entire domain name system (takes something like 3 days to do it) and
the Internet host count comes from counting the number of hosts in
that dump.  Note this is not a complete listing; some well-known and
large sites refuse to allow transfers of their domain data.  So when
the NIC program locates 118,000 hosts (as it did in July) you can be
sure that is an underestimate.  The guess in July was that the real
count was something over 150,000.

By the way, there is a plan afoot to actually try to estimate the number
of Internet users, by estimating the number of users per host.  The IETF
hopes to have that number by the end of this year...

Craig

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 89 18:09:35 GMT
From:      dyer@spdcc.COM (Steve Dyer)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Any experience using commercial cable TV as a MAN?

Has anyone ever investigated using a couple of channels from a town's
cable TV system as the basis of a metropolitan-area network?  I'm completely
ignorant of the technology and its limitations, but I'd think that something
like this *might* work with broadband modems and the right link-level hardware.
For connection to a regional network also located in the same town
(e.g., NEARnet), it might be preferable to lots of relatively low speed
leased lines.

I'd appreciate hearing from people who know a little bit more about
the issues and whether or not this is completely unrealistic.

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 89 18:21:07 GMT
From:      car@trux.UUCP (Chris Rende)
To:        comp.dcom.lans,comp.protocols.nfs,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.unix.i386,comp.sys.ibm.pc
Subject:   Re: Unix PC networking (SUMMARY of EMail)


Here is the summary of Email received from my two posting about
"Unix PC networking" and "Call for information on PC-NFS".

car.

Here is my original posting:

> We will be implementing a fairly large, multi-server/multi-site network.
> 
> Systems to be networked include PC's (>100) and several unix systems (~6).
> The PC's need access to file servers, 3270 gateways, and direct access
> to other unix systems on the network.
> 
> We want a unix-based network OS and are currently looking at Banyan Vines
> to run on a 386 box or a Banyan server.
 
>From edsews!uunet!hpcndr.cnd.hp.com!jason  Wed Oct  4 08:37:11 1989 remote from rphroy

Are you really stuck on using a network OS, or are you willing to look at
something like LAN Manager on Unix (LM/X)?

LM/X, available from several companies (like HP), lets your file and print
servers live directly on your UNIX hosts. LM/X client software should
include Telnet capability as well, giving you connectivity to the UNIX
systems directly. Also, several UNIX vendors (HP included) provide 3270
gateway software on their UNIX systems; you may need to use some fancy
termulation software on the PC, but it should work.

You might contact your local HP sales critter to see what he or she can put
together for you. You might be surprised as to what the connectivity
picture can look like...

Good luck; please send me your summary of results if you decide not to post
it.
--
This is not an official statement of Hewlett-Packard Corp., and does not 
necessarily reflect the views of HP. It is provided completely without warranty
of any kind. Lawyers take 3d10 damage and roll a saving throw vs. ego attack.

Jason Zions				Hewlett-Packard Corp.
Colorado Networks Division		3404 E. Harmony Road
Mail Stop 102				Ft. Collins, CO  80525-9599
{known_world}!hplabs!hpcndm!jason  or  jason%hpcndm@hplabs.HP.COM

>From cfctech!mailrus!wuarchive!texbell!cs.utexas.edu!uunet.UU.NET!ldc-net!rod  Wed Oct  4 08:37:12 1989 remote from rphroy

I'd take a look at Sun's or FTP Software's PC/NFS packages.  You get the
same DOS file server capability, plus access to all of Unix ( the Banyan
hides anything useful).  You can also use any Unix box which runs NFS as a
server.  I've been using Banyan since 4/89, after using PC/NFS for about
a year, and have nothing good to say about it.

rod

--------------------------------------------------------------------
Rod Merry                          Email: uunet!ldc-net!rod
Lee Data		           Phone: 612-828-0323		

>From edsews!uunet!mimsy!oddjob.uchicago.edu!nucsrl!chinet.uucp!les  Wed Oct  4 08:37:14 1989 remote from rphroy

I'm working with a system of about the same size (10 unix machines - 90 PC's)
running AT&T Starlan and it provides all of the functions you mention.  We
use a PC with a CXI (now owned by Novell) board as a 3270 gateway using
netbios to talk to the other PC's directly, but you could use a board in
a unix machine instead.
There are 1M and 10M versions of Starlan - ours is the 1M and it struggles
with the load during busy parts of the day.  The 10M version should handle
it nicely, and there are bridges availble to connect 10 <-> 1 and routers
for X.25 or fiber links if you exceed the physical size limits of the
twisted-pair or coax connections.

>Any input regarding Token Ring vs. Ethernet would also be appreciated.

The 10M Starlan is basically Ethernet over twisted pair wiring (coax will
work too), but it uses the OSI protocols.  You can get it for AT&T
3B2's & 386 unix as the transport for RFS, uucp and terminal session links
as well as the DOS Server (a seperate piece of unix software).  The PC
client and server software should run on anything that is reasonably
IBM compatible.  There is also a nice mail interface for the PC's called
PMX-Starmail that uses unix mail as the transport.

Les Mikesell
  les@chinet.chi.il.us

>From edsews!uunet!dsinc.dsi.com!wells!mdi386!bruce  Wed Oct  4 08:37:18 1989 remote from rphroy
Please make sure and repost your responses.. I am trying to implement
something somewhat smaller, and would like to see what you are doing..

I am setting up as follows:
1 Arix 875
1 NCR 32/600
2 IBM RT (115 and 135)
12 various PC systems

This is being set up on Ethernet, with PC-NFS and TCP/IP.  I would like
to have used the DOS SERVICES on the IBM, but maybe later.  The users
on the PC's do not generally run applications that share data, so for
that they will log onto one of the various UNIX machines.  However, they
will use Wordprocessing, Spreadsheets, etc. on the PC's.
bruce
---
=========================================================================
	Bruce A. McIntyre, McIntyre Designs, Inc. VOICE(215)322-1895
	143 Bridgetown Pike, Langhorne, Pa. 19047 DATA (215)357-2915
	{wells|lgnp1}!mdi386!bruce		bruce@mdi386 tbit+

>From cfctech!hacgate.scg.hac.com!hacgate.scg.hac.com:ashtate!unisol!haral!elroy!  Thu Oct  5 08:48:22 1989 remote from rphroy

In article <271@trux.UUCP> you write:
>Does anyone have any experience to share regarding Vines or similar products?

I am not using Vines, but I interface with a PC running Vines and all I 
can say is, am I glad that I am not running Vines!

Vines does not seem to talk straight TCP/IP among other Vines machines, and,
the machine that actually has a TCP/IP service loaded on, seems to be loosing
the service fairly frequently, requiring reboots or restarts of the software.

-- 
--Haral Tsitsivas
  UniSolutions Associates
  (213) 542-0068
  ...!uunet!ashtate!unisol!haral
---
--Haral Tsitsivas
  UniSolutions Associates
  (213) 542-0068
  ...!uunet!ashtate!unisol!haral

>From cfctech!mailrus!wuarchive!texbell!cs.utexas.edu!uunet.UU.NET!cucstud!tfd!tons61!harrys  Thu Oct  5 08:48:25 1989 remote from rphroy

Your best bet is to find a *nix system that allows or supports NFS.  If you
wish to network the PC's into it.  Some other TCP/IP products can do this but
I have PC-NFS and NFS from my vendor on my UNIX machine.  It works great!
For the cost, however, you may want to check the public source archive for
the public domain version of TCP/IP and load that on the PC's and save the 
cost of purchasing software (you still need the controler cards).

Lator gator.
-- 
Harry Skelton - Senior Systems Administrator - U.S. Dept. of Transportation
   ..!attctc!tons61!harrys ..!obdient!tons61!harrys ..!tfd!tons61!harrys
[  Views expressed by Harry Skelton are not those of the US Gov. or CBSI  ]

>From edsews!uunet!ukc!vision.uucp!davel  Thu Oct  5 08:48:33 1989 remote from rphroy

This company has commercial product "PC-Connect" and others which integrate
Dos and Unix systems over networks. I can send details if you wish.

--------------------------------------------------------------------------------
 * I I               Dave Lockwood                 These opinions are shareware.
 * II             Technical Consultant             If you like them, send $10...
 * I *   *
 *  **  *          davel@vision.UUCP               VisionWare Ltd,
 * * * *   ...!uunet!mcvax!ukc!vision!davel        Leeds Business Park,
 **  **           +44-532-529292 X2439             Leeds, LS27 0JG,
 *   *                                             United Kingdom
VISIONWARE DOS/UNIX Integration
--------------------------------------------------------------------------------

>From edsews!uunet!fciva!dag  Thu Oct  5 08:48:39 1989 remote from rphroy

We are running a smaller version of something similar here.  We have 3 unix
machines (Prime EXLs, 386 MultiBusII boxes.  These could easily be replaced
with a perhaps twice that number of fast 386 AT machines).  The EXLs are 
running AT&T System V.3.1, TCP/IP over ethernet, and Locus Computing's Merge
386 DOS under unix product.  Each EXL has an average of 16 Wyse 60s which
are used in native mode primarily for DB access, but also can be used for
light DOS word processing and spreadsheet work in PC Scancode mode.  We have
the PC-Enhanced keyboards, so the terminals behave exactly like small PCs.
This allowed us to keep a lid on the number of PCs sitting idle on desks.

We are also running Locus Computing's PC-Interface product on about 20 286
AT class machines.  This provides multiple host file service, printer service,
remote execution, and terminal emulation on the PCs.  The terminal emulation
is inflexable, but that was easily fixed with SuperKey macros.  The file,
printer, and remote execution services are very well implemented from the PC
user's point of view.  I would have liked some better diagnotics in the host
software on the unix machines.  The services use udp/ip over the same thin
ethernet.

One of the EXLs, with associated terminals and PCs is in California (we are
located in Virginia).  Currently we are using uucp over Telebit Trailblazer+s
to move data between sites.  In particular, I wrote an lp interface script that
does:
cat $file | uux -n - "$machine!lp -s -o$option -t$usetitle -n$copies"
so that printers at remote sites are transparently accessable.

I have a similar interface script on the two EXLs here that uses rcp and remsh
to accomplish the same thing over ethernet.  Eventually, I suspect we will set
up a SLIP connection over either T2500s or a leased line for the California
site.  This would allow PCs at one site to log in a disk drive at the remote
site.  It would be slow, but it would work.

All this software, and the hardware except for the PCs and terminals, was
purchased as a package from Prime, but is available separately elsewhere.  The
first generation was buggy, but the current software releases are quite good,
and single sourcing has support advantages.  I've been quite pleased with what
we've accomplished, my management is mostly pleased, and a colleage who is an
ex IBM-mainframer is amazed at the cost/performance ratio we've achieved, even
with paying double high prices to Prime for the hardware.

This is probably more information than you expected.  Let me know if you have
any questions.

Dan
---
Daniel A. Graifer			Franklin Capital Investments
uunet!fciva!dag				7900 Westpark Drive, Suite A130
(703)821-3244				McLean, VA  22102

>From edsews!sun!sunburn.West.Sun.COM!mcdphx!zztop!xroads!ronnie  Fri Oct  6 08:54:05 1989 remote from rphroy

I am sysadmin at IDEA Courier in Tempe, Arizona and we currently
have 120 pc's (of varying types) with Sun's pcnfs and using
Sun 3/260's and Sun 3/280's as servers.  We also hook the pc's
up via coax to a patch panel with direct access to our 3270
mainframe.  The pc's have a 3270 emulator and users can switch
between using pc-dos, telnet, 3270 and ftp/nfs.

If you need more detail on our current set-up, just let me
know, but the Sun's used as servers seem to provide out needs
adequately and without much problem. (the biggest problem is
notifying the pc's when the Sun is going down for maintenance
or sending mail to user's on the pc's and having them KNOW they
have mail.  We have Lifeline mail but it doesn't tell the pc
user when he has mail if he is doing another application.  I guess
the biggest problem is that the pc's are not multitasking.....

Ronnie

---
\  /  C r o s s r o a d s  C o m m u n i c a t i o n s
 /\   (602) 941-2005 300|1200 Baud 24 hrs/day
/  \  hplabs!hp-sdd!crash!xroads!ronnie

>From edsews!mailrus!uflorida!novavax!branch!branch.FIDONET.ORG!wcr  Fri Oct  6 16:46:33 1989 remote from rphroy

I work for Winn Dixie Stores in Florida.  We are using an NCR Tower 650  
running Unix System 5 with our PC on a Token Ring netowrk.  We also have a  
3174 controller (local) on the ring for use with the emulator.  For the most  
part, everything runs fine on the netowrk, the tower is a file/print server.   
And the pc's, mostly PS2/ mod 25's are work stations.  We even have a cron  
backup the user files at 2 a.m.  IBM's 3270 emulator is designed to work on a  
token ring, and a station is needed for Gateway functions.  The Tower runs  
TFS Consumer (I beleive..) and the PC's are running PCLAN.

Unfortunately, I don't have any expirence with Vines or eithernet.

Sorry I couldn't have been more help.
  
Bill
 
--------------------------------------------------------------------+
"Out on a Limb in The Branch Office...."                            ]
                                                                    ]
Fidonet : 1:369/11  The Branch Office.   (branch.FIDONET.ORG)       ]
          1:369/0   Treasure Coast Net.                             ]
UUCP    : {sun!hoptoad, attctc, <internet>!mthvax}!ankh,            ]
                                gatech!uflorida!novavax!branch!wcr  ]
                                                                    ]
INTERNET: wcr@branch.FIDONET.ORG -or- wcr@f11.n369.z1.FIDONET.ORG   ]
BBS     : +1 305 979-2073                                           ]
                                   'I was asking for it.....'       ]
--------------------------------------------------------------------+

>From edsews!mailrus!gatech!harvard!spdcc!esegue!johnl  Sat Oct  7 10:43:55 1989 remote from rphroy

Remote files, rlogin, rsh, rcp, printing, telnet, ftp.  Backup and email
available at extra cost.  You want gateways, telnet or rlogin to some other
machine.  It understands ARP and packet forwarding so you are a real member
of your TCP network, even if it is as large as the Internet.

There is a developer's kit available at extra cost that lets you implement
network applications of your own.

>Can the PC component of PC-NFS run on XT's?
Yes.

>How much memory does the PC component of PC-NFS use?
Too much, nearly 100K, but I don't think you'll find anything else as
functional that takes much less.

>How does the performance of PC-NFS compare with other PC servers?
It feels pretty respectable.  I haven't benchmarked it, though others
certainly have.

>How does PC-NFS interact with the host Unix machine?
It looks just like any other NFS client.  At a place where I consult, we
have a network of about 25 Suns and 386/ix machines running NFS, and several
PCs that mount filesystems from any and all of the other hosts.

There is a special daemon for PC-NFS that provides login validation and
printer service.  But you only need to run one copy per ether, not a copy per
machine.

PC NFS is also supposed to work via SLIP over serial links, but I've never
tried it.  I suspect that zmodem would be a lot faster.

FTP Software in Wakefield MA also has a PC version of NFS which supports a
wider variety of PC hardware.  Since FTP's primary line of business is
TCP/IP for PCs, while PC NFS is definitely a sideline for Sun, I'd strongly
consider FTP.

>From edsews!uunet!ukc!ibmpcug.co.uk!dwight  Sat Oct  7 10:43:58 1989 remote from rphroy

At The Independent (a daily national newspaper in the UK), we are using
Sun's PC-NFS to link about 100 PCs with nine Sun servers running SunOS
(Unix). We love it, although there are some problems. I can't think of
anything better for this particular kind of need.

I am writing a paper on the subject for the Sun UK Unix Users Group.
If you're interested in getting the paper, or in more information,
let me know.

Questions like yours about the differences between Ethernet and Token
Ring are best answered elsewhere, like in the various trade journals.
We run Ethernet. It's fine.

--Dwight Ernest
  (Best to reply to dwight%independent.uucp@ukc.ac.uk)

>From edsews!ames!pacbell!dumbcat!marc  Mon Oct  9 09:27:12 1989 remote from rphroy

In article <274@trux.UUCP> you write:
    In general, what services does PC-NFS provide for the PC user?
    (I.e., file sharing, printer services, EMail, modems, rlogin, gateways,...)

PC-NFS allows you to define virtual disk drives with the actual disk drive
existion upon the NFS server.  The package also comes with FTP, Telnet (with
a brain damaged VT100 implementation), rcp, and some other unix like
utilities tailored toward dos.  Printers on the server can also be used,
however several NFS versions were buggy in that you could only spool to a
printer using the ``net print'' command -- you could not have a program talk
to the printer directly.
    
    Can the PC component of PC-NFS run on XT's?

Yes.
    
    How much memory does the PC component of PC-NFS use?

With PC-NFS drivers loaded it takes up aout 80K.  That jumps to over 100 (I
for get ho buch over a hundred) when the print spooler is enabled.
    
    How does the performance of PC-NFS compare with other PC servers?
    
PC-NFS is client only.  The assumption is that you have a Server box
somewhere on your network.  With a Vax 780 running VMS and Wollengongs NFS
implementation the disk access is about the same as a slow floppie.  Using a
Sun-3/280 as the server makes disk access a little bit slower than the local
hard disk.  It's fast enough to use when you must have shared files.

    How does PC-NFS interact with the host Unix machine?
    
It's just another NFS client.  It can access any exported filesystem from
any NFS server.  It can use Yellow pages.  There is an authentication daemon
that comes with PC-NFS (in source form) that you must put on one of your
hosts.  Putting the daemon on the YP master seems to be the best way.

Hope this helps.

--marc
// Marco S. Hyman		{ames,pyramid,sun}!pacbell!dumbcat!marc
-- 
Christopher A. Rende           Central Cartage (Nixdorf/Pyramid/SysV/BSD4.3)
uunet!edsews!rphroy!trux!car   Multics,DTSS,Unix,Shortwave,Scanners,StarTrek
 trux!car@uunet.uu.net         Minix,PC/XT,Mac+,TRS-80 Model I: Buy Sell Trade
       "I don't ever remember forgetting anything." - Chris Rende

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 89 19:29:39 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for MPUT and MGET in FTP . . .



	      Points to know about FTP history:

		1) 3-cornered FTP (source, destination, and control points on 
		   different hosts) never worked.

John,

Huh??  The UCLA MVS TCP/IP package ("ACP"), like its predecessor NCP
FTP package, used "3-cornered" FTP successfully, starting in 1974.  It
still does.  ISI recently wrote the BFTP program (see RFC-1068) to
perform background file transfers using "3-cornered FTP"; it has been
successful, and has been quite widely distributed.   Where did this
"never" come from?   

Bob Braden

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 89 19:53:57 GMT
From:      loverso@Xylogics.COM (John Robert LoVerso)
To:        comp.protocols.tcp-ip
Subject:   Re: rwhod protocol and >42 users

In article <1178@celit.fps.com> dave@fps.com (Dave Smith) writes:
> Has there been any thought given to extending the rwhod protocol so that
> more than 42 (1024/sizeof whoent (==24)) users on a system will be reported 
> correctly?  This limit is entirely too small for today's systems.

Yes.  I played with this at Encore.  I did two approaches.  The
first one, based on a hack we had at SUNY/Buffalo, added a new
rwhod packet type that was just a continuation of the previous
information.  This allowed `n' packets; a modified rwhod would just
issue as many packets as needed.  Modified rwhod's would collect
these packets and concatinate them to the spool/rwho file.  Unmodified
rwhod's would just ignore the new packet types (except on certain
SystemV machines, where it would print stupid, obnoxious messages
on the console about `unknown type', sigh).  This worked.

The second approach just up'd the sendspace for udp packets to 8K;
this works with no protocol modification.  With this, fragmentation
happens automatically over networks with an MTU less than the packet
size.  However, several bugs in 4.2BSD prevents this from working.
4.3 is no problem.

With either approach, rwho/ruptime needed to be modified so that
they read more than 41 whoents from the spool/rwho file (i.e., just
read all of the file).

However, this is all BAD.  Either approach causes rwhod to send
out multiple broadcast packets.  On a relatively fast machine,
allowing IP to do the fragmentation, the broadcasts will hit the
net almost back-to-back.  This can cause many more problems then
benefits.  Many people will tell you that rwhod is ugly enough as
it is, just producing one broadcast packet every 1 [4.2] or 3 [4.3]
minutes.

If you are really hot on producing a new protocol, how about this.
Simple observation shows that most of the information rwhod gives
out doesn't change all that much.  So, perhaps a more reasonable
approach, would be to use a delta protocol, where any given packet
would include some new whoents and a few bits to delete old whoents.
Thus, over a period of time (10 minutes?), a rwhod-listener might
pick up a complete list of users.

Finally, you can just chuck rwhod and use Sun's "rusers/rup" instead.
It works, albeit not very well.

John
-- 
John Robert LoVerso			Xylogics, Inc.  617/272-8140
loverso@Xylogics.COM			Annex Terminal Server Development Group

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 1989 00:01-EDT
From:      CERF@A.ISI.EDU
To:        gamiddleton@WATMATH.WATERLOO.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Comment on RFC1124 (?)
Guy,

check with Craig Partridge at BBN (Craig@nnsc.nsf.net)
concerning host count. I think I got this data from Tracey LaQuey
at University of Texas. 

Vint
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 89 20:01:12 GMT
From:      nagle@well.UUCP (John Nagle)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for MPUT and MGET in FTP . . .


      I'm sorry, I had no idea that UCLA MVS was capable of that.
The systems decended from either BBN or Berkeley code generally didn't
have that capability, and the original FTP spec was rather hazy about
how it was supposed to work.

      But it's nice that it's starting to work now.

					John Nagle

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 89 20:03:45 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for MPUT and MGET in FTP . . .



	1) 3-cornered FTP (source, destination, and control points on 
	   different hosts) never worked.

The above claim notwithstanding, however, see RFC 1068 on BFTP.

--jon.

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      9 Oct 89 21:55:22 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   experience using commercial cable TV as a MAN.


 dyer@ursa-major.spdcc.COM (Steve Dyer) writes:
>Has anyone ever investigated using a couple of channels from a town's
>cable TV system as the basis of a metropolitan-area network? 

	look no further, Steve!  the cities of Springfield, Mass and
	St. Paul, Minnesota have linked their respective ethernets
	over their local cable systems -- the result for each is a 
	full speed ethernet that spans many buildings, many miles apart.  

	a large company local to the Boston area is also looking
	into linking their building ethernets this way.

>like this *might* work with broadband modems and the right link-level hardware.
>For connection to a regional network also located in the same town
>(e.g., NEARnet), it might be preferable to lots of relatively low speed
>leased lines.

	indeed.  we at Chipcom are exploring the possibilities of attaching
	to NEARnet via broadband cable technology (yes, folks: 802.4!).
	our Marathon bridge is a very zippy .3 to .4 learning bridge.
	i'd call it a transparent bridge, but after BOFing at Interop,
	let's just call it a translucent bridge.  the bridge runs at
	nearly 9000 packets per second at short distance, and drops
	to about 4000 pps at ten miles....  naturally, latency increases
	with long distance as well.  (you knew that!)

	naturally, there are some gotchas with this technology.  the local
	cable system has to be fairly high quality stuff.  some cable 
	companies are fairly lax about attenuations and other nifty RF stuff;
	such conditions would cause many physical layer 802.4 errors.

>I'd appreciate hearing from people who know a little bit more about
>the issues and whether or not this is completely unrealistic.

	it's being done already.  the major reason Chipcom has not hooked
	to internet or NEARnet via broadband is that we will be moving
	to Southboro next year...

	(by the way, i work for Chipcom and worked on the Marathon bridge
	 software and systems for most of the last 18 months.  ok?)

-- 
 ... Steve Elias (eli@spdcc.com);6178906844;6179325598; {}
/* free email to fax gateway for destinations in metro Boston area. */
/* send email and the destination fax number... */

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 00:57:35 GMT
From:      sra@lcs.mit.edu (Rob Austein)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for MPUT and MGET in FTP . . .


   Date: 8 Oct 89 19:16:41 GMT
   From: nagle@well.UUCP (John Nagle)

   ... 3-cornered FTP (source, destination, and control points on
   different hosts) never worked.

What about BFTP (RFC-1068)?  I don't know how widely used it is, but
it certainly works.

--Rob Austein, MIT

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 02:16:12 GMT
From:      loverso@Xylogics.COM (John Robert LoVerso)
To:        comp.protocols.tcp-ip
Subject:   Re: rwhod protocol and >42 users

In article <7370@xenna.Xylogics.COM>, I write:
% ...fragmentation happens automatically over networks with an MTU less
% than the packet size.  However, several bugs in 4.2BSD prevents[sic] this
% from working.  4.3 is no problem.

This is incorrect.  4.2, 4.3, and 4.3-tahoe all refuse to fragment a broadcast
packet.  Needless to say, I was playing with a modified kernel (i.e., fire).

John
(thanks to those who pointed this out)

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 1989 06:59-EDT
From:      CERF@A.ISI.EDU
To:        phri!roy@RUTGERS.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: RFC for MPUT and MGET in FTP . . .
The 3-way FTP was used for various kinds of RJE management
(remote job entry) in the early days of ARPANET when we
still had a fair amount of batch processing going on.
Remember, this was in the early 1970's. The access control
complications in today's networking environment make this
more complicated, but having a program on one machine manage
the activities of programs on other machines seems useful
even today (and not merely in the RJE context). One might choose
other tools than 3-point FTP (i.e. more modern ones), of course.

Vint Cerf
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 04:01:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

Guy,

check with Craig Partridge at BBN (Craig@nnsc.nsf.net)
concerning host count. I think I got this data from Tracey LaQuey
at University of Texas. 

Vint

-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 04:36:01 GMT
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   RFC for MPUT and MGET in FTP . . .

I knew people who used third party FTP in order to transfer files to
their Imagen printers. The Imagen's would allow you to just open a TCP
connection to a certain point and blat a file over the connection,
which they would then print.
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
"Live the life you love, Use a god you trust,
 and don't take it all too seriously." - Love & Rockets

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 06:05:40 GMT
From:      louie@SAYSHELL.UMD.EDU ("Louis A. Mamakos")
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?) / OSI Transition

Geez.  What a fuss.

Do you all have a serious interest in the particular RFC's that were
published in PostScript, or is this just another opportunity to flame?
Have you tried to USE these RFCs and found them deficient?

A measure of success for an RFC is if it meets the needs of the audience 
it was written for.  I can't speak to RFC 1124, but have quite intimate
experince with the NTP spec; or rather with its many, many draft versions.

I'd like to speak to the utility of RFC1119, on the Network Time
Protocol.  The development of the NTP RFC took quite a long time.  I
wrote an implementation of NTP based on many of the draft NTP protocol
specificiations.  The idea was to find out if the protocol described
by the document actually matched and could interoperate with the
version that Mills, the author, developed.  Also during this process
the protocol was changed and improved due to the testing that was
performed.

During this entire process I read literally 20 different versions of
this specification.  They were all in the form of a PostScript
document.  A number of other folks on the NTP mailing list also read
this document and submitted suggestions to Mills relating to the
content and typographical appearence of the document.  I can't recall
a single occasion when someone complained that the document was only
available in PostScript form.

My point is that the *content* of the RFC was what this group of folks
were interested in, and not the form.  It really didn't impact *my*
use of the spec.  Yes, it's a little more difficult to print the
thing, but having the spec published in PostScript enhances the
understanding of the material.

The result of this experience is that, yes, the spec does describe the
protocol in sufficient detail that at least two different
implementations of NTP were built from the document.  The talk to each
other as well as the implemention built by the author of the protocol.
I think that's a wonderful thing from the point of view of a protocol
implementor.

I suppose that some folks don't have a PostScript printer available to 
print these documents; the quick answer is that paper versions are available
from the NIC.  I think PostScript capable printers are becoming very
popular and affordable these days.  It is true that you can't grep the
text of the document.  But, IMO the added readability of the PostScript
form outweighs the utility to grep it.

This is my perspective as a serious user of RFC 1119.  Before you
condemn the form, print the document and ask yourself if it would be
as easy to understand if it was a "dumb" ASCII text document?

louie

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 08:57:47 GMT
From:      ug051@crayamid.cray.com (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   Re:  ether collision backoff

comment: ethernet retransmission upon collision is way down below IP
and on the tcp/ip level you should not bother.

the "standard" retransmission serves to scatter the retransmission events
in time space since a collision is detected always on all neighbouring
hosts on an ethernet trunc . 
It is in fact that the electrical messages spreading out on the ethernet 
trunc overlap (at least partially) and scramble. By the way the detection is
done purely on hardware level: when two signals arrive the energy on the
cable is higher and this leads to collision detect going off.

When all people use the same algorithm of retransmitting timing, which
contains a statistical element (random number dependent) that is
different for all hosts (the point is different for all hosts) you have a
pretty good guaranty that they will not (yes, NOT) retransmit at the same
time. When you start using different algorithms, there might be accidental
"resonances" between the different algorithms, causing perhaps during 
some instatnces of retransmittals two hosts to retransmit in a time interval
than might lead to new collisions.
Even if the new algorithm seems "better", in a fairly local region (about the length
of an ethernet packet or between bridges) all hosts should use about the same
algorithm to avoid accidental synchronous retransmissions.

Even in an environment where collisions are frequent, I would not change the
retransmission algorithms but scope the line to see who spoils it.

michael

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Oct 89 09:08:39 SET
From:      KA%ESOC.BITNET@CUNYVM.CUNY.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   RPC and DNS

     TCP/IP RPC and DNS
     -------------------


     Does anybody know of a VAX/VMS based implementation of RPC
(particularly the Port Mapper) and Domain Name Server/Resolver.

     We have DEC's ULTRIX Connection, but for the time being, they
do not support these features. We would only be interested in a
software solution over standard DEC interfaces to Ethernet.

     Jenny Franks,
     ESOC,
     Robert Bosch Strasse 5,
     6100 Darmstadt,
     West Germany

     KA@ESOC / KA@DDAESA10
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 10:59:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for MPUT and MGET in FTP . . .

The 3-way FTP was used for various kinds of RJE management
(remote job entry) in the early days of ARPANET when we
still had a fair amount of batch processing going on.
Remember, this was in the early 1970's. The access control
complications in today's networking environment make this
more complicated, but having a program on one machine manage
the activities of programs on other machines seems useful
even today (and not merely in the RJE context). One might choose
other tools than 3-point FTP (i.e. more modern ones), of course.

Vint Cerf

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Oct 89 16:45:22 EDT
From:      "Gary S. Miliefsky" <GMILIEFS@mitvma.mit.edu>
To:        tcp-ip@sri-nic.arpa
Subject:   Multihoming

Is it valid for a multi-homed host to have a unique name for each ip
address, or is it required/implied that a multi-homed host have a single
node name and more than one ip address?
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 13:03:19 GMT
From:      mep@AQUA.WHOI.EDU (Michael E. Pare)
To:        comp.protocols.tcp-ip
Subject:   Re:  Any experience using commercial cable TV as a MAN?

Most cable TV companies use a sub-split format with reverse (toward the
headend) frequencies only ranging from 5-30MHz and the forward (away from
headend) strating at 54MHz to top end (300, 400, 450 etc.).  This severly
limits the useable bandwidth for data since the reverse direction is so
limited.

Most broadband equipment utilizes IEEE standard frequencies which start
above the 54MHz level for the reverse direction.  They are designed for
mid-split systems which most private CATV plants are (universities etc.).

Even if you limited the channeling to 6MHz in each direction (limited
daat bandwidth) everyone on the system would have to use 'like' equipment
in order to talk on the system.  You'd probably have to have the CATV
company coordinate the efforts.  This assumes you can find the hardware
and would it be worth it for a 6MHz bandwidth?!  Also, in many metro
areas there is usually more than one CATV company which certainly
breaks up the network within the metro area.  These companies have no
intentions of linking together.

But this is just my limited thoughts on using CATV as a MAN.

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 13:03:55 GMT
From:      boomer@athena.mit.edu (Don Alvarez)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: experience using commercial cable TV as a MAN.

In article <164@ursa-major.SPDCC.COM> eli@ursa-major.spdcc.COM
(Steve Elias) writes: dyer@ursa-major.spdcc.COM (Steve Dyer) writes:
>>[anybody every run ethernet over local cable-tv through a city?]
>[yes, Springfield, mass and St. Paul, Minnesota have]
>
>	naturally, there are some gotchas with this technology.  the local
>	cable system has to be fairly high quality stuff.  some cable 
>	companies are fairly lax about attenuations and other nifty RF stuff;
>	such conditions would cause many physical layer 802.4 errors.
>
how about the problem of having every character you type sent
ito the home of every phreak and hacker in a 100 square mile area?

-don
boomer@athena.Princeton.edu
--
+ -------------------------------------------------------------------------- +
|  Don Alvarez           M.I.T. Center For Space Research    (617) 253-7457  |
|  boomer@SPACE.MIT.EDU  Moving Soon: Princeton University Gravity Lab 8/89  |
+ -------------------------------------------------------------------------- +

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 13:06:49 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  RFC for MPUT and MGET in FTP . . .

John,

Harrumpth. Fuzzballs do it, too; even RFC-1068. Why, we use it at least
once per year.

Dave

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Oct 89 20:22:06 -0400
From:      Buz Owen <ado@BBN.COM>
To:        "Gary S. Miliefsky" <GMILIEFS@mitvma.mit.edu>
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: RFC for MPUT and MGET in FTP . . .
MGET and MPUT aren't explicitly specified in the FTP protocol spec (RFC 959)
because these commands a matter "local" to the user ftp program -- only the
language used between the FTP server program and the FTP user program is
standardized by the protocol spec.  Here are some hints though:

For MPUT, the user FTP program should accept an argument which designates a
group of local files to be sent -- a directory or subdirectlry name or file
group specifier, expressed according to the host's local convention, and
execute "STOR" commands for each of the files indicated.  If the local system
contained system calls or subroutines for interpreting file group specifiers,
these facilities should be used to give standard local semantics to the
argument.

For MGET, the user program should accept a string argument (with no local
interpretation), submit an NLST command with this string as its argument to the
server to obtain a list of files on the server which match the argument, and
then execute one RETR command for each filename in the list received from the
server, retrieving each of the files in turn.  A point to watch out for here is
that (a naive implementation of) the FTP server might only respond to NLST with
whole directory or subdirectory listings -- i.e. fail to implement its own
local group name convention, or the server's operating system might not have a
file group naming convention.  In any case, it is the user's responsibility to
know the remote syntax for designating a group of files, not the ftp user
program's responsibility.

MGET and MPUT will work better if the user FTP program is prepared to create
local directories implicitly when doing MGET, and to execute MKD, CWD and CDUP
commands when doing MPUT to transfer a file hierarchy, since there is no
guarantee that a server will create necessary (sub) directories when given a
filename containing directory components in a STOR command.

When transferring to or from a system with differing filename syntax, the user
FTP program might also (attempt to) give help in adjusting or translating
filenames, although this can't be done in a fully general way.  The original
implementation of MGET and MPUT at BBN contained heuristics to translate
between unix file name syntax and Tenex/TOPS20 or Multics file name syntax.
This involved optional stripping of trailing version numbers, case translation,
delimiter translations, (e.g. ">" to "/" for Multics), and removal of the
directory component, under control of various flags.

The discussion in RFC 959 under the NLST, MKD, PWD, and CDUP commands may be of
some help here.  The advice in in RFC 1123 under the same topics and also under
"user interface" is also relevant.

With apologies for possibly belaboring the obvious, hope this helps.

Buz
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 13:54:02 GMT
From:      craig@bbn.com (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Datamation Hall of Fame

People might be interested in the September 15th issue of Datamation, p. 29.
I discovered this morning that Vint Cerf is this year's inductee into the
Datamation Hall of Fame.  And he's in pretty prestigious company (the
roster of past awardees includes Howard Aiken, Seymour Cray, John Backus,
Don Knuth, John McCarthy, Ritchie and Thompson, Turing and Von Neumann....)

Craig

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 13:54:15 GMT
From:      KA@ESOC.BITNET
To:        comp.protocols.tcp-ip
Subject:   RPC and DNS


     TCP/IP RPC and DNS
     -------------------


     Does anybody know of a VAX/VMS based implementation of RPC
(particularly the Port Mapper) and Domain Name Server/Resolver.

     We have DEC's ULTRIX Connection, but for the time being, they
do not support these features. We would only be interested in a
software solution over standard DEC interfaces to Ethernet.

     Jenny Franks,
     ESOC,
     Robert Bosch Strasse 5,
     6100 Darmstadt,
     West Germany

     KA@ESOC / KA@DDAESA10

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 14:51:24 GMT
From:      kasten@interlan.interlan.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re:  Counting Internet Hosts (and Users)

Gee, 

Seems like there is a simpler way to do it......

    for (i=0; i<0xffffffff; i++)
         foo = ping(i)
        if (foo == answered)
           number_of_hosts++;

Its only an order n problem . . . no fancy protocols, no worrying about
whether you are allowed to dump the domain tables, etc, etc...

It may take a while to finish, but that would provide a good excuse for 
people to buy more/faster/bigger/<your favorite adjective here> machines.

Linearly and Inefficiently Yours...
Frank Kastenholz
Racal InterLan

(p.s. for those people who tend to believe everything they read - don't)

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Tue, 10 Oct 89 22:03:39 PDT
From:      Greg Satz <satz@cisco.com>
To:        AFDDN.TCP-IP@GUNTER-ADAM.AF.MIL
Cc:        tcp-ip@NIC.DDN.MIL, customer-service@cisco.com
Subject:   Re: cisco question
>>   Now for the meat of the question.  Let's suppose that I have my own packet
>> switch with 20 ports on it.  I have a cisco MGS or AGS gateway and I connect
>> my packet switch to the Milnet via the gateway.  I get the NIC to assign me
>> a class B net number such as 131.7.0.0.  I could then assign each of my 20
>> ports to have a different number in the forth octet, so I would have 
>> something like 131.7.x.1 thru 131.7.x.20.  I could also decide to connect
>> lans to my packet switch and subnet my class B addresses.  For instance, I
>> could let 131.7.1.x be a subnet that includes the cisco and each of the ports
>> which would give me 131.7.1.1 thru 131.7.1.254, of which I only need 20 
>> because I only have 20 ports.  Now, if I decide to connect a gateway from a
>> lan to my packet swicth on port 5, its address in subnet 131.7.1 would be 
>> 131.7.1.5.  I could let the lan be subnet 131.7.32.x thru 131.7.255.x.  I
>> assume I could break the third octet on any convenient boundary. 

Is the following picture equivalent to the above words?

    ---26---ciscoM---131.7.1.1---[switch]---131.7.1.5---ciscoL---131.7.x.y
      X.25             X.25                   X.25                LAN

>>   now my problem is how to tell the cisco how to route to the gateway to
>> the lan based on the subnet field being in a range.  Any one see how this
>> would be done??  The second part of the question (assuming it can be done),
>> is whether the cisco will only open one vc to the lan gateway or 
>> whether it will try to open a vc for each unique IP destination address on 
>> the lan??

The way to make this work is to inform the routers of each other's
presence. This can be done using static routing or with a dynamic routing
protocol such as IGRP. The cisco connected to Milnet, ciscoM, must know
that everything on 131.7.0.0 is reachable out its X.25 interface connected
to your 20 port switch. The cisco connected to the LAN, ciscoL, must know
that the rest of the world is accessible via its X.25 interface.

Whether you use static or dynamic routing, the routing database will
contain the next hop address which will either be 131.7.1.1 for ciscoL or
131.7.1.5 for ciscoM. As these two routers get involved in all traffic
between them, a minimum of one VC is used. More can be permitted using the
X.25 NVC parameter.

For example, if ciscoM needed to send something to 131.7.32.1, it would
find that 131.7.5.1 was the next hop address. Furthermore if ciscoL needed
to send something to 10.2.0.2, it would find the next hop to network 10 is
131.7.1.1. In both these cases, your excellent description holds.

For more configuration details, please send mail to
customer-service@cisco.com.

Greg Satz
cisco
-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 16:36:15 GMT
From:      hwb@MERIT.EDU (Hans-Werner Braun)
To:        comp.protocols.tcp-ip
Subject:   syslog to 127.0.0.1.

Hi:

For quite some time already we are seeing syslog messages logged from
a variety of machines on the NSFNET backbone nodes. All the originating
machines appear to have the same operating system. Turns out that they send 
the syslog messages to 127.0.0.1, and the campus and regional networks
then forward it to the NSFNET backbone. Could people please verify
whether their loopback interface is configured right? I personally,
for example, would not want all my mail exchanges etc. logged at
far away places without explicitly configuring it that way...
It may also be of interest to have regional and campus networks filter out 
packets to 127.0.0.1.

	-- Hans-Werner

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 17:35:19 GMT
From:      dglo@zodiac.ADS.COM (Dave Glowacki)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: experience using commercial cable TV as a MAN.

In article <164@ursa-major.SPDCC.COM> eli@ursa-major.spdcc.COM (Steve Elias) writes:
> dyer@ursa-major.spdcc.COM (Steve Dyer) writes:
>>Has anyone ever investigated using a couple of channels from a town's
>>cable TV system as the basis of a metropolitan-area network? 
>
>	look no further, Steve!  the cities of Springfield, Mass and
>	St. Paul, Minnesota have linked their respective ethernets
>	over their local cable systems -- the result for each is a 
>	full speed ethernet that spans many buildings, many miles apart.

St. Paul's broadband link is half-speed, but full speed links are doable
(if you can get 'em past the politicians :-)  Unfortunately, this link
is only used as a glorified Appletalk network link (or was when I left the
city 8 months ago.)  In its infinite wisdom, the rest of the city is
"networked" up over another chunk of broadband via a bunch of glorified
terminal servers.

>>like this *might* work with broadband modems and the right link-level hardware.
>	naturally, there are some gotchas with this technology.  the local
>	cable system has to be fairly high quality stuff.  some cable 
>	companies are fairly lax about attenuations and other nifty RF stuff;
>	such conditions would cause many physical layer 802.4 errors.

The BIGGEST gotcha when I worked at St. Paul was the problems caused by
the cable company searching for cable pirates.  The network would go
down without warning about once a month because of that.

>>I'd appreciate hearing from people who know a little bit more about
>>the issues and whether or not this is completely unrealistic.

Send mail to pwcs.StPaul.GOV and they can probably answer some of your
questions or give you pointers to the right people.
-- 
Dave Glowacki          dglo@ads.com          Advanced Decision Systems

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 17:37:56 GMT
From:      wunder@SDE.HP.COM (Walter Underwood)
To:        comp.protocols.tcp-ip
Subject:   Re: PostScript Versus ASCII

Well, I've been staying out of this, partly because HP is a major
vendor of non-PostScript (TM) printers, but ...

At least two of our top networking engineers are visually impaired.
One is blind, and another uses very large print on the screen.  An
ASCII document can displayed at any size on a screen, or displayed
on a volatile Braille display, or even printed in Braille.  PostScript
can't.

We can handle PostScript diagrams, but PostScript text (i.e.,
paper-only text) is not for everybody.  I'd appreciate it if y'all
keep an ASCII copy of TCP/IP documents available.

wunder

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 18:14:33 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: Any experience using commercial cable TV as a MAN?

In article <160@ursa-major.SPDCC.COM> 
dyer@ursa-major.spdcc.COM (Steve Dyer) writes:
>Has anyone ever investigated using a couple of channels from a town's
>cable TV system as the basis of a metropolitan-area network?  [...]
 
>For connection to a regional network also located in the same town
>(e.g., NEARnet), it might be preferable to lots of relatively low speed
>leased lines.
>

	Broadband LAN technology was designed to exploit cable TV
technology for building high speed LANs over a much larger area than
an Ethernet.  The desire was to exploit a high speed medium and
achieve economies of scale by reusing an existing technology.  I don't
know whether there was a thought of actually having broadband LAN
technology and cable TV co-exist on the same cable system, but it is
technologically feasible to do so.

	Now for the gotchas:

	1) Cable TV cable plants are not necessarily designed to
support two-way high quality communication as required by a LAN (MAN).
What the viewer sees as degraded, but watchable, television translates
into useless bandwidth for data.  The cable TV operator must support
the cable plant to meet data requirements.  If you call him and say
that the system isn't working, he might respond that all the TV
signals look fine, so the trouble must be in your equipment.  I know
of one campus where the data guys try to run a LAN channel pair on a
system operated by TV people, and they are unable to convince the TV
people that there are serious signal problems.  So much for exploiting
existing technology.

	2)  The IEEE 3 channel broadband repeater technology is too
restrictive for use in a MAN scale network.  It takes too many
channels and does not have the necessary diameter.  You must use a
*proprietary* vendor technology to build a MAN sized network.
Something like the Ungermann-Bass Buffered Repeater or one of the
Applitek devices would work.  To my knowledge, there are no standard
interoperable broadband technologies except for the unacceptable IEEE
standard.

	3) You want the same channels for data that the cable TV
operator wants for TV.  He will not give you channel 2 for data; you
must go somewhere out on the fringes to find some channels.  Applitek
is the only vendor that I know that understands this situation.  Most
of the others use standard TV channels, the same ones defined by the
IEEE.

	So, if you can convince Cablevision to support data, and they
hire techs who know how to maintain broadband to data standards and
they don't charge more than the phone company would, then maybe you've
got something.  I have heard that some companies have made private
arrangements with local cable operators to use channels for data, but
I don't know what arrangements they have made for service.

	I understand Manhattan Cable offers broadband LAN service to
customers in Manhattan, NY, so it can be done.

	Specifically speaking of NEARnet, the NEARnet people would
have to deal with no less than three major cable operators to create a
MAN within route 128.  The size of the market is nebulous and issues
of maintenance and such would be quite difficult to resolve; in my
opinion, not worth the trouble.  NEARnet handles low-recurring cost,
high bandwidth MAN services using Ethernet-on-microwave, not cable TV.
Sorry.  There does not seem to be a high bandwidth, low capital, low
recurring network to suit your needs.  (But then, doesn't everyone
want lots of bandwidth cheap?)

	Why the cable industry failed to understand and exploit
anything other than entertainment TV escapes me.  Why has it taken the
phone company so long to understand LAN technology?  These paradigm
shifts take time, I guess.

	--Kent England, Boston University (and NEARnet)

	Disclaimer:  These views are not official views of Boston
University or NEARnet; they simply reflect the idiosyncratic and
distorted view of the speaker and are due entirely to spending too
much time in the networking business.

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 18:54:07 GMT
From:      karl@asylum.SF.CA.US (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?) / OSI Transition

In article <8910100305.AA19076@sayshell.umd.edu> louie@SAYSHELL.UMD.EDU ("Louis A. Mamakos") writes:
>Do you all have a serious interest in the particular RFC's that were
>published in PostScript, or is this just another opportunity to flame?
>Have you tried to USE these RFCs and found them deficient?

As the author of the original message in this discussion, I find your
comment personally offensive.  Are you really asserting that I took
the trouble to obtain RFC1124 just because I wanted to flame on its
form, not its content?  If so, you are badly mistaken.

In any event, this discussion has gone on long enough and I believe
the concensus is that postscript as the sole representation is not a
good idea.

				--karl--

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 20:45:22 GMT
From:      GMILIEFS@MITVMA.MIT.EDU ("Gary S. Miliefsky")
To:        comp.protocols.tcp-ip
Subject:   Multihoming


Is it valid for a multi-homed host to have a unique name for each ip
address, or is it required/implied that a multi-homed host have a single
node name and more than one ip address?

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 21:35:33 GMT
From:      AFDDN.TCP-IP@GUNTER-ADAM.AF.MIL
To:        comp.protocols.tcp-ip
Subject:   cisco question

Anyone know the answer to this one???

  Within the DDN Milnet, we are running IP over X.25.  GENERALLY speaking,
when a host has to send an IP datagram, it looks at the IP address of the
destination (or the next hop), then claculates the X.121 style address using
the DDN's algorithm.  If there's already a virtual circuit established to
that destination, then the datagram is queued and sent on that vc.  If there's
no vc already established, then the call request procedure is initaited and
a virtual circuit to the correct destination comes into being.  The end result 
of this behavior is that only one X.25 vc is established between any given
pair of IP addresses on the same network (what a concept).

  Now for the meat of the question.  Let's suppose that I have my own packet
switch with 20 ports on it.  I have a cisco MGS or AGS gateway and I connect
my packet switch to the Milnet via the gateway.  I get the NIC to assign me
a class B net number such as 131.7.0.0.  I could then assign each of my 20
ports to have a different number in the forth octet, so I would have 
something like 131.7.x.1 thru 131.7.x.20.  I could also decide to connect
lans to my packet switch and subnet my class B addresses.  For instance, I
could let 131.7.1.x be a subnet that includes the cisco and each of the ports
which would give me 131.7.1.1 thru 131.7.1.254, of which I only need 20 
because I only have 20 ports.  Now, if I decide to connect a gateway from a
lan to my packet swicth on port 5, its address in subnet 131.7.1 would be 
131.7.1.5.  I could let the lan be subnet 131.7.32.x thru 131.7.255.x.  I
assume I could break the third octet on any convenient boundary. 

  now my problem is how to tell the cisco how to route to the gateway to
the lan based on the subnet field being in a range.  Any one see how this
would be done??  The second part of the question (assuming it can be done),
is whether the cisco will only open one vc to the lan gateway or 
whether it will try to open a vc for each unique IP destination address on 
the lan??

darrel b.
-------

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 21:40:56 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   X for PC

Good afternoon,
		I know this probably isn't the right forum for an X question,
but I thought that I had heard of MIT doing a public domain version of X
server for a PC running DOS. Does anyone have any info along these lines? I
know I saw a commercial package from a company called Hummingbird Communication
out of Ontario. Does anyone have any experience with this product and any
idea of net card requirements and price? It seems you never have time to see
everything you need to at Interop (:*).
			Thanks in advance,
					   Chris VandenBerg
					   chris@salt.acc.com

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 22:48:32 GMT
From:      dave@fps.com (Dave Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: rwhod protocol and >42 users

In article <7370@xenna.Xylogics.COM> loverso@Xylogics.COM (John Robert LoVerso) writes:
>If you are really hot on producing a new protocol, how about this.
>Simple observation shows that most of the information rwhod gives
>out doesn't change all that much.  So, perhaps a more reasonable
>approach, would be to use a delta protocol, where any given packet
>would include some new whoents and a few bits to delete old whoents.
>Thus, over a period of time (10 minutes?), a rwhod-listener might
>pick up a complete list of users.

This sounds like a reasonable idea.  Of course for it to be at all useful
multiple vendors would have to support it.  I'll try to put some work in
on it and then perhaps get it merged into the BSD stuff.

>
>Finally, you can just chuck rwhod and use Sun's "rusers/rup" instead.
>It works, albeit not very well.
>

I don't see any advantage to rusers over rwhod.  It generates a broadcast
packet (albeit a smaller one) and then it makes everyone on the network
do some work.  We had enough trouble already when people discovered
"perfmeter" and started hitting rstatd up for information every 10 seconds.

David L. Smith
FPS Computing, San Diego
ucsd!celerity!dave or dave@fps.com
"Repent, Harlequin!," said the TickTock Man

-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      10 Oct 89 23:13:45 GMT
From:      gja@mullian.ee.mu.oz.au (Inspector Gadget)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?) / OSI Transition

In article <8910100305.AA19076@sayshell.umd.edu> louie@SAYSHELL.UMD.EDU ("Louis A. Mamakos") writes:
>Geez.  What a fuss.
>
 [.......]
>This is my perspective as a serious user of RFC 1119.  Before you
>condemn the form, print the document and ask yourself if it would be
>as easy to understand if it was a "dumb" ASCII text document?
>
>louie

	IMO you've missed the point entirely. If _all_ that was ever 
available was paper versions from NIC (or where-ever) and people
were asked "Pretty Laser-printed or Plain 'ASCII' version?" I'm sure
everyone would take the pretty laser-printed ones for their bookshelves.
The problem is that the _form_ of the document is (for most people)
on electronic storage/retrieval systems. Postscript forms are of no use
at all until they're _printed_, yet not everyone wants to use paper
versions of the documents (as has been re-iterated over and over).
[ 'what ever happened to the paper-less office?', I thinks to meself]

	In case you think I don't understand how nice PS versions would be
I should mention that I've just "wasted" a week or so transferring a 
collection of RFCS to a MAC and prettying them up for laser-printing.
What I would have given for PS versions if they'd been archived somewhere.
(no flames about me stupidly ignoring "archive something-or-other" please.
what's done is done). However regardless of the inconvenience to me when
producing paper versions I'd still see it as important that ASCII versions
as stored for online reference (until everyone has graphics screens and 
a collection of programs to search PS documents just like we can now search
plain text documents. 'PSgrep' and 'PSmore' spring to mind.....).

	The issue is not simply ease of understanding, it's ease of
information retrieval.

Grenville Armitage

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 00:22:06 GMT
From:      ado@BBN.COM (Buz Owen)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for MPUT and MGET in FTP . . .

MGET and MPUT aren't explicitly specified in the FTP protocol spec (RFC 959)
because these commands a matter "local" to the user ftp program -- only the
language used between the FTP server program and the FTP user program is
standardized by the protocol spec.  Here are some hints though:

For MPUT, the user FTP program should accept an argument which designates a
group of local files to be sent -- a directory or subdirectlry name or file
group specifier, expressed according to the host's local convention, and
execute "STOR" commands for each of the files indicated.  If the local system
contained system calls or subroutines for interpreting file group specifiers,
these facilities should be used to give standard local semantics to the
argument.

For MGET, the user program should accept a string argument (with no local
interpretation), submit an NLST command with this string as its argument to the
server to obtain a list of files on the server which match the argument, and
then execute one RETR command for each filename in the list received from the
server, retrieving each of the files in turn.  A point to watch out for here is
that (a naive implementation of) the FTP server might only respond to NLST with
whole directory or subdirectory listings -- i.e. fail to implement its own
local group name convention, or the server's operating system might not have a
file group naming convention.  In any case, it is the user's responsibility to
know the remote syntax for designating a group of files, not the ftp user
program's responsibility.

MGET and MPUT will work better if the user FTP program is prepared to create
local directories implicitly when doing MGET, and to execute MKD, CWD and CDUP
commands when doing MPUT to transfer a file hierarchy, since there is no
guarantee that a server will create necessary (sub) directories when given a
filename containing directory components in a STOR command.

When transferring to or from a system with differing filename syntax, the user
FTP program might also (attempt to) give help in adjusting or translating
filenames, although this can't be done in a fully general way.  The original
implementation of MGET and MPUT at BBN contained heuristics to translate
between unix file name syntax and Tenex/TOPS20 or Multics file name syntax.
This involved optional stripping of trailing version numbers, case translation,
delimiter translations, (e.g. ">" to "/" for Multics), and removal of the
directory component, under control of various flags.

The discussion in RFC 959 under the NLST, MKD, PWD, and CDUP commands may be of
some help here.  The advice in in RFC 1123 under the same topics and also under
"user interface" is also relevant.

With apologies for possibly belaboring the obvious, hope this helps.

Buz

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 02:42:03 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: experience using commercial cable TV as a MAN.

In article <9456@zodiac.ADS.COM> dglo@ads.com (Dave Glowacki) writes:
! eli@ursa-major.spdcc.COM (Steve Elias) writes:
!!	...St. Paul, Minnesota have linked their respective ethernets
!!	over their local cable systems -- the result for each is a 
!!	full speed ethernet that spans many buildings, many miles apart.
!
!St. Paul's broadband link is half-speed, but full speed links are doable
!(if you can get 'em past the politicians :-)  Unfortunately, this link
!is only used as a glorified Appletalk network link (or was when I left the
!city 8 months ago.)  In its infinite wisdom, the rest of the city is
!"networked" up over another chunk of broadband via a bunch of glorified
!terminal servers.

	the network i refer to was installed just a few months ago...
	actually, i think St. Paul is referring to it as a 'beta test'.




-- 
 ... Steve Elias (eli@spdcc.com);6178906844;6179325598; {}
/* free email to fax gateway for destinations in metro Boston area. */
/* send email and the destination fax number... */

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 02:54:42 GMT
From:      messingr@KODAK.COM (Rich Messinger x24361 B83, Rm 528, RL, 02221)
To:        comp.protocols.tcp-ip
Subject:   Source for ftp for Ultrix

I am thinking of doing some tracking of ftp usage on our system and I
figure that the best way to get the information is to make a local
modification to the ftp/ftpd source.  We are running on a uVAX with
Ultrix.  Does anyone out there know where I can get my hands on the code?
Or has someone done this already so I do not reinvent the wheel?

Thanks in advance.

Richard Messinger
Eastman Kodak

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Wed, 11 Oct 89 13:54:11 HST
From:      Torben Nielsen <torben@foralie.ics.Hawaii.Edu>
To:        GMILIEFS@MITVMA.MIT.EDU, kasten%interlan.interlan.com@RELAY.CS.NET, tcp-ip@NIC.DDN.MIL
Subject:   Re:  Multihoming
>Date:	Wed, 11 Oct 89 04:56:16 HST
>From:	Frank Kastenholz <kasten%interlan.interlan.com@RELAY.CS.NET>
>Message-Id: <8910111456.AA19313@interlan.interlan.com>
>To:	GMILIEFS@MITVMA.MIT.EDU, tcp-ip@NIC.DDN.MIL
>Subject: Re:  Multihoming
>Status: R
>
>Gary,
>
>A node name is just something to make it easy for us human types to enter
>commands. The node name/IP address mapping is a function of your local
>directory system. Most, if not all, such directory systems basically
>do one-to-one mapping - one host name per IP address and vice versa.
>
>A directory system _could_ return >1 IP address for a given node name, but
>then the problem of choosing which IP address to use comes up - if I say
>FTP FOO and I get back 2 IP addresses - 1.1.1.1 and 2.2.2.2, which one should
>I use? There are all kinds of heuristics that one could use (I am "closer"
>to net 1.x.x.x than I am to 2.x.x.x, etc, etc, etc) but no one does.

False, some systems have the capability to return addresses according to a 
defined sort order. So you try one after the other until you either get
a connection or run out of addresses.

>Having a unique name for each IP address solves these problems, but
>introduces some human problems. A machine would have multiple equally
>valid names - "You can call me Ray, or You can call me Jay...."

It introduces quite a few other problems too you know. Talk to people who
do this with Sun's. There are cases where you have to there because of the
way the server/client stuff is/was (haven't looked at that recently) done.

>So, to summarize - having one name and multiple IP addresses is theoretically
>possible, but there does not seem to be any support for it in the name/address
>resolution systems so the tacit implementors agreement is one address/one name.

????? I have lots of systems with one name and multiple IP addresses (and
so do a lot of others!). The workstation I'm on now is not a gatewway; yet
it sits on two ethernets and has two IP addresses. Works just fine; it's even
supported :-)

							Torben
-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 05:03:39 GMT
From:      satz@CISCO.COM (Greg Satz)
To:        comp.protocols.tcp-ip
Subject:   Re: cisco question

>>   Now for the meat of the question.  Let's suppose that I have my own packet
>> switch with 20 ports on it.  I have a cisco MGS or AGS gateway and I connect
>> my packet switch to the Milnet via the gateway.  I get the NIC to assign me
>> a class B net number such as 131.7.0.0.  I could then assign each of my 20
>> ports to have a different number in the forth octet, so I would have 
>> something like 131.7.x.1 thru 131.7.x.20.  I could also decide to connect
>> lans to my packet switch and subnet my class B addresses.  For instance, I
>> could let 131.7.1.x be a subnet that includes the cisco and each of the ports
>> which would give me 131.7.1.1 thru 131.7.1.254, of which I only need 20 
>> because I only have 20 ports.  Now, if I decide to connect a gateway from a
>> lan to my packet swicth on port 5, its address in subnet 131.7.1 would be 
>> 131.7.1.5.  I could let the lan be subnet 131.7.32.x thru 131.7.255.x.  I
>> assume I could break the third octet on any convenient boundary. 

Is the following picture equivalent to the above words?

    ---26---ciscoM---131.7.1.1---[switch]---131.7.1.5---ciscoL---131.7.x.y
      X.25             X.25                   X.25                LAN

>>   now my problem is how to tell the cisco how to route to the gateway to
>> the lan based on the subnet field being in a range.  Any one see how this
>> would be done??  The second part of the question (assuming it can be done),
>> is whether the cisco will only open one vc to the lan gateway or 
>> whether it will try to open a vc for each unique IP destination address on 
>> the lan??

The way to make this work is to inform the routers of each other's
presence. This can be done using static routing or with a dynamic routing
protocol such as IGRP. The cisco connected to Milnet, ciscoM, must know
that everything on 131.7.0.0 is reachable out its X.25 interface connected
to your 20 port switch. The cisco connected to the LAN, ciscoL, must know
that the rest of the world is accessible via its X.25 interface.

Whether you use static or dynamic routing, the routing database will
contain the next hop address which will either be 131.7.1.1 for ciscoL or
131.7.1.5 for ciscoM. As these two routers get involved in all traffic
between them, a minimum of one VC is used. More can be permitted using the
X.25 NVC parameter.

For example, if ciscoM needed to send something to 131.7.32.1, it would
find that 131.7.5.1 was the next hop address. Furthermore if ciscoL needed
to send something to 10.2.0.2, it would find the next hop to network 10 is
131.7.1.1. In both these cases, your excellent description holds.

For more configuration details, please send mail to
customer-service@cisco.com.

Greg Satz
cisco

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 07:34:36 GMT
From:      tli@sargas.usc.edu (Tony Li)
To:        comp.protocols.tcp-ip
Subject:   Re:  Counting Internet Hosts (and Users)

In article <8910101451.AA01170@interlan.interlan.com>
kasten@interlan.interlan.COM (Frank Kastenholz) writes: 
    Gee, 
    
    Seems like there is a simpler way to do it......
    
        for (i=0; i<0xffffffff; i++)
             foo = ping(i)
            if (foo == answered)
               number_of_hosts++;
    
    Its only an order n problem . . . no fancy protocols, no worrying about
    whether you are allowed to dump the domain tables, etc, etc...

Yes, but it probably takes about 136 YEARS to run (assuming that pings
take about 1 second to either respond or time out).

Thanks, but we're not young enough.

Tony Li - USC University Computing Services
Internet: tli@usc.edu	Uucp: usc!tli	Bitnet: tli@gamera, tli@ramoth
This is a test.  This is a only a test.  In the event of a real life
you would have been given instructions.

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 08:12:40 GMT
From:      pcf@galadriel.bt.co.uk (Pete French)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Re: tcp/ip terminal servers with slip support?

From article <381@galadriel.bt.co.uk>, by pcf@galadriel.bt.co.uk (Pete French):
> O.K. - I give up, I have been reading this group now for 3 months so will
> somebody please mai me and tell me what SLIP is please.

Thanks to the 37 people who have replied so far ! ... I now know exactly what
slip is .

-Pete.

-- 
       -Pete French.               | "Love is the corpse,
  British Telecom Research Labs.   |  That crawls on dreams,
 Martlesham Heath, East Anglia.    |  Rips them apart,
All my own thoughts (of course)    |  And tears them to shreds" - SOM

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 09:48:24 GMT
From:      epsilon@wet.UUCP (Eric P. Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC for MPUT and MGET in FTP . . .

In article <14005@well.UUCP> nagle@well.UUCP (John Nagle) writes:
>	1) 3-cornered FTP (source, destination, and control points on 
>	   different hosts) never worked.

Excuse me, when did it ever not work?  I'm not being facetious
here.  If what you say is true, what's this "proxy" command doing
in user-FTP?

>
>	2) Transferring many small files in succession tends not to work.
>	   If you try to reuse the data connection immediately, it won't
>	   reopen, even though the TCP spec says it should.  This is a bug
>	   in the spec.  Most current FTP implementations use the PORT
>	   command to get a new data connection for each file, leaving the
>	   old one to time out in TIME_WAIT state.

Read the spec again.  In the default (STRU F/MODE S) you can't
reuse the socket since closure is used to indicate end of file.
Maybe I should bring my "why are there so many MINIMAL
implementations" gripe over here from Info-Nets...

					-=EPS=-

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 09:52:07 GMT
From:      ug051@crayamid.cray.com (Michael Nittmann)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multihoming

So, even on a multihomed host, the hostname command gives you the
let's say generic name under which the hosts identifies itself.
BUT: names have no significiance, it is the internet addresses that 
count, the allocated names (via hosts file) only have to be unique.
Ergo: multihomed host had different names for every internet address it hosts.

michael

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 12:23:05 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Hanging connections


	We are having troubles communicating with some new machines on the
Internet in Mexico.  The symptoms are that we can make ftp or telnet
connections, which seem to work initially, but soon after the connection is
made (some data point to it being after 512 bytes have been transferred,
but we're not sure about that yet) the connection hangs.  How do I go about
trying to figure out what might be wrong?  Some of you might remember my
asking about ping packets being duplicated; that was between us and this
same host, I don't know if the two phenomina are related.

	The remote hosts we are trying to reach are 132.247.5.1 (pbr322)
and 132.247.5.2 (pt7mdv).  I don't believe the host names have been
officially registered yet, but that's what we call them in our host table
(they don't seem to be in anybody's nameserver yet).  We usually try to
reach them from some machine on our local network such as 128.122.136.12,
but yesterday we tried it from rocky2.rockefeller.edu (129.85.1.2) with the
same results, so I don't think the problem is at our end.  The same
problems seem to occur regardless of which side initiates the connection.
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 13:33:58 GMT
From:      DIXON-R@OSU-20.IRCC.OHIO-STATE.EDU (Bob Dixon)
To:        comp.protocols.tcp-ip
Subject:   Fax over tcp/ip

This is a pre-announcement of a Fax over tcp/ip package we now have operational
here in prototype form, and which will be made available free to educational
institutions when it is finished and polished up.
 The basic scheme is to use a PC clone as a network gateway (total hardware
cost for PC is $2K). A fax card is used in the PC to communicate with a
co-located conventional group 3 fax machine. The fax machine thinks it is
using a telephone line to call some distant fax machine, but in fact it is
just talking to the PC. The PC stores the fax data as a binary file. The PC
then uses binary FTP to send the fax file out its ethernet port to any similarly
arranged system anywhere in the Internet, where the process is reversed.
The FTP portion of the operation is essentially instantaneous in comparison
with the normal time needed by the fax machine to scan a document.
 A scanner and graphics printer can be used instaed of the local fax macine if
desired. Both the fax machine and PC may also be used for other tasks if
desired, and need not be dedicated solely to this function.
 It is not terribly difficult to assemble such a system, and to operate it in
a crude manual mode. We have it operable in a somewhat automated mode now,
and are working on the necessary software to make it robust, error-tolerant
and very user-friendly so that it can be used as a routine tool by people
such as librarians. There is great need for such a capability among libraries
for inter-library loan.
 When the software is finished it will be distributed free to anyone who
wants it, along with a suggested hardware configuration.

                                Bob Dixon
                                Ohio State University

-------

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 13:53:45 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip
Subject:   Re: Fax over tcp/ip

will we see complaints about fax files using too much bandwidth on 
the internet?  the service i offer is not used very often, and only
transfers small text files when it is used.  i am reluctant to offer
the reverse service, as the gentleman from ohio state has just offered.

an average fax page is about 20k or 30k...  i've been wondering if 
people (site admin cats) would complain if the internet were used 
routinely to transfer fax files around...  what do you think?



-- 
 ... Steve Elias (eli@spdcc.com);6178906844;6179325598; {}
 /* email2fax!  send email for info */

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 14:56:16 GMT
From:      kasten@interlan.interlan.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multihoming

Gary,

A node name is just something to make it easy for us human types to enter
commands. The node name/IP address mapping is a function of your local
directory system. Most, if not all, such directory systems basically
do one-to-one mapping - one host name per IP address and vice versa.

A directory system _could_ return >1 IP address for a given node name, but
then the problem of choosing which IP address to use comes up - if I say
FTP FOO and I get back 2 IP addresses - 1.1.1.1 and 2.2.2.2, which one should
I use? There are all kinds of heuristics that one could use (I am "closer"
to net 1.x.x.x than I am to 2.x.x.x, etc, etc, etc) but no one does.

Having a unique name for each IP address solves these problems, but
introduces some human problems. A machine would have multiple equally
valid names - "You can call me Ray, or You can call me Jay...."

So, to summarize - having one name and multiple IP addresses is theoretically
possible, but there does not seem to be any support for it in the name/address
resolution systems so the tacit implementors agreement is one address/one name.

Cheers
Frank Kastenholz
Racal InterLan

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 16:03:42 GMT
From:      solensky@interlan.interlan.COM (Frank Solensky)
To:        comp.protocols.tcp-ip
Subject:   Re:  Telnet options RFC?

In <1813@cooper.cooper.EDU>, Jeff Hanker writes:

>	              I need the RFC which contains a list of all the currently
>	registered telnet option codes and a description of them.  If they
>	are not in a single RFC, then I need the list of such RFCs.  N.B.:
>	I AM NOT talking about RFC854 or 855.

Here's a list of Telnet RFCs that are listed in an article about Telnet by
Barry Shein in the current issue of "Connexions: The Interoperability Report"
(v3,n10).

RFC#   Title
----   -----
726  Remote Controlled Transmission and Echoing Telnet Option
727  Telnet Logout Option
728  Minor Pitfall in the Telnet Protocol
732  Telnet Data Entry Terminal Option (updated by 1043)
735  Revised Telnet Byte Macro Option
736  Telnet SUPDUP option
748  Telnet Randomly-lose Option  (published 4/1/78)
749  Telnet SUPDUP-Output Option
779  Telent Send-Location Option
818  Remote User Telnet Service
856  Telnet Binary option
857  Telnet Echo
858  Telnet Supress Go-Ahead
859  Telnet Status Opion
860  Telnet Timing Mark
861  Telnet Extended Options: List Option
885  Telnet End-of-Record Option
927  TACACS User Identification Telnet Option
930  Telnet Terminal Type Option
933  Output Marking Tlenet Option
946  Telnet Terminal Location Number Option
1041 Telnet Data Entry Terminal Option
1053 Telnet X.3 PAD Option
1073 Telnet Window Size Option
1079 Telnet Terminal Speed Option
1080 Telnet Flow Control Option
1091 Telnet Terminal Type Option
1096 Telnet X Display Location Option
1097 Telnet Subliminal Message Option  (published 4/1/89)

In addition, Douglas Comer lists some additional older RFCs in Appendix 3
of "Internetworking With TCP/IP":

RFC#   Title
----   -----
726  Remote Controlled Transmission and Echoing Telnet Option
719  Discussion on RCTE
718  Comments on RCTE from Tenex Implementation Experience
703,702,701,679,669  Survey of New-Protocol Telnet Servers
698  Telnet Extended ASCII Option
659  Announcing Additional Telnet Options
658  Telnet Output Line Feed Disposition
657  Telnet Output Vertical Tab Disposition Option
656  Telnet Output Vertical Tab Stops Option
655  Telnet Output Form Feed Disposition Option
654  Telnet Output Horizontal Tab Disposition Option
653  Telnet Output Horizontal Tab Stops Option
652  Telnet Output Carriage Return Disposition Option
651  Revised Telnet Status Option
587  Announcing New Telnet Options
581  Corrections to RFC 560 - Remote Controlled Transmission and Echoing
	Telnet Option
563  Comments on the RCTE Telnet Option
560  Remote Controlled Transmission and Echoing Telnet Option

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 16:51:47 GMT
From:      chris@wugate.wustl.edu (Chris Myers)
To:        comp.protocols.tcp-ip
Subject:   Re: Source for ftp for Ultrix (LONG)

In article <8910110254.AA01526@Kodak.COM> messingr@KODAK.COM (Rich Messinger x24361 B83, Rm 528, RL, 02221) writes:
>I am thinking of doing some tracking of ftp usage on our system and I
>figure that the best way to get the information is to make a local
>modification to the ftp/ftpd source.  We are running on a uVAX with
>Ultrix.  Does anyone out there know where I can get my hands on the code?
>Or has someone done this already so I do not reinvent the wheel?

I have already done this using the 4.3BSD Tahoe ftp source (available at
many archives).  The ftpd program logs, to /usr/adm/xferlog, all successful
transfers and some information about each one: date, time, remote host,
seconds to transfer, file size, file path.

Here is an example from the log for wuarchive.wustl.edu (Washington University's
public archive system, a DECstation 3100 running Ultrix 3.1):

Sun Oct  1 00:44:25 7 en.ecn.purdue.edu 31841 /mirrors/msdos/mswindows/xword.arc.1
Sun Oct  1 00:44:42 8 en.ecn.purdue.edu 34688 /mirrors/msdos/mswindows/spy104.arc.1
Sun Oct  1 00:45:11 9 en.ecn.purdue.edu 50736 /mirrors/msdos/mswindows/gcp42s.arc.1
Sun Oct  1 00:45:42 17 en.ecn.purdue.edu 103802 /mirrors/msdos/mswindows/xvtdraw1.arc.1
Sun Oct  1 00:58:30 1 nsco.network.com 1776 /README

I have also written a perl script that will analyze the log file and give you
a report on archive usage (usage by day, by domain, by archive section and
by host; also transfer rates and percent-of-total usage figures):

   TOTALS FOR SUMMARY PERIOD Sun Oct  1 TO Wed Oct 11
   
   Files Transmitted To Date         4520
   Bytes Transmitted To Date    251802377
   Systems Using Archives             254
   
   
   Daily Transmission Rates
   
               Number Of   Number of   Average    Percent Of  Percent Of
      Date     Files Sent  Bytes Sent  Xmit Rate  Files Sent  Bytes Sent
   ----------  ----------  ----------  ---------  ----------  ----------
   Sun Oct  1         358    23781997   2450 cps      7.92        9.44
   Mon Oct  2         623    19882380   1202 cps     13.78        7.90
   Tue Oct  3         319    17160460   3004 cps      7.06        6.82
   Wed Oct  4         221    13721780   4507 cps      4.89        5.45
   Thu Oct  5         503    36682417   2878 cps     11.13       14.57
   [ several more days trimmed out ]
    
   Total Transfers from each Archive Section
   
          Archive Section          Files Sent  Bytes Sent
   ------------------------------  ----------  ----------
   Index and Informational Files          179    30498244
   fixes/bsd-vax                            1        4292
   fixes/sunos-sun3                         4       48189
   fixes/ultrix-vax                         1         376
   gnu                                     15    14047859
   graphics/gif                           721    41148099
   graphics/lpr_art                       813     3994099
   info                                    13      355107
   info/linkletter                          1        3685
   info/rfc                                 2       65062
   mirrors/info-mac                       303    15690822
   mirrors/msdos                         1540    97314333
   network_info                            11     2144738
   packages/X.V11R3                        26     6233589
   packages/tex                            26    12857821
   packages/uupc                           11      694655
   pub                                      3      656326
   pub/gnu                                  1       70209
   pub/ingres                               5     5533558
   pub/ntp                                  1          20
   pub/private                              1        9323
   pub/rfc                                  3      101696
   pub/sr                                   1        1931
   pub/tex                                  5       16143
   systems/ibmpc                            1      226401
   systems/sun                             21      262073
   unix/4.3BSD-tahoe                        9       28393
   usenet/comp.binaries.amiga              73     2593054
   usenet/comp.binaries.apple2            195     3494910
   usenet/comp.binaries.atari.st          182     5181405
   usenet/comp.binaries.ibm.pc             91     2705673
   usenet/comp.sources.atari.st            12       92666
   usenet/comp.sources.games               68     2304398
   usenet/comp.sources.misc                 9       80133
   usenet/comp.sources.sun                 12      201785
   usenet/comp.sources.unix               153     2959627
   usenet/comp.sources.x                    5       58111
   usenet/comp.virus                        2      123572
   
   
   Total Transfer Amount By Domain
   
                Number Of   Number of   Average    Percent Of  Percent Of
   Domain Name  Files Sent  Bytes Sent  Xmit Rate  Files Sent  Bytes Sent
   -----------  ----------  ----------  ---------  ----------  ----------
   ca                   80     5028804   1760 cps      1.77        2.00
   dk                   58     2791217   1579 cps      1.28        1.11
   ed                    1      103348   2198 cps      0.02        0.04
   fi                    1        1776   1776 cps      0.02        0.00
   fr                   17     5986162   2431 cps      0.38        2.38
   no                    4       48189    803 cps      0.09        0.02
   se                   12      699905   1846 cps      0.27        0.28
   uk                   10      812722    456 cps      0.22        0.32
   us                   28     1639883   2538 cps      0.62        0.65
   com                 307    22213496   1401 cps      6.79        8.82
   edu                3002   142759922   2936 cps     66.42       56.70
   gov                  18     1016118   1745 cps      0.40        0.40
   mil                  10     1868862   3009 cps      0.22        0.74
   org                  60     7271711   4191 cps      1.33        2.89
   scp                  91     2080077     54 cps      2.01        0.83
   arpa                 20     1435159    195 cps      0.44        0.57
   wustl.edu           176    32048501  54227 cps      3.89       12.73
   unresolved          625    23996525   2878 cps     13.83        9.53
    
   Total Transfer Amount By System
   
                                     Number Of   Number of   Average
        System Name or Address       Files Sent  Bytes Sent  Xmit Rate
   --------------------------------  ----------  ----------  ---------
   [some address or hostname]                 4       17601   2514 cps
   [some address or hostname]                 1       11695   2923 cps
   [some address or hostname]                54     1351255   4222 cps
   [some address or hostname]                 1      239819   5102 cps
   [some address or hostname]                 1        5230    747 cps
   [some address or hostname]                 3       78640   4915 cps
   [some address or hostname]                67     4131605    395 cps
   [some address or hostname]                 1      287125   4950 cps
   [some address or hostname]                 3       29243   2249 cps
   [some address or hostname]                 4      141036   2136 cps
   [some address or hostname]                 1        1776    888 cps

   [more stuff cut out]

Anyway, since you [the reader] are interested in this enough to read the
entire article, I'll mail you a copy of both the modified ftp and the
reporting script on request.

Chris Myers                                   Internet: chris@wugate.wustl.edu
Software Engineer                               BITNET: chris@wunet.bitnet
Office of the Network Coordinator                 UUCP: uunet!wugate!chris
Washington University in Saint Louis             Phone: +1 314 362 6186

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 17:05:41 GMT
From:      ebrill@bronze.bacs.indiana.edu (Ed Brill)
To:        rec.ham-radio.packet,comp.protocols.tcp-ip
Subject:   VT100 emulation for KA9Q net code

I use KA9Q net code to connect to our various network resources here at IU
from time to time.  Things like the emacs editor, though, have real trouble
trying to work with KA9Q (through no fault in the software, that's not really
something hams often have to worry about).

Is there an ANSI.SYS driver or something like that, or a code modification I
could use to get net to work better with emulation?

Thanks
and 73,


Ed Brill                              |  SysOp, the IU PC-Link Central BBS
Indiana University Computing Services |  (812) 855-7252
ebrill@subcomm.bacs.indiana.edu       |  KA9TAW @ K9IU (ham radio packet)
ebrill@iubacs.bitnet                  |  ...!pur-ee!iuvax!silver!ebrill

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 17:58:44 GMT
From:      jbvb@ftp.COM (James Van Bokkelen)
To:        comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: pt200 term. emulator over TCP/IP

In article <Oct.2.22.45.42.1989.12597@pilot.njin.net>, ccoombs@pilot.njin.net (Cliff Coombs) writes:
> Question(s):
> 	Does anyone make a pt200 TCP/IP emulation product?  Is there a
> 'generic' emulation product I should try?  If I provide a termcap file
> can a product be made?  If so by whom?  Can I get C code and adapt it
> myself?  Since the vice-president wants this right away should I look
> for another job?

You probably have PC/TCP v2.03.  In this version, you can use TNGLASS with
any emulator that loads as a DOS "console" driver (like ANSI.SYS).  As of
2.04 (which we ship this week, but Sytek may lag a bit with), TNGLASS also
supports emulating BIOS serial line services on INT 14, so you could use
emulators which work that way, too.  I can't supply the emulator, though.
-- 
James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 19:44:17 GMT
From:      dan@ccnysci.UUCP (Dan Schlitt)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?) / OSI Transition

Well, now that you mention it, the NTP documentation was the exact
place where I encountered this postscript mania.  I tried to read it
on-line and found it to be unreadable.  Yes, I can get it to a
postscript printer.  But that is a pain in our case and I don't really
want a paper copy.  So I postponed looking at NTP and went on to
something else.

Please, please give us something we can use unix tools like grep on
and can read on our terminals without having to have a display
postscript based terminal.

Thanks.
-- 
Dan Schlitt                        Manager, Science Division Computer Facility
dan@sci.ccny.cuny.edu              City College of New York
dan@ccnysci.uucp                   New York, NY 10031
dan@ccnysci.bitnet                 (212)690-6868

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 20:11:19 GMT
From:      jmwobus@cmx.npac.syr.edu (John Wobus)
To:        comp.protocols.tcp-ip
Subject:   New Host-Requirement RFCs

Re the new Host requirements RFCs.

The good news: we now know what an Internet host is.

The bad news: there is no Internet host in the world!

The shocking news: of the two vendors I heard speak on the subject
   at Interop, neither plans to fully comply!

I'm happy that the RFCs are completed and I appreciate the work
involved.  However, I'm sure a lot of us users were hoping for
something we could refer to in procurement specifications.  Besides
requiring some less-than-generally-useful features like source
routing, it avoids the issue of implementations not meant to include
all the applications mentioned, i.e., a single-user system which
wisely makes no effort to offer SMTP service.

We will be happier if either vendors change their attitudes or if
another paper (RFC?) is developed to fill the gap--I can imagine
a paper describing everything a host ought to do if it can claim
to offer "TELNET" service, if it can claim to offer "FTP" service,
etc.  Perhaps it could also address the different protocols below
IP too.

Once again, the Host Requirement RFCs represent signficant work in the
right direction.  It is just that they might not turn out
to be QUITE as useful as I had hoped.

John Wobus
Syracuse University

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 21:53:13 GMT
From:      jdarcy@encore.UUCP (Jeff d'Arcy)
To:        comp.bugs.4bsd,comp.protocols.tcp-ip
Subject:   TCP reassembly problem

I came across an interesting TCP bug in our BSD-based OS (we try to stay
current with regard to BSD releases), and I was wondering if anyone else
has any comments or insight to offer.

The problem occurs when a segment with FIN set is received out of order
(i.e. some prior packet has not yet arrived).  It seems that tcp_input()
calls tcp_reass() to put the segment on the TCP reassembly queue, but
then the connection is put into CLOSE_WAIT state.  This results in the
missing segment being dropped when it arrives, among other less drastic
side effects (e.g. duplicate FIN processing).

Obviously, this loss of data is not a good thing.  The problem was fixed
quite easily, by "forgetting" that FIN was set until the reassembly queue
is emptied, but I'm surprised that it ever existed.  By looking at Tahoe
and Network Release sources it seems (can't be 100% certain) that the bug
would exist in stock distributions also.  Has anyone else seen it?

Interestingly, the bug first showed up when fingering a remote machine,
most commonly when going through a gateway or to a Sun.  Even then the
symptoms only appeared about 1/6 of the time.

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 22:43:05 GMT
From:      baker@VITAM6.UUCP (Fred Baker)
To:        comp.protocols.tcp-ip
Subject:   MIB Object Access

This is getting to be an interesting conversation.  As for Frank's three
approaches, the one I've observed is the first - two vendors get together,
one of whom wants to OEM or reference sell the other's product,
and agree on the MIB thingies needed to provide the service in question.
Of course, competitors don't necessarily make the same deal - they go to
Other Guy Inc, who defines a different set of MIB objects to perform
a similar service.

Now, if First Guy Inc puts its MIB objects into the public domain using
some sort of MIB Distribution service (SMTP to MIB@NIC?), then this sort of
stuff gets less play, and First Guy Inc is a Good Person In The Internet.
Hubba Hubba.

It seems to me that the Net Management Station gets its download of MIB
thingies offline and stores them - after all, an ASN.1 Object is supposed
to be forever invariant.  He doesn't put his head up in a firefight.

Now, it seems to me that the question of relevence is: how does Generic Inc's
management station really make use of the MIB objects?  Given that he has
downloaded the representation, name, definition, and humanspeak verbiage
about an object, at the moment about all that he can do is say that
NETWORK.BOX.FROM.<VENDOR> sent out GOOD.THING.TO.KNOW, which it dutifully
stores in a database, prints out, or graphs.  So?

Fred Baker
baker@vitalink.com

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      11 Oct 89 23:59:07 GMT
From:      nisca.ircc.ohio-state.edu!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!fallst!tkevans@tut.cis.ohio-state.edu  (Tim Evans)
To:        tcp-ip@NIC.DDN.MIL
Subject:   TCP/IP for Mixed BSD/Sys V Network
We have a mixed network of VAXen running BSD (four of them), AT's running
VentureCOM (tm) Venix '286 (250 of them), and '386 AT clones running
SCO Xenix (tm) (150 of them).  We are using an XNS networking
product and are considering joining the rest of the world.

What TCP/IP packages (commercial and public domain) might be available
to run in such an environment?

Please reply via e-mail, using the path shown below.  Recent changes
in my connections have probably rendered your pathalias data out of
date.  I will provide a summary if response warrants.  Thank you.
-- 
UUCP:		uunet!anagld!aplcen!fallst!tkevans
INTERNET:	tkevans%fallst@aplcen.apl.jhu.edu
OTHER: 		...!attmail!fallst!tkevans
Tim Evans  2201 Brookhaven Court, Fallston, MD  21047   (301) 965-3286
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 01:24:41 GMT
From:      michaud@devax.dec.com (Jeff Michaud)
To:        comp.protocols.tcp-ip
Subject:   Re: rwhod protocol and >42 users

> Finally, you can just chuck rwhod and use Sun's "rusers/rup" instead.
> It works, albeit not very well.

	Is rusers like remote finger (ie. like "f @some-host-name")?

	A more efficient method all around would be to have a dedicated system
	act as a "remote who" server.  On a timer the server system (lets call
	this one the master server) will send out a udp broadcast advertising
	itself as a "remote who" server.  Hosts that want to advertise who's
	logged on the system (call these slave servers) send the info directly
	to the "remote who" server.   Clients which want info on whos logged
	in on the network asks the local slave server (who knows who the master
	server is) who in turns asks the master server (or the slave server
	can store the master servers address/port away where clients can use
	it to request the info directly from the master server).

	To extend this just a bit further so improve on the availability
	problem if the master server is down, we can allow for multiple
	master servers to exist.  Slave servers will remember all the master
	servers and also send their "whos logged on me" messages to each
	of the masters.  3-4 servers on a lan should be sufficient if
	a high assurance of availability is needed.

	This reduces udp broadcast traffic for an equiv service to rwho
	down to 4/minute if there is 4 master servers which each advertise
	themselves once a minute.  It also removes the beating on the
	disk to keep writing out to the /usr/spool/rwho/whod.* files
	(my workstation has been up 7 days and rwhod already has 47 minutes
	of cpu time, and this is on a fast DECstation 3100!).

	This would probably be a good job for a location brokerage service?

/--------------------------------------------------------------\
|Jeff Michaud    michaud@decwrl.dec.com  michaud@decvax.dec.com|
|DECnet-ULTRIX   #include <standard/disclaimer.h>              |
\--------------------------------------------------------------/

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Oct 89 08:11:43 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        Frank Kastenholz <kasten@interlan.interlan.com>
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: Multihoming

> A node name is just something to make it easy for us human types to enter
> commands. The node name/IP address mapping is a function of your local
> directory system. Most, if not all, such directory systems basically
> do one-to-one mapping - one host name per IP address and vice versa.
> 
> ...
> 
> So, to summarize - having one name and multiple IP addresses is theoretically
> possible, but there does not seem to be any support for it in the name/address
> resolution systems so the tacit implementors agreement is one address/one name.

Frank:

    I think the tide is moving the other way.  People will use one name which
maps to multiple addresses.  The Host Requirements states that applications
have to be able to handle a case where a name maps to multiple addresses,
and if one fails, try to connect to the other.

Craig
-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 01:39:13 GMT
From:      randall@uvaarpa.virginia.edu (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

In article <1949@cmx.npac.syr.edu> jmwobus@cmx.npac.syr.edu (John Wobus) writes:

>  However, I'm sure a lot of us users were hoping for
>something we could refer to in procurement specifications.  

The new host requirement RFCs are "something we can refer to
in procurement specifications" and I think a lot of vendors
will be seeing them referred to in that fashion in the future.

>Besides requiring some less-than-generally-useful features like source
>routing, it avoids the issue of implementations not meant to include
>all the applications mentioned, i.e., a single-user system which
>wisely makes no effort to offer SMTP service.

I strongly disagree with the notion that RFC-822 source routing
is "not generally useful."  The mail systems I manage for GE all
fully support source routing as specified in RFC-822 and I put use
them in some outgoing mail (e.g. in mail to DECnet gateways that
are less than correctly defined { not GE mind you, our DECnet nodes
can all be reached as "userid@decnet-node-name.DNET.GE.COM" and
don't need the "% hack" of any other non-standard syntax. } ).
My systems do not support the "% hack" popularised by BSD sendmail
and will not as long as I manage their mail systems.  The "% hack"
is ugly, difficult to parse correctly at Internet--othernet gateways,
and not needed.  If your system doesn't support source routing, it
is broken and has been at least since RFC-822 came out.

A single-user, multitasking system should be able to handle SMTP.
IF your single-user system is single-tasking, I'd suggest that it
will never be much more than a very bright terminal to the rest
of the Internet.  Watering down an RFC to account for DOS machines
or the like strikes me as inappropriate.

>We will be happier if either vendors change their attitudes or if
>another paper (RFC?) is developed to fill the gap--I can imagine
>a paper describing everything a host ought to do if it can claim
>to offer "TELNET" service, if it can claim to offer "FTP" service,
>etc.  Perhaps it could also address the different protocols below
>IP too.

I predict that vendors will be moving strongly in towards supporting
the host requirements RFC precisely because I expect sites to cite
those RFCs in procurement requests. (See Above).

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Oct 89 08:25:07 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        John Wobus <jmwobus@cmx.npac.syr.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: New Host-Requirement RFCs

John:

    I think the picture is much better than you present.  Many users have
already expressed plans to put use the HR in their specifications.
Furthermore, the HR was sensitive to the needs of single-user systems.
As James Van Bokkelen stated at Interop, he thinks the MUSTs
in the HR are consistent with doing a DOS implementation.  (Except he
didn't like IP source-routing -- and then he confessed to recently
encountering a situation where he wished he had source-route support
in his IP.  I think James will concede he was biting his tail there...:-)

    My impression is that one of the vendors' biggest concerns is that
HR will require some effort to make existing, "working" code conform,
while at the same time, trying to enhance their products to keep up with
a changing world.  For most products which have tried earnestly
to track the TCP/IP protocol suite, these changes should not be very
extensive, but the concern is valid.  And to address this concern, the
IETF is planning to try to enforce a "quiet time" over the next 9 months
to a year during which we will not make new standards that affect hosts.
In other words, we'll try to make the protocol suite a fixed target for
the next year, so vendors have a chance to catch their breath and make
their implementations HR conformant.

Craig Partridge
IETF Area Director - Host and User Services
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 01:50:38 GMT
From:      michaud@devax.dec.com (Jeff Michaud)
To:        comp.protocols.tcp-ip
Subject:   Re:  Counting Internet Hosts (and Users)

> In article <8910101451.AA01170@interlan.interlan.com>
>     Seems like there is a simpler way to do it......
>     
>         for (i=0; i<0xffffffff; i++)
>              foo = ping(i)
>             if (foo == answered)
>                number_of_hosts++;
 
> Yes, but it probably takes about 136 YEARS to run (assuming that pings
> take about 1 second to either respond or time out).

	Thats only if you were to actually wait for for a response/timeout.  If
	you just continuously sent one right after the other without waiting for
	the response (but sending just slow enough as to not create a traffic jam)
	and simply count the number of responses.  I wonder how long that would
	take?

/--------------------------------------------------------------\
|Jeff Michaud    michaud@decwrl.dec.com  michaud@decvax.dec.com|
|DECnet-ULTRIX   #include <standard/disclaimer.h>              |
\--------------------------------------------------------------/

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Thu, 12 Oct 89 14:12:19 HST
From:      Torben Nielsen <torben@foralie.ics.Hawaii.Edu>
To:        stine@sparta.com, tcp-ip@NIC.DDN.MIL
Subject:   Re: Multihoming
>Enough of this practical, reality-based stuff! :-)
>
>Addresses are identifiers that are used to label where messages can be
>sent or received.  An IP address identifies a host's network
>interface.  A host may have several network interfaces.

And it could even have several IP addresses on the *same* network interface....

>Like IP addresses, host names are identifiers.  They are used to label
>(surprise!) hosts.  A host may have several host names.
>
>To use a network, a mapping must be made from host name to IP
>address(es).  Hence the DNS.

This is news to me at least. It is my understanding that if you use the
DNS, there can only be one host name. CNAMES records of course, but only
one ``true" name...

						Torben
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 07:37:45 GMT
From:      adnan@sgtech.UUCP (Adnan Yaqub)
To:        comp.protocols.tcp-ip
Subject:   What happens when TCP sequence numbers wrap?

I was looking over the Berkeley TCP code and began to wonder what
happens when TCP sequence numbers wrap.  In the tcp_input routine
duplicate acks are detected by the check (after macro expansion):
	(int) (segment ack - last unacknowledged) <= 0
It seems to me that if I send a message which ends at, say, sequence
number (2**32)-1, then when the ack arrives (which would be 0) I would
reject it as a duplicate.

Is this comething which is not worried about, or am I missing
something?
--
Adnan Yaqub
Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860
...cwjcc!ncoast!sgtech!adnan ...uunet!abvax!sgtech!adnan

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 1989 13:35-EDT
From:      CERF@A.ISI.EDU
To:        phri!roy@RUTGERS.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Hanging connections
I wonder if you are running into a large packet fragmentation
problem? If something is being fragmented and not reassembled
along the path of routers/gateways your traffic is going, the
TCP connection would get stuck.

Vint Cerf
-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 10:45:30 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Multihoming

Is there an RFC that defines a multihomed system?  In an AUTODIN environment
a multihomed system has a single name but multiple mutually exclusive routes
to the system.  Within the AUTODIN concept, NIC.DDN.MIL would be a multihomed
system as it is accessible from the ARPANET and the MILNET.  A system on a
regional network might be considered multihomed if it can be accessed direct-
ly from the Internet as well as the regional net.

Torben's workstation may be considered multihomed in its local environment
but would not be from my perspective if there is only one route to his LAN.

Now is a system really multihomed if the PSNs are co-located?

Merton

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 12:11:43 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Multihoming


> A node name is just something to make it easy for us human types to enter
> commands. The node name/IP address mapping is a function of your local
> directory system. Most, if not all, such directory systems basically
> do one-to-one mapping - one host name per IP address and vice versa.
> 
> ...
> 
> So, to summarize - having one name and multiple IP addresses is theoretically
> possible, but there does not seem to be any support for it in the name/address
> resolution systems so the tacit implementors agreement is one address/one name.

Frank:

    I think the tide is moving the other way.  People will use one name which
maps to multiple addresses.  The Host Requirements states that applications
have to be able to handle a case where a name maps to multiple addresses,
and if one fails, try to connect to the other.

Craig

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 12:12:30 GMT
From:      torben@FORALIE.ICS.HAWAII.EDU (Torben Nielsen)
To:        comp.protocols.tcp-ip
Subject:   (none)

Merton,

>Date:	Thu, 12 Oct 89 00:45:30 HST
>From:	mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
>Message-Id: <8910121045.AA23199@WLV.IMSD.CONTEL.COM>
>To:	GMILIEFS@MITVMA.MIT.EDU, kasten%interlan.interlan.com@RELAY.CS.NET,
>	tcp-ip@NIC.DDN.MIL, torben@foralie.ics.Hawaii.Edu
>Subject: Re:  Multihoming
>Status: RO
>

......
......

>Torben's workstation may be considered multihomed in its local environment
>but would not be from my perspective if there is only one route to his LAN.

There may be only one route from your perspective, but there're definitely
two paths. And you could reach the host via either path. One address is
128.171.1.2 and the other is 132.160.1.3. As it turns out,it's even the same
number of hops from you and a nameserver could return you either address.

What I was responding to was the comment abot systems not supporting
multiple addreses belonging to one name. That's clearly not the case
today.

						Torben

-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 12:25:07 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: New Host-Requirement RFCs


John:

    I think the picture is much better than you present.  Many users have
already expressed plans to put use the HR in their specifications.
Furthermore, the HR was sensitive to the needs of single-user systems.
As James Van Bokkelen stated at Interop, he thinks the MUSTs
in the HR are consistent with doing a DOS implementation.  (Except he
didn't like IP source-routing -- and then he confessed to recently
encountering a situation where he wished he had source-route support
in his IP.  I think James will concede he was biting his tail there...:-)

    My impression is that one of the vendors' biggest concerns is that
HR will require some effort to make existing, "working" code conform,
while at the same time, trying to enhance their products to keep up with
a changing world.  For most products which have tried earnestly
to track the TCP/IP protocol suite, these changes should not be very
extensive, but the concern is valid.  And to address this concern, the
IETF is planning to try to enforce a "quiet time" over the next 9 months
to a year during which we will not make new standards that affect hosts.
In other words, we'll try to make the protocol suite a fixed target for
the next year, so vendors have a chance to catch their breath and make
their implementations HR conformant.

Craig Partridge
IETF Area Director - Host and User Services

-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 12:59:03 GMT
From:      lazear@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

It seems quite appropriate for someone who wants the help
and definition that the RFC provides, but who only needs a
portion of the functionality, to specify the parts of the
RFC that are "optional" for his/her procurement.  Thus,
if you don't want your DOS "super-terminal" to do SMTP,
make it an optional part of the specs you put in your
RFP.

The downside is that *you* have to decide what will affect
your interoperability, not some committee from a larger
community of interest.  Cutting out the "wrong" part of the
RFC may cut off your options later, but that's part of being
an informed consumer (i.e., buying what you asked for, not 
just what you meant to ask for).

	Walt (Lazear@gateway.mitre.org)

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 14:57:24 GMT
From:      stine@SPARTA.COM (Robert Havens Stine)
To:        comp.protocols.tcp-ip
Subject:   Re: Multihoming

Enough of this practical, reality-based stuff! :-)

Addresses are identifiers that are used to label where messages can be
sent or received.  An IP address identifies a host's network
interface.  A host may have several network interfaces.

Like IP addresses, host names are identifiers.  They are used to label
(surprise!) hosts.  A host may have several host names.

To use a network, a mapping must be made from host name to IP
address(es).  Hence the DNS.

But, as has been amply testified, there is no need for a one-to-one
mapping between the names of a host and the IP addresses of its
interfaces.

- Bob Stine

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 14:58:19 GMT
From:      bin@primate.wisc.edu (Brain in Neutral)
To:        comp.protocols.tcp-ip
Subject:   Re: Source for ftp for Ultrix (LONG)

If you're running pre-3.0 Ultrix, you'll have to play some netdb.h
and arpa/inet.h tricks to get the sources to even compile, much less
run...but it's certainly doable.

Paul DuBois
dubois@primate.wisc.edu

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 15:13:48 GMT
From:      AVL@MATH.AMS.COM (Al Lazzareschi)
To:        comp.protocols.tcp-ip
Subject:   Thin or Thick

While we are on the subject would someone like to comment on
the difference between RG58 and RG59 thinwire?

Can you mix them or should you use just one type?


Allan Lazzareschi                    American Mathematical Society
Technical Specialist                 P O Box 6248
AVL@MATH.AMS.COM                     Providence, R.I. 02940
                                     (401)272-9500  x272

-------

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 15:37:47 GMT
From:      rogers@OSI540SN.GSFC.NASA.GOV (Scott W. Rogers)
To:        comp.protocols.tcp-ip
Subject:   Re:  Source for ftp for Ultrix

FTP source code is available from berkeley and on-line on
uunet.uu.net.  This includes both ftpd and ftp.  This code
will compile as is under Ultrix 3.0 and with some tinkering on Ultrix
2.3.
				Rogers@osi540sn.gsfc.nasa.gov
				Scott W. Rogers
				Computer Scieces Corp/NASA Code 540

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 17:35:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Hanging connections

I wonder if you are running into a large packet fragmentation
problem? If something is being fragmented and not reassembled
along the path of routers/gateways your traffic is going, the
TCP connection would get stuck.

Vint Cerf

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 17:52:40 GMT
From:      russ@cipher.UUCP (Russ Harvey)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP (the company, not the protocol) required

In article <39700@bu-cs.BU.EDU> madd@cs.bu.edu (Jim Frost) writes:
>In article <46653@bbn.COM> wbe@BBN.COM (Winston Edmond) writes:
>|Try:	FTP Software, Inc.
>|	501 Cambridge St.
>|	Cambridge, MA  02141
>|	(U.S.) 617-868-4878 [phone]
>
>They have moved, although I would be surprised if you couldn't find
>out to where by either mailing or calling the old address/number.
>Sorry but I don't have the new address.

The information I have:

	FTP Software, Inc.
	26 Princess Street
	Wakefield, MA 01880
	Phone: (617) 246-0900
	Fax: (617) 246-0901
	Internet: info@ftp.com
--
uunet!cipher!russ

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Oct 89 01:10 PDT
From:      Michael Stein                        <CSYSMAS@OAC.UCLA.EDU>
To:        tcp-ip@NIC.DDN.MIL
Cc:        shlump.nac.dec.com!michaud@DECUAC.DEC.COM(Jeff Michaud)
Subject:   Re: rwho'ing (and other broadcasting...)
First I have to admit that I'm scared of broadcasts, especially
ones which are automatic.  I keep seeing a "bridged" campus
wide LAN (token ring, eventually FDDI?) with 30k+ machines.

If each has a Rwhod which outputs 1 broadcast UDP packet
every 30 seconds then there will be 1000 packets/seconds
which EVERY host will receive and have to deal with.

  ** as far as I can see BROADCAST's don't scale up **
   (can you see a world wide network doing this too?)

I kind of like the proposal by Jeff Michaud:

>   A more efficient method all around would be to have a dedicated      system
>   act as a "remote who" server.  On a timer the server system (le     ts call
>   this one the master server) will send out a udp broadcast adver     tising
>   itself as a "remote who" server.  Hosts that want to advertise      who's
>   logged on the system (call these slave servers) send the info d     irectly
>   to the "remote who" server.   Clients which want info on whos l     ogged
>   in on the network asks the local slave server (who knows who th     e master
>   server is) who in turns asks the master server (or the slave se     rver
>   can store the master servers address/port away where clients ca     n use
>   it to request the info directly from the master server).

I'd only make one change -- advertise the server via some
DNS like mechanism, no broadcasts at all... (Perhaps this requires
X.500?).
-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 18:31:13 GMT
From:      pace@spectra.COM (William B. Pace)
To:        comp.protocols.tcp-ip
Subject:   Number of TCP retries

A friend is implementing TCP/IP and has a couple of simple questions
which someone out there in netland could help him with.  He has looked
through the RFC's but doesn't see his answers there.  The environment
is a common Ethernet lan.  No gateways, routers, bridges, brouters,
long-haul networks, beer, knockwurst or oompah bands are involved.

1) If a packet is not acknowledged, how many times should TCP retry
   sending the packet before giving up?

2) What is a reasonable time for a SYN packet to time out?

3) What is a reasonable fixed TCP/IP timeout for an Ethernet lan when
   you don't want to do fancy retry timing ala Karn's work?

4) When programming an Ethernet controller (e.g. Lance chip), how many
   times should the controller retransmit the packet when it detects
   collisions and other errors before giving up and reporting an error
   to the driver?

Please send responses to pace@spectra.com.  Thanks for the help.

Bill Pace
pace@spectra.com
Disclaimer:  My boss doesn't even know I exist.

"I'm not a real programmer, but I play one on T.V."

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 20:30:25 GMT
From:      mhart@NRI.RESTON.VA.US ("Monica L. Hart")
To:        comp.protocols.tcp-ip
Subject:   SNMP Internet Draft

The following document is now available for anonymous FTP from
the "Internet-Drafts:" Directory at NIC.DDN.MIL.

        Title:     "Management Information Base for Network Management 
		   of TCP/IP-based internets"
        Auther:    Marshall Rose/Nysernet
        Filename:  draft-ietf-snmp-mib2-00.txt

This document well be reviewed at an SNMP Working Group meeting 
at the University of Tennessee at Knoxville next Monday, October 16.
Please contact Marshall Rose (mrose@cheetah.nyser.net) or Jeff Case
(case@utkuxl.utk.edu) for details.

The document will also be discussed at the next IETF Meeting in Hawaii.

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 21:37:13 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-requirement RFCs

It wasn't so much that I didn't like IP Source-Routing; we do it in our PING
as a (useful) debugging tool.  The point I was trying to make was that there
were two IP options I felt were useful in day-to-day applications (Telnet,
FTP, etc.): Source Routing and IP Security.  Of the two, IP Security is
relatively easy (and small) to code (on a DOS PC).  In contrast, IP Source
Routing (loose or strict) is harder to code, hard to do a user interface
for ("telnet foo.bar.com via baz.lusing.net, bar.winning.net", maybe?),
and tremendously hard to explain to the average user:

	"Well, first you find out who is black-holing you with traceroute,
	and then you play around trying to find a gateway somewhere off to
	one side which can actually reach the place you want to go, and then
	you name that gateway in a loose source route..."

I still don't intend to hurry on Source Routing for the applications; the
amount of playing around it took me that day to find a gateway (me not being
a routing hacker) that knew where I wanted to go is not something I want
to inflict on my support people right now.  Maybe if the DNS is extended to
provide some way of querying for gateways by geographic region or the
like, but I don't know of anyone working on that.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      12 Oct 89 22:23:28 GMT
From:      almquist@JESSICA.STANFORD.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

John,
> [RFC1122/RFC1123] avoids the issue of implementations not meant to
> include all the applications mentioned, i.e., a single-user system which
> wisely makes no effort to offer SMTP service...  I can imagine a paper
> describing everything a host ought to do if it can claim to offer
> "TELNET" service, if it can claim to offer "FTP" service, etc.

	As one of the authors of the Host Requirements RFCs, I don't
think that there was ever any intention that a host would be
non-compliant simply because it didn't choose to support certain
applications.  In my opinion, a host which doesn't support email is
compliant with the SMTP requirements of RFC1122.  However, if the vendor
claims a compliant implementation of SMTP, you can expect that he will
meet the requirements put forth in the SMTP chapter (and also the
chapters describing protocols needed to support SMTP, such as TCP, DNS,
...).

> Perhaps it could also address the different protocols below IP too.

	The Host Requirements RFCs defer to the Gateway Requirements RFC
for layers below IP (since these are the same for hosts and gateways).

						Philip

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Oct 89 08:22:28 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        pace@spectra.com
Cc:        tcp-ip@sri-nic.ARPA
Subject:   re: Number of TCP retries

> A friend is implementing TCP/IP and has a couple of simple questions
> which someone out there in netland could help him with.  He has looked
> through the RFC's but doesn't see his answers there.  The environment
> is a common Ethernet lan.  No gateways, routers, bridges, brouters,
> long-haul networks, beer, knockwurst or oompah bands are involved.

Uh... first a pushy question.  Is your friend implementing TCP, or something
to run over an Ethernet?  If he's running something over an Ethernet, fine,
but don't call it TCP.  Otherwise some poor soul will try sometime later
to run it through a gateway, and will get badly flamed....

On a second point, doing the right thing (i.e. real TCP) for each question
raised, isn't very hard.  I don't know what your friend feels he's saving.

> 1) If a packet is not acknowledged, how many times should TCP retry
>    sending the packet before giving up?

    10 is a nice number, *iff* you do exponential backoff.

> 2) What is a reasonable time for a SYN packet to time out?

    start with 1/2 second or so, and exponentially back off.

> 3) What is a reasonable fixed TCP/IP timeout for an Ethernet lan when
>    you don't want to do fancy retry timing ala Karn's work?

    Phooey -- Karn's algorithm and Jacobson's algorithm are both
    very simple.  Jacobson even gives the C code in his paper.
    Furthermore, if your Ethernet saturates, fixed timeouts will
    make the situation worse....

> 4) When programming an Ethernet controller (e.g. Lance chip), how many
>    times should the controller retransmit the packet when it detects
>    collisions and other errors before giving up and reporting an error
>    to the driver?

    Dunno... any Lance experts?

Craig
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 03:04:58 GMT
From:      CMH117@PSUVM.BITNET (Charles Hannum)
To:        comp.protocols.tcp-ip
Subject:   Downloading from Simtel ...

I figured this out several weeks ago, but haven't had a chance to post it yet.
To download from Simtel20 to VM, you must do the following:

  FTP> Type I
  FTP> Quote TYPE L 8

Note: The L in the line above ***MUST*** be capitalized.  Otherwise, case does
not matter.

The problem with this is that MGET and MPUT don't work.  Tough luck.

+-------------------------------------------------------------+
| Mr. Cole's Axiom:                                           |
|    The sum of the intelligence on the planet is a constant; |
| the population is growing.                                  |
 +-------------------------------------------------------------+
| My name?  Hannum ... Charles Hannum.  You can reach me at:  |
|   Bitnet ..... CMH117@PSUVM                                 |
|                C9H@PSUECL                                   |
|   Internet ... cmh117@psuvm.psu.edu                         |
|                c9h@psuecl.psu.edu                           |
 +-------------------------------------------------------------+

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 03:33:00 GMT
From:      WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   Fax over tcp/ip

Steve,

Perhaps it would be reasonable to pre-ftp compress, post-ftp
uncompress these files?  Always send out out compressed files and toss
received files which won't uncompress with a rejection notice.

--Frank

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Oct 89 09:13:45 EDT
From:      stine@sparta.com (Robert Havens Stine)
To:        torben@foralie.ics.Hawaii.Edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Multihoming
   >>Addresses are identifiers that are used to label where messages can be
   >>sent or received.  An IP address identifies a host's network
   >>interface.  A host may have several network interfaces.

 >And it could even have several IP addresses on the *same* network interface....

Right.  There's a mapping between the subnet and the internet layers.
IP addresses still, in some sense, are handles for identifying
datagram sources and sinks for users of the internet service.

   >>Like IP addresses, host names are identifiers.  They are used to label
   >>(surprise!) hosts.  A host may have several host names.
   >>
   >>To use a network, a mapping must be made from host name to IP
   >>address(es).  Hence the DNS.

 >This is news to me at least. It is my understanding that if you use the
 >DNS, there can only be one host name. CNAMES records of course, but only
 >one ``true" name...

Jeez! What are the other "untrue" names? Meaningless scribbles?
Mispronunciations?

Of course there are varieties of names, some of which may be special
in some way.  DNS provides a mapping between names and addresses.

- Bob


-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 06:01:36 GMT
From:      philf@xymox.metaphor.com (Phil Fernandez)
To:        comp.protocols.tcp-ip
Subject:   Re: ether collision backoff

In article <14015@well.UUCP> nagle@well.UUCP (John Nagle) writes:
> (...re. collision backoff pros and cons)
>      General advice: DON'T DO THIS unless you can establish by both
>mathematical calculation and tests on large networks that you are not
>introducing instability...

This general area has been a topic of much conversation around
Metaphor lately, where we're looking to some excessive collision
problems.  Let me ask:

Just how does one change the Ethernet backoff algorithm when it's
implemented completely within an IC such as the AMD Lance?  Sun, for
example, uses the Lance on their desktop workstations, and I don't
know how they might have changed the backoff scheme even if they
wanted to.

How often does one even get the opportunity to reimplement this
algorithm these days?

pmf


+-----------------------------+----------------------------------------------+
| Phil Fernandez              |             philf@metaphor.com               |
|                             |     ...!{apple|decwrl}!metaphor!philf        |
| Metaphor Computer Systems   |"Does the body rule the mind, or does the mind|
| Mountain View, CA           | rule the body?  I dunno..." - Morrissey      |
+-----------------------------+----------------------------------------------+

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Oct 89 12:13:57 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: FAX over TCP/IP
Considering the fact that we can already Email graphic images over TCP/IP,
why would anyone want to step backwards to low resolution black&white FAX
pictures???

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 08:10:00 GMT
From:      CSYSMAS@OAC.UCLA.EDU (Michael Stein)
To:        comp.protocols.tcp-ip
Subject:   Re: rwho'ing (and other broadcasting...)

First I have to admit that I'm scared of broadcasts, especially
ones which are automatic.  I keep seeing a "bridged" campus
wide LAN (token ring, eventually FDDI?) with 30k+ machines.

If each has a Rwhod which outputs 1 broadcast UDP packet
every 30 seconds then there will be 1000 packets/seconds
which EVERY host will receive and have to deal with.

  ** as far as I can see BROADCAST's don't scale up **
   (can you see a world wide network doing this too?)

I kind of like the proposal by Jeff Michaud:

>   A more efficient method all around would be to have a dedicated      system
>   act as a "remote who" server.  On a timer the server system (le     ts call
>   this one the master server) will send out a udp broadcast adver     tising
>   itself as a "remote who" server.  Hosts that want to advertise      who's
>   logged on the system (call these slave servers) send the info d     irectly
>   to the "remote who" server.   Clients which want info on whos l     ogged
>   in on the network asks the local slave server (who knows who th     e master
>   server is) who in turns asks the master server (or the slave se     rver
>   can store the master servers address/port away where clients ca     n use
>   it to request the info directly from the master server).

I'd only make one change -- advertise the server via some
DNS like mechanism, no broadcasts at all... (Perhaps this requires
X.500?).

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 11:15:14 GMT
From:      VSBENZI@WEIZMANN.BITNET (Benzi mizrahi)
To:        comp.protocols.tcp-ip
Subject:   CNAME question

Hello all,

 we have a name server that is primary to our local zone and sub-zone
 within our local zone. Can I have CNAME RR in the upper zone that
 his owner name is the same as the sub-zone? Consider the following
 RRs:

 our.local.zone.  IN SOA    ....


                  IN NS     ns.our.local.zone

 ns.our.local.zone. IN A     <ip.addr>

 ...

 sub-zone.our.local.zone.   IN CNAME  sub-zone.sub-zone.our.local.zone.

 ...
 ;
 ;End of parent zone
 ;

 sub-zone.our.local.zone. IN  SOA ...


                          IN  NS ns.our.local.zone

 ...

 sub-zone.sub-zone.our.local.zone. IN A  <his.ip.addr>

 ...
 ;
 ; End of sub-zone
 ;

 Is this a protocol error? thanx , Benzi

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 12:08:19 GMT
From:      almes@RICE.EDU (Guy Almes)
To:        comp.protocols.tcp-ip
Subject:   Re: Fax over tcp/ip

Steve,
  The Internet consists of a large fabric of (increasingly) T1 leased
lines to be used in support of scholarship and research.  If we use it
to ship FAX images, and if those images support scholarship and research,
and if they comprise a small fraction of our (fixed cost) circuits, then
I don't think there would be objection.
  One positive outgrowth would be that, if this became common, then people
would start building interesting/useful tools, including:
  * compression techniques for reducing the bandwidth required,
  * more flexible inputs than simple scanners (various text or graphic
	format files as input)
  * more flexible outputs than FAX printers
besides, it might spur real use of multimedia mail if/when our multimedia
mail techniques are shown to be better.
  I'm not a fan of FAX, but it is useful at times and there is no reason
to be stuck with dial up phone lines when we do use it.
	-- Guy

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 12:22:28 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Number of TCP retries


> A friend is implementing TCP/IP and has a couple of simple questions
> which someone out there in netland could help him with.  He has looked
> through the RFC's but doesn't see his answers there.  The environment
> is a common Ethernet lan.  No gateways, routers, bridges, brouters,
> long-haul networks, beer, knockwurst or oompah bands are involved.

Uh... first a pushy question.  Is your friend implementing TCP, or something
to run over an Ethernet?  If he's running something over an Ethernet, fine,
but don't call it TCP.  Otherwise some poor soul will try sometime later
to run it through a gateway, and will get badly flamed....

On a second point, doing the right thing (i.e. real TCP) for each question
raised, isn't very hard.  I don't know what your friend feels he's saving.

> 1) If a packet is not acknowledged, how many times should TCP retry
>    sending the packet before giving up?

    10 is a nice number, *iff* you do exponential backoff.

> 2) What is a reasonable time for a SYN packet to time out?

    start with 1/2 second or so, and exponentially back off.

> 3) What is a reasonable fixed TCP/IP timeout for an Ethernet lan when
>    you don't want to do fancy retry timing ala Karn's work?

    Phooey -- Karn's algorithm and Jacobson's algorithm are both
    very simple.  Jacobson even gives the C code in his paper.
    Furthermore, if your Ethernet saturates, fixed timeouts will
    make the situation worse....

> 4) When programming an Ethernet controller (e.g. Lance chip), how many
>    times should the controller retransmit the packet when it detects
>    collisions and other errors before giving up and reporting an error
>    to the driver?

    Dunno... any Lance experts?

Craig

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 12:33:43 GMT
From:      eli@URSA-MAJOR.SPDCC.COM
To:        comp.protocols.tcp-ip
Subject:   fax over tcp/ip


hello Frank,

group 3 fax files are already compressed by both run length and
huffman coding, so unix LZ compression isn't apt to provide much
more compression...

steve



------- Forwarded Message

In-Reply-To: Msg of 11 Oct 1989  07:53-MDT from spdcc!eli at bloom-beacon.mit.edu (Steve Elias)

Steve,

Perhaps it would be reasonable to pre-ftp compress, post-ftp
uncompress these files?  Always send out out compressed files and toss
received files which won't uncompress with a rejection notice.

- --Frank

------- End of Forwarded Message

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 12:56:53 GMT
From:      mep@AQUA.WHOI.EDU (Michael E. Pare)
To:        comp.protocols.tcp-ip
Subject:   Re:  Thin or Thick

>...difference between RG58 and RG59 thinwire?

RG58 is based on a nominal impedence of 50 ohms and can range from 50 to 53
ohms.  To use it for thinnet applications you need to ensure the type you
buy is rated at 50 ohms.  RG59 is based on a nominal impedence of 75 ohms
and is more often used for CATV (broadband) applications.  The two should
never be mixed.  

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 13:07:46 GMT
From:      awaldfog@wellfleet.com (Asher Waldfogel)
To:        comp.protocols.tcp-ip
Subject:   Re: rwho'ing (and other broadcasting...)

It is certainly true that "global" broadcasts don't scale well.  But
broadcasts (and multicasts) are very useful within "local" LAN
domains.  I also agree with the direction of your idea for rwho
services.  But I think the real bug in scaling is building a bridged
network with 30K+ nodes.  To scale to that size you need to route.

More importantly, I'm not sure we should worry too much about 
"local" protocols such as rwho scaling into overgrown bridged 
environments. 

Asher Waldfogel
Wellfleet Communications

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 13:49:32 GMT
From:      spe@cbnews.ATT.COM (Scott P. Elliott)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   SLIP for System V Rel 3 with STREAMS.

I'm looking for a version of SLIP that's been ported to the System V Release
3 UNIX* O.S. using STREAMS.  It should also work with the WIN/3B networking
package.  If anyone has any information, please send me e-mail.  Thanks.

-----
*UNIX is a registered trademark of AT&T.
-- 
Scott Elliott
spe%cbqss1@att.com
att!cbqss1!spe

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 14:48:10 GMT
From:      bob@JVNCB.CSC.ORG (Bob Albrightson)
To:        comp.protocols.tcp-ip
Subject:   Re: Thin or Thick

> While we are on the subject would someone like to comment on
> the difference between RG58 and RG59 thinwire?
> 
> Can you mix them or should you use just one type?

No.  RG58 is 50 ohms and RG59 is 75 ohms.  You don't want to use RG59 at
all in an ethernet installation.  ( I assume that you are refering to 
ethernet ).

 -bob

-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 15:11:23 GMT
From:      solensky@interlan.interlan.COM (Frank Solensky)
To:        comp.protocols.tcp-ip
Subject:   Re:  What happens when TCP sequence numbers wrap?

In <ADNAN.89Oct12083745@sgtech.UUCP>, Adnan Yaqub asks:
	
	I was looking over the Berkeley TCP code and began to wonder what
	happens when TCP sequence numbers wrap.  In the tcp_input routine
	duplicate acks are detected by the check (after macro expansion):
		(int) (segment ack - last unacknowledged) <= 0
	It seems to me that if I send a message which ends at, say, sequence
	number (2**32)-1, then when the ack arrives (which would be 0) I would
	reject it as a duplicate.
	
	Is this comething which is not worried about, or am I missing
	something?

The only difference between "signed" and "unsigned" integers is how the values
will be interpreted once they are at or above 2**(N-1), where N represents the
integer length on your machine.  The large unsigned positive value in your
"last acknowledged" can also be thought of as a large signed negative, as the
casting of the result will do.

Say the last ack is (2**32)-100.  That will be stored the same way as the
value -100.  The expression becomes (int)(0 - (-100)) == (int)(0+100) = 100.
So the ack isn't tossed.
						-- Frank Solensky
						   Racal InterLan

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 16:34:28 GMT
From:      desnoyer@apple.com (Peter Desnoyers)
To:        comp.protocols.tcp-ip
Subject:   Re: Number of TCP retries

In article <242@spectra.COM> pace@spectra.COM (William B. Pace) writes:
> 4) When programming an Ethernet controller (e.g. Lance chip), how many
>    times should the controller retransmit the packet when it detects
>    collisions and other errors before giving up and reporting an error
>    to the driver?

I believe the retransmission you are talking about is part of the Ethernet 
spec. I seem to recall that it is something like 10 times with (random) 
binary exponential back-off, and another 6 at the maximum random back-off, 
and then report an error. 

Check the spec - this is essential to the correct operation of the 
Ethernet protocol. With linear backoff, the protocol is unstable and 
vulnerable to congestion collapse. With exponential backoff but off by 
some factor from the spec you could get squeezed out or hog the bus.

                                      Peter Desnoyers
                                      Apple ATG
                                      (408) 974-4469

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Fri, 13 Oct 89 13:15:14 +0200
From:      Benzi mizrahi <VSBENZI%WEIZMANN.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@sri-nic.arpa
Subject:   CNAME question
Hello all,

 we have a name server that is primary to our local zone and sub-zone
 within our local zone. Can I have CNAME RR in the upper zone that
 his owner name is the same as the sub-zone? Consider the following
 RRs:

 our.local.zone.  IN SOA    ....


                  IN NS     ns.our.local.zone

 ns.our.local.zone. IN A     <ip.addr>

 ...

 sub-zone.our.local.zone.   IN CNAME  sub-zone.sub-zone.our.local.zone.

 ...
 ;
 ;End of parent zone
 ;

 sub-zone.our.local.zone. IN  SOA ...


                          IN  NS ns.our.local.zone

 ...

 sub-zone.sub-zone.our.local.zone. IN A  <his.ip.addr>

 ...
 ;
 ; End of sub-zone
 ;

 Is this a protocol error? thanx , Benzi
-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 16:47:38 GMT
From:      baker@VITAM6.UUCP (Fred Baker)
To:        comp.protocols.tcp-ip
Subject:   Ethernet Retransmissions

The following is from IEEE 802.3 section 4.4.2.1. Ethernet V1 and V2 make
similar statements.  the 'attemptLimit' is 16, which on the LANCE especially
and I believe also the 825X6 is implemented in silicon.  You try 10 times,
increasing the backoff each time, try five times using the same maximum
backoff, and then QUIT.  the chips also give you some rudimentary TDR data
upon an access failure.

Our experience: if you see 16 successive collisions on the same message,
you will see 16 gazillion if you keep trying.  The net is broken, go fix it.

Fred Baker
baker@vitalink.com

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 17:06:01 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: What happens when TCP sequence numbers wrap.

If your developer has been careful to test for the cases, and does the
compares right, everything works fine across both 0x7FFFFFFF ->
0x80000000 and 0xFFFFFFFF -> 0x00000000.  I've never seen Berkeley or
Sun TCP source code, but I know for sure that a Sun 386i running SunOS
4.0.1 does not handle the second case right.  I know for sure that our
TCP does.  The wrap case does matter, just leave a system monitor
running on a telnet or X connection for a while (depends on what
initial sequence number you get at open timethe fiorst time I tried it
took a weekend) and use a LAN monitor to watch the Sun ignore acks
after the boundary is reached...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 17:13:57 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re: FAX over TCP/IP

Considering the fact that we can already Email graphic images over TCP/IP,
why would anyone want to step backwards to low resolution black&white FAX
pictures???

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 18:15:53 GMT
From:      pat@hprnd.HP.COM (Pat Thaler)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: Thinwire vs. Thickwire (Why 30 nodes only on thin?)

> / hprnd:comp.protocols.tcp-ip / kratz@bnrgate.bnr.ca (Geoff Kratz) / 11:11 am  Oct  1, 1989 /
> In article <8909291306.AA06775@jvnca.csc.org>, aggarwal@JVNCA.CSC.ORG (Vikas Aggarwal none) writes:
> > 
> > Just to collect one's views on Thinwire ethernet vs Thickwire ethernet,
> 
> What about Unshielded Twisted Pair (UTP)?  We are using this exclusively 
> now, and we have found a number of advantages:
> 
>     - extremely cheap (uses existing 4-wire in the building)
>     - MAUs cost much less than transceivers
>     - You can use the BIXX cross-connects to simplify moves of workstations
>       (a move requires moving jumper wires from one cross-connect to another)
> 
> The disadvantage, of course, is the distance.  UTP is only good to about 
> 400 meters.  Within a building, though, this is usually adequate.  Another 

The design goal for 10BASE-T is 100 m on 24 AWG UTP.  400 meters is 
excessive.
> thing is the tolerance on the clock crystals.  We found a number of 
> workstation manufacturers who's specs on the clock were less than adequate, 
> thus causing a lot of jams or CRC's.  However, for our site (1000+ 

The clock problem has to do with the effect of excessive clock skew on
repeaters, not with any characteristic of twisted pair vs coax (except that
with coax you may not have had to have a repeater between your nodes).  
Repeaters decode the incoming signal and reencode it with their internal
clock in order to remove jitter.  The clocks of the sending DTE and the
repeater may be slightly different, but the must be within 10 MHz +- 0.01%
to meet the spec.  A device with a fast clock can transmit a maximum length
packet in about 300 ns faster than a device with a slow clock.  To allow
for this skew, a repeater stores at least 3 bits in its FIFO before it
starts transmitting (so it won't run out of bits if it is fast) and 
has space for at least 3 more bits to accumulate (so it won't drop
bits if it is slow).  If clock frequency is out of spec then packets
can get corrupted.  

Since people switch from a small unrepeatered coax network to a twisted
pair network, they discover the problem when the repeater is inserted.

> workstations in 5 buildings with constant workstation moves), UTP gives us 
> more benefits in topology planning, installation and $$$.
> 
> And yes, we run at full ethernet (10 Mbps).
> 
> Anyone else out there using UTP for their ethernets?
> -- 
> Geoff Kratz         Bell-Northern Research, Ltd.    Ph: (613) 763-5784
> Internet Systems      P.O. Box 3511, Station C      FAX:(613) 763-3283
>                     Ottawa Ontario Canada K1Y 4H7
> BITNET: kratz@bnr.ca
> ----------

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 18:57:51 GMT
From:      Clifford Collins <COLLINS-C@OSU-20.IRCC.OHIO-STATE.EDU>
To:        comp.protocols.tcp-ip
Subject:   Encrypted SMTP Mail?

I recently saw copies of RFC1113, 1114 and 1115 that address
encrypted SMTP mail.  Are there any implementations out there?
I would be very interested in acquiring what's out there to test
and evaluate.  Any leads would be welcome. Please reply to me
via e-mail.  Thanks!

Clifford A. Collins            collins-c@osu-20.ircc.ohio-state.edu
The Ohio State University    Instruction & Research Computer Center
-------

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 19:14:14 GMT
From:      pat@hprnd.HP.COM (Pat Thaler)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: Thinwire vs. Thickwire (Why 30 nodes only on thin?)

> / hprnd:comp.protocols.tcp-ip / glen@aecom.yu.edu (Glen M. Marianko) /  6:01 pm  Oct  7, 1989 /
> In article <8909291306.AA06775@jvnca.csc.org>, aggarwal@JVNCA.CSC.ORG (Vikas Aggarwal none) writes:
> > 
> > Just to collect one's views on Thinwire ethernet vs Thickwire ethernet,
> > I am listing what I know about the topic:
> > 
> > THINWIRE
> > ...
> > 	Max segment length - 185 meters (30 nodes per segment)
> 
> This posting reminded me of a question I had about thin ethernet and
> the 30 nodes per segment limit.  Why is this?  I thought on thin
> ethernet you can have a node every .5 meters (vs. thick which is
> marked for much more).  If so, then 185/.5=370 according to my
> calculator with the weak battery :-).  So why couldn't I have more
> than 30 workstations?    Tell ya, the only place I ever saw this in
> print was in a DEC catalog.  Maybe this is a DEC restriction?
> -- 
It comes from the IEEE 802.3 10BASE2 standard. It is actually 30 MAUs
per segment that is important, not how many stations are attached to 
those MAUs.  It is due to the effect of the MAU (leakage current,
loading, etc.) and the effect of the connectors used to attach the MAU
on the media.  The spacing requirement is to ensure you don't have a bunch
of MAUs clustered right together as that can lead to a larger reflection.
MAUs can be closer together on thin than on thick for two reasons: 1) the
attenuation of thin is higher (part of the reason it only goes 185 m);
and 2) the number of MAUs is smaller on thin 30 vs. 100.

> -- Glen M. Marianko  Manager, LAN Services  Glasgal Communications, Inc.
>    151 Veterans Drive  Northvale, New Jersey 07647  201-768-8082
>    glen@aecom.yu.edu - {uunet}!aecom!glen (Courtesy of AECOM & unaffiliated)
> ----------
Pat Thaler

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 19:23:32 GMT
From:      mhw@wittsend.lbp.harris.com (Michael H. Warfield (Mike))
To:        comp.protocols.tcp-ip
Subject:   Re: Thin or Thick

In article <624204828.0.AVL@MATH.AMS.COM> AVL@MATH.AMS.COM (Al Lazzareschi) writes:
>While we are on the subject would someone like to comment on
>the difference between RG58 and RG59 thinwire?

	RG58 is 50 ohms impedance.  That is what is generally used for
"Thinwire ethernet".  RG59 is 75 ohm cable and CANNOT be used for ethernet.
I understand some people may have gotten away with it bu their transcievers
must be extremely forgiving (most are not).  In any case, if it works at all
it is WAY out of spec.  IEEE spec is 50 ohms +- 1%.

>Can you mix them or should you use just one type?

	Don't mix.  Only use RG58.

Michael H. Warfield  (The Mad Wizard)	| gatech.edu!galbp!wittsend!mhw
  (404)  270-2123 / 270-2098		| mhw@wittsend.LBP.HARRIS.COM
An optimist believes we live in the best of all possible worlds.
A pessimist is sure of it!

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 22:00:41 GMT
From:      BILLW@MATHOM.CISCO.COM (William Westfield)
To:        comp.protocols.tcp-ip
Subject:   Re: Number of TCP retries


    The environment is a common Ethernet lan.  No gateways, routers,
    bridges, brouters, long-haul networks, etc,  are involved.

No. No.  Please do NOT make any assumptions about the environment
a TCP will be located in.  I can't tell you how many problems
assumptions like this have caused (they always end up used in an
environment other than the one they were designed for originally.


    1) If a packet is not acknowledged, how many times should TCP
       retry sending the packet before giving up?

Well, one philosophy says "forever", which is to say that this should
be controlled by the application, rather than by TCP. If the application
is telnet, you let the user decide when to abort.  If it is something
like mail, the application might abort after several minutes.


    2) What is a reasonable time for a SYN packet to time out?

0.5 seconds, with exponential backoff and retransmission, with a total
timeout of 30 seconds or so.  The exponential backoff is real important
here.  The short initial retransmission will let ARP drop packets.


    3) What is a reasonable fixed TCP/IP timeout for an Ethernet lan when
       you don't want to do fancy retry timing ala Karn's work?

Never use a fixed timeout.  An exponential timeout is easy to implement.
Even Karn/Jacobson algorithms, although "fancy" turn out to be
wonderfully uncomplicated to implement.


    4) When programming an Ethernet controller (e.g. Lance chip), how many
       times should the controller retransmit the packet when it detects
       collisions and other errors before giving up and reporting an error
       to the driver?

This is fixed by the ethernet spec, and usually by the ethernet
controller.  It is 16 times total.  The LANCE does not permit you
to change this number, although some other controllers might.

Bill Westfield
cisco Systems.
-------

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      13 Oct 89 23:51:18 GMT
From:      nowicki@ENG.SUN.COM (Bill Nowicki)
To:        comp.protocols.tcp-ip
Subject:   Re: ether collision backoff


	From: nagle@well.UUCP (John Nagle)
	Subject: Re: ether collision backoff
	Date: 9 Oct 89 16:53:56 GMT
	References: <42686@sgi.sgi.com>

	Back in 1984, somebody at Sun turned down the retransmit delay
	in 4.2BSD's TCP, apparently hoping to "improve performance".
	The resulting mess caused trouble in the Internet for years.

The above is **NOT TRUE**.  For some reason our competitors are always
starting such false rumors.  The truth is that Sun just ported 4.2BSD,
like many other vendors.  Sun just happened to have faster hardware
than most of the others.

The 4.2BSD TCP implementors did not give much thought to the dynamics
of retransmission timers, as everybody should know by now who has read
any recent papers on the subject.  Some work was done at Berkeley to
improve this in the 4.3BSD project, which Sun incorporated into the
SunOS 3.4 release, and even more work was done for the "4.3BSD Tahoe"
release on congestion control that was included in SunOS 4.0.

I could certainly believe that Sun might have subtle bugs in one of its
Ethernet implementations.  These are not intentional.  Please report
any known violations of the spec to the vendor through the appropriate
customer support channels.  Spreading rumors is a bad idea; if it is
broken, get the vendor to fix it!

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 89 00:25:24 GMT
From:      hd@kappa.rice.edu (Hubert D.)
To:        comp.protocols.tcp-ip
Subject:   Re: Fax over tcp/ip

I suggest using the CCITT group 4 document transmition standard instead
of the CCITT group 3 specification which is used over the phone lines.  The
group 4 spec uses ONE compression table for the entire file; group 3
uses a compression table for EVERY line.  The internetwork is a much
more reliable medium than the telephone lines.  So, a protocol which
suits the medium should be used

--==--
Hubert Daugherty             Department of Electrical and Computer Engineering
hd@rice.edu                                   Rice University
(713) 527-4035                               Houston, TX 77252

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 89 00:42:41 GMT
From:      karl@asylum.SF.CA.US (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: Thin or Thick

In article <624204828.0.AVL@MATH.AMS.COM> AVL@MATH.AMS.COM (Al Lazzareschi) writes:
>While we are on the subject would someone like to comment on
>the difference between RG58 and RG59 thinwire?

I was one of the folks who installed the network at Interop last week.
We had lots of thick, thin, and this year, unshielded twisted pair
(not to mention non-ethers such as fddi, IBM type 1 [for token ring],
etc).

Clearly, thin ether is easier to handle than thick, but its run length
is more limited.  It's a mild pain to attach end-connectors on either
type, but you need more of 'em on cheapernet (thin).  I've never had
noise problems with either, but I've had more shorts with thin than
with thick.  

But compared to thin and thick -- twisted pair is wonderful -- once
you get the connectors right.  Modular jacks don't fall out like those
hideous AUI connectors [even when the slide locks work], a mere mortal
can carry the wire, and you don't have to be a Vanderbilt to pay for
it.  You *do* end up with a star (or star of star, or spine and ribs)
shaped network, with sometimes more total cable.  But with the right
kind of wiring discipline (using all those things that the phone
companies invented when they were in the telephone business -- like
punch down blocks and wire closets) twisted pair can make life much
easier and potentially less expensive.

				--karl--

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 89 00:50:45 GMT
From:      karl@asylum.SF.CA.US (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: Fax over tcp/ip

In article <8910131208.AA18264@iapetus.rice.edu> almes@RICE.EDU (Guy Almes) writes:
>Steve,
>  The Internet consists of a large fabric of (increasingly) T1 leased
>lines to be used in support of scholarship and research.  If we use it
>to ship FAX images

The X.400 mail system can take fax images, both group 3 and group 4
(as well as voice, executables, ... and even ASCII text).

(For the TCP/IP "purist" [such a euphamism!], X.400 could be
considered a child of the TCP/IP community as it came from IFIP WG6.5
before ISO/OSI got 'hold of it.)

Marshall Rose has demonstrated that X.400 can work over TCP/IP.

We ought to avoid inventing yet another protocol just to handle FAX.

				--karl--

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 89 02:32:21 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip
Subject:   email to fax, fax to email

In article <2078@brazos.Rice.edu> hd@rice.edu (Hubert D.) writes:
>I suggest using the CCITT group 4 document transmition standard instead
>of the CCITT group 3 specification which is used over the phone lines.  The
>group 4 spec uses ONE compression table for the entire file; group 3
>uses a compression table for EVERY line.  The internetwork is a much
>more reliable medium than the telephone lines.  So, a protocol which
>suits the medium should be used

	sure enough, group 4 would result in smaller files zipping
	around the internet.  i have no experience with group 4, but
	i'd guess the files would still be 20k to 50k per page...

	unfortunately for internet bandwidth, group 3 is where it's at.
	the installed base of group 3 computerfax hardware is growing
	very rapidly.  there is no inexpensive group 4 hardare, eh?

	by the way, if anyone would like to actually receive a group 3
	fax file via the internet, i'd be happy to mail along copies
	of an obscure (funny) photo from an upstate new york fishing
	journal, or a fax of my siamese cat's face (catfax).  public
	domain fax display software is available courtesy of "well!pokey".

	it should soon be appearing in a comp.sources newsgroup near you...









-- 
 ... Steve Elias (eli@spdcc.com);6178906844;6179325598; {}
 /* free email2fax!  send email for info. */
 /* be rude to a headhunter today and win free prizes! */

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 89 07:07:39 GMT
From:      sl@van-bc.UUCP (Stuart Lynne)
To:        comp.protocols.tcp-ip
Subject:   Re: Fax over tcp/ip

In article <2078@brazos.Rice.edu> hd@rice.edu (Hubert D.) writes:
>I suggest using the CCITT group 4 document transmition standard instead
>of the CCITT group 3 specification which is used over the phone lines.  The
>group 4 spec uses ONE compression table for the entire file; group 3
>uses a compression table for EVERY line.  The internetwork is a much
>more reliable medium than the telephone lines.  So, a protocol which
>suits the medium should be used

The problem is not so much that you want to choose *ONE* bit encoding spec,
but that you are probably going to have to support several.

There is a basic tradeoff to make. If we choose one standard (eg G3 or G4)
then you will have to convert whatever you have to that standard. This
involves CPU cycles. If you allow multiple standards (ie G3 and G4) then all
sites will have to support multiple formats, but you won't have to convert
from what you have to a standard format if the other end does understand
what you already have. This may involve extra communications bandwidth but
may conserve CPU cycles at each end.

I would suspect that if a fax transfer standard is implemented it should 
involve a handshake at the beginning where each end tells the other what 
it understands. Then if you have a format which the other end doesn't 
understand you know you have to convert before sending otherwise you just 
send it.

We store fax images in TIFF files and support G3, packbits, Lempel-Ziv and
will be doing G4 shortly. Right now we're leaning towards Lempel-Ziv. It 
gives similiar compression ratio's to G3 and is much faster to do (ie less 
CPU cycles). For colour images it's better than G3.

-- 
Stuart.Lynne@wimsey.bc.ca ubc-cs!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 89 13:15:39 GMT
From:      sscott@camdev.UUCP (Steve Scott)
To:        comp.protocols.tcp-ip
Subject:   Need help with IBM TCP sw and UB board

To IBM TCP (on MSDOSmachines) users in USENETland


I have installed IBM Transmission Control Protocol
for the Personal System/2 Computer software into
a Model 30 (the 8086 type) w/ a UB 2261A Ethernet board.
I am using a Micom transceiver

It doesn't work (yet)

I have "ohmed out" the thinlan coax, the transceiver
(and the AUI cable) is new

The LOADNIU.EXE utility that comes with the board
says that it passes diagnostics

The board is set for interrupt 2 and shared memory
space at $D0000.  I have set DMA settings to 0 
(which means that DMA doesn't exist, I think).

I have used the custom.exe program (which allows the 
IBM software to match the particular HW setting) 
to match these settings but to no avail

I have also tried different memory locations with
still no luck.  Should I try a different I/O block
of addresses (I think there is only two to choose
from)

My signature is at the bottom.  (I have turned debug
on and nothing looks bad EXCEPT that the software tells
me that it thinks that its ethernet address is
00.00.00.00.00.00.  Is this right?  Is this a backwards
broadcast address?).  I also think that the machine
should be able to ping itself (but it won't)

I have installed/configured 802.3 hw/sw in multi and
various flavors of *nix machines but this is the first
time for a PC

Anyway, any help would be appreciated


-- 
Steve Scott            UUCP: {attctc|texbell|texsun}!csccat!camdev!sscott
Motorola, Inc.         Telephone : 1-817-232-6317

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 89 14:12:07 GMT
From:      rhg@cpsolv.UUCP (Richard H. Gumpertz)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP & NFS for Altos

Does anybody know of a TCP/IP (and NFS too, maybe) implementation for the old
Altos 80286-based Xenix 3 machines (Altos models 1086, 2086, 3086)?  I know of
a company that wants to put about a dozen of them on a TCP/IP Ethernet.  Note
that the Xenix is Altos' own port, not SCO's.  I suppose it may be similar
enough, however, to allow some software reuse.

Any pointers?  Even Altos hasn't offered any solid suggestions!

Since my news feed is a bit spotty, please reply via email.
-- 
==========================================================================
| Richard H. Gumpertz    rhg@cpsolv.UUCP -or- ...uunet!amgraf!cpsolv!rhg |
| Computer Problem Solving, 8905 Mohawk Lane, Leawood, Kansas 66206-1749 |
==========================================================================

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 89 18:23:38 GMT
From:      rick@UUNET.UU.NET (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs


	and will not as long as I manage their mail systems.  The "% hack"
	is ugly, difficult to parse correctly at Internet--othernet gateways,
	and not needed.

Funny, thats exactly how I (and lots of others) have been describing
the rfc822 source routing. I assure you that the rfc822 source routing
is MUCH more difficult to parse that the % hack.

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      14 Oct 89 21:45:03 GMT
From:      root@netdev.UUCP (Alex Huppenthal)
To:        comp.protocols.tcp-ip,comp.sys.att
Subject:   Re: SLIP for System V Rel 3 with STREAMS.

In article <10197@cbnews.ATT.COM> spe@cbnews.ATT.COM (Scott P. Elliott) writes:
>I'm looking for a version of SLIP that's been ported to the System V Release
>3 UNIX* O.S. using STREAMS.  It should also work with the WIN/3B networking


Please post the results of this query. We are setting up Unix SV 3.2 systems
and need SLIP / Streams as well.

-Alex


-- 
Communication Systems Research         (   Without Dr. Pepper......        )
SNAIL:  6045 Buffridge Tr, Dallas, TX 75252  (     what are we, really?  )
INTERNET:  alex@comsys.com      UUCP:  { texbell }!netdev!alex 

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 89 00:53:47 GMT
From:      maa@ssc-vax.UUCP (Mark A Allyn)
To:        comp.protocols.tcp-ip
Subject:   tcp-ip software

I understand that the source code for the tcp-ip low level software
is available on public domain. I was also told that I could get
it somehow over the internet

Can anyone tell me if this is true and if so, what the host
is and its internet address??

Thanks
Mark Allyn
uw-beaver!ssc-vax!ssc-bee!maa

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 89 05:47:06 GMT
From:      estrin@USC.EDU (Deborah Estrin)
To:        comp.protocols.tcp-ip
Subject:   Call for Papers--Journal of Internetworking


          Advanced Announcement and Call For Papers

                Journal of Internetworking

                  Research and Experience


                       Aims and Scope

      Designing and implementing communication protocols that
 enable  heterogeneous  computer  systems  to interoperate is
 extremely difficult.  The  demand  for  such  protocols  has
 risen sharply as users have begun to connect diverse systems
 together.  For example, the federally-supported Internet  in
 the US has grown from a few dozen research institutions into
 a worldwide network connecting tens of thousands of  comput-
 ers  and  hundreds of thousands of users.  At the same time,
 the international community is developing standards for open
 system interconnection (OSI).

      Much of the recent work in internet protocols has  been
 of an experimental or practical nature using the Internet as
 an experimental facility.  As  new  international  standards
 arise,  there  will  be more implementation and experimental
 efforts.  The results of this work have been  reported  pri-
 marily  in  technical  reports, RFCs, and various conference
 proceedings.  No journal  concentrates  on  interoperability
 and internet protocols research.

      INTERNETWORKING will seek to provide a focus for origi-
 nal results of research in interoperability; a mechanism for
 quality control and verification through the refereeing pro-
 cess;  and  opportunities for comment and debate in a public
 and easily accessible forum.

      The journal will encourage  papers  on  topics  ranging
 from  architectural models to details of implementations and
 performance measurements.  The emphasis will be primarily on
 those   papers  reporting  practical  experience  gained  in
 designing, implementing or using internet  protocols.   How-
 ever,  papers  of  a more mathematical or theoretical nature
 that might contribute  to  the  development  of,  or  better
 understanding of, methods of design, construction and use of
 internetworking protocols will also be  welcomed.   Shorter,
 unrefereed notes and letters may be published if they relate
 to  current research topics or  previously  published  arti-
 cles.

      Articles may range in length from a short note (perhaps
 half  a page) to the length required to document a design in
 detail (perhaps forty pages or more).  The goal is  to  pro-
 vide  timely  dissemination  of  results while maintaining a
 thorough review process.

      INTERNETWORKING  will  provide  a  valuable  source  of
 reference  to all who design, implement or use internet pro-
 tocol software, or who want to learn more about the technol-
 ogy.  Anyone involved in the investigation of interoperabil-
 ity or the communication protocols that  support  it  should
 consider writing about their work for the journal.

 Editor-in-chief:

                Professor Douglas E. Comer
                Computer Sciences Department
                Purdue University
                West Lafayette, IN 47907
                USA

                Tel: (317) 494-6009
                comer@purdue.edu

 Editors:
                Ralph A. Droms
                Computer Science Department
                Bucknell University
                Lewisburg, PA 17837
                USA

                Tel: (703) 620-8990
                rdroms@nri.reston.va.us


                Deborah L. Estrin
                Computer Science Department
                Henry Salvatori Computer Science Center
                University of Southern California
                Los Angeles, CA  90089-0782
                USA

                Tel: (213) 743-7842
                estrin@usc.edu

      A further editor and an international  editorial  board
 are   currently  being  appointed.   Full  details  will  be
 announced prior to publication of the first issue.


 Publisher:

      John Wiley & Sons  of  Chichester   New York   Brisbane
 Toronto and Singapore.


 Call For Papers:

      Papers are solicited for the first two issues with ini-
 tial submission deadlines of December 31, 1989 and March 31,
 1990.  The first two issues will be published in 1990.


      For further details please contact one of the editors.

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 1989 10:30-EDT
From:      CERF@A.ISI.EDU
To:        daemon@TUT.CIS.OHIO-STATE.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Fax over tcp/ip
If you FAX IN to your PC, how does it figure out where to send the
file via FTP? Or convey to the far end what fax number to call
to deliver it? Or have I confused the service functionality?

Vint
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 89 14:30:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Fax over tcp/ip

If you FAX IN to your PC, how does it figure out where to send the
file via FTP? Or convey to the far end what fax number to call
to deliver it? Or have I confused the service functionality?

Vint

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 89 16:36:16 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip
Subject:   fax over tcp/ip.

In article <[A.ISI.EDU]15-Oct-89.10:30:31.CERF> CERF@A.ISI.EDU writes:
>If you FAX IN to your PC, how does it figure out where to send the
>file via FTP? Or convey to the far end what fax number to call
>to deliver it? Or have I confused the service functionality?
>
>Vint

	hi Vint!  nice rap on gigabit networking at interop!
	i surely won't complain about wasting bandwidth on fax, ok?

	the two questions...

	1 -- how to specify the destination fax number for the email2fax
	     direction?  grepping the subject line or some such scheme
	     is a simple solution.
	2 -- how to specify the destination email address from an inbound fax?
	     this is the more interesting question, i think.  

	the bruteforce way to deal with inbound faxes to standard phone
	lines on PCs or other unix systems is to have some sort of character
	recognition and a standard for where (or how) to write/print the
	destination email address...  i needn't explain the difficulties
	with such a scheme, however.  

	the reliable method is to use DID phone lines and DID capable 
	PC-fax cards in the fax2email server PCs.  such phone lines are
	a bit expensive -- $100 per month per 100 phone numbers, with some
	additional charges for the number of trunks.  for those who aren't
	familiar with DID (Direct Inward Dial) -- it is the method the phone
	company CO uses to transmit phone numbers down to big PBXs and other
	automated phone equipment.  (such as voice mail.)

	each 'subscriber' to the fax2email service could have a specific
	fax phone number assigned.  simple database lookup in the fax2email
	server could provide the proper email destination address for the
	fax.  the only chance for misdelivery would be if the source fax
	hardware dials the wrong phone number.  (DID numbers are assigned
	in big blocks, as in 555-5400 to 555-5599).





-- 
 ... Steve Elias (eli@spdcc.com);6178906844;6179325598; {}
 /* free email2fax!  send email for info. */
 /* be rude to a headhunter today and win free prizes! */

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 89 17:18:00 GMT
From:      BEAME@McMaster.CA
To:        comp.protocols.tcp-ip
Subject:   Re:  Thin or Thick


> RG58 is based on a nominal impedence of 50 ohms and can range from 50 to 53
> ohms.  To use it for thinnet applications you need to ensure the type you
> buy is rated at 50 ohms.

We had someone who shall remain nameless (he dosen't work at here anymore),
wire several areas with 53 ohm RG58. Does anyone know what the ramifications
of this are ? We are mostly running 3C501 :-( cards in PCs.

        - Carl
        Beame@McMaster.CA

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 89 17:42:51 GMT
From:      espo@bpa.BELL-ATL.COM (Bob Esposito)
To:        comp.protocols.tcp-ip
Subject:   Kernel mod for Traceroute


	Does anyone have kernel patches for traceroute?  The problem is
	I have no source and would like to patch my current kernel
	binary.  I'm running a Sun 3/160, 3.5 Unix.  Any info would be
	appreciated.


-- 
Bob Esposito           uucp: espo@bpa.bell-atl.com, {rutgers|bellcore}!bpa!espo
Bell of Pennsylvania   inet: espo@phlsun.prepnet.com
Philadelphia, PA.      phone: +1 215 466 6831  packet: N3CTA @ N3CTA 44.80.0.93
===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===-===

-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 89 21:07:30 GMT
From:      karn@ka9q.bellcore.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Where can I get RFCs?

>I have heard, that RFCs are freely available from some site.

The nominal site is nic.ddn.mil, which accepts anonymous FTP. The RFCs are
in directory RFC:.

For those on NSFNet and tributary networks who may have had trouble reaching
the NIC due to the perenially slow and congested nature of the MILNET and
ARPANET (what's left of it), not to mention the perenially slow and
congested nature of the NIC machine itself, you're welcome to access the
shadow RFC collection I keep on flash.bellcore.com (128.96.32.20) under
/pub/rfc. I usually add new RFCs to the collection within a day or so of
being announced. (Most of the delay is usually in reaching the NIC. It helps
that I like to work weird hours.)

These files are all compressed, so their names end in ".Z".  You'll need the
UNIX "uncompress" program to read them, and be sure to pull them over in
binary mode.

Phil

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 89 21:41:05 GMT
From:      karn@ka9q.bellcore.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Downloading from Simtel ...

In article <89285.230458CMH117@PSUVM.BITNET> CMH117@PSUVM.BITNET (Charles Hannum) writes:
>I figured this out several weeks ago, but haven't had a chance to post it yet.
>To download from Simtel20 to VM, you must do the following:
>
>  FTP> Type I
>  FTP> Quote TYPE L 8
>
>Note: The L in the line above ***MUST*** be capitalized.  Otherwise, case does
>not matter.
>
>The problem with this is that MGET and MPUT don't work.  Tough luck.

Just to expand on this a little....the reason MGET and MPUT from a BSD
client to a TOPS-20 server don't work is because the remote server will
return an error message in response to the NLST command. It complains that
you must be in ascii mode to do an NLST.

I dunno whether this is strictly the fault of the server or of the client,
but the problem could be fixed on either end. The TOPS-20 server could be a
little more lenient by always executing the NLST command as though it were
in ascii mode. Alternatively, the BSD client could keep track of the TYPE
commands issued to the server and issue temporary "TYPE A" commands around
NLST and LIST commands when the server is otherwise in TYPE I state.

My own FTP client does the latter because I got annoyed by LIST output from
BSD systems appearing on my MS-DOS screen without carriage returns.

Phil

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 89 21:52:41 GMT
From:      karn@ka9q.bellcore.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Number of TCP retries

In article <8910131633.AA12633@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes:
>Uh... first a pushy question.  Is your friend implementing TCP, or something
>to run over an Ethernet?  If he's running something over an Ethernet, fine,
>but don't call it TCP.  Otherwise some poor soul will try sometime later
>to run it through a gateway, and will get badly flamed....

AMEN!!

>> 1) If a packet is not acknowledged, how many times should TCP retry
>>    sending the packet before giving up?
>
>    10 is a nice number, *iff* you do exponential backoff.

Personally, I like (and use) "infinity", but I seem to be a minority...

>> 2) What is a reasonable time for a SYN packet to time out?
>
>    start with 1/2 second or so, and exponentially back off.

I think this is too small. 5-10 seconds is more realistic; remember it
doesn't hurt to use longer timeouts except when the network is losing lots
of packets, and then you don't want to add to the confusion.

In my own implementation, I keep a cache of IP address vs smoothed round
trip times and mean deviations. These are kept on a global basis, i.e.,
they're computed in addition to the per-connection calculations. When
opening a new connection, I first check to see if there's an entry in the
cache.  If so, I initialize my SRTT and MDEV values from the cache. If not,
I use a default (typically SRTT = 5 sec and MDEV = 0).

Phil

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      15 Oct 89 22:19:47 GMT
From:      karn@ka9q.bellcore.com (Phil Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: fax over tcp/ip.

In article <254@ursa-major.SPDCC.COM> eli@ursa-major.spdcc.COM (Steve Elias) writes:
>	the reliable method is to use DID phone lines and DID capable 
>	PC-fax cards in the fax2email server PCs. [..]

Yes, this technique works, but it sure has an appetite for telephone
numbers!  Bellcore is the entity charged with the administration of the
North American Numbering Plan; they're the ones who assign new area codes as
needed to meet demand for telephone numbers. Given the rate at which area
codes have been splitting over the past few years (leaving only a handful of
unused codes) I wouldn't be surprised to see some eyebrows raised in certain
circles around here at yet another proposed large-scale consumer of
telephone numbers. Particularly since they're only needed to overcome a
limitation of the existing G3 FAX protocol (i.e., the inability to specify a
recipient.)

In any event, I suspect the skyrocketing demand for cellular phones, pocket
pagers, (real) fax machines and computer modem lines are all going to force
*some* sort of resolution to the crisis in the next few years...

Phil

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 89 01:51:05 GMT
From:      dik@cwi.nl (Dik T. Winter)
To:        comp.protocols.tcp-ip
Subject:   Re: Downloading from Simtel ...

(Reference lost because of editing problems;if you want to know why, send mail)
> I dunno whether this is strictly the fault of the server or of the client,
> but the problem could be fixed on either end. The TOPS-20 server could be a
> little more lenient by always executing the NLST command as though it were
> in ascii mode.
I think simtel changed, but I am not sure.  If I am right currently an NLST
will work if in non-ascii mode; but I could not check (too many anonymous
users).
>                Alternatively, the BSD client could keep track of the TYPE
> commands issued to the server and issue temporary "TYPE A" commands around
> NLST and LIST commands when the server is otherwise in TYPE I state.
I do not know the exact definition of TYPE A.  Is it 7 bit, 8 bit or what?
If 7 bit, you do not want to do your NLST in ascii (check you Mac).
> 
> My own FTP client does the latter because I got annoyed by LIST output from
> BSD systems appearing on my MS-DOS screen without carriage returns.
The problem with the LIST output is due to your client not properly
formatting the output.  When in a BSD ftp to a Mac try an ls.  If you are
unlucky your terminal is locked.  But this is a more general problem.
What should a client do when the filename-space on the server is very
different from that on the client?  In my opinion the client should
format the output for LIST such that inputting an item to GET
is retranslated to the original item.  Also when doing a GET the
client ought to translate filenames that are invalid on the clients
machine.  (Ever tried to get a file where the name contains an embedded
slash on a unix machine?)
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik@cwi.nl
BITNET/EARN: dik@mcvax

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 89 02:25:39 GMT
From:      rick@UUNET.UU.NET (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: Downloading from Simtel ...

Its the clients fault.

The current BSD client does this correctly. (current being the
one I am running...) It will be released in a week or two as
soon as a finish adding the "mnewer" command which gets files
newer than a specifed date (unfortunately it needs a cooperating
server, but I'll supply that too!0

--rick

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Oct 89 08:02:32 EDT
From:      Brian Holmes <BHOLMES%WAYNEST1.BITNET@CORNELLC.cit.cornell.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Encrypted SMTP Mail?
My notes havn't arrived from Interop yet, but I believe a company
with initials TIS is supposed to have front end encryption program for
network mailers by December or January.  I'll post an address as soon
as my stuff arrives unless someone beats me to it.

                        Brian Holmes
                        CSC Operating Systems & Communications

SNAIL    : Wayne State University, 5925 Woodward, Detroit MI 48202 U.S.A.
BITNET   : BHOLMES@WAYNEST1
INTERNET : Brian_Holmes@UM.CC.UMICH.EDU
UUCP     : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 89 12:02:32 GMT
From:      BHOLMES@WAYNEST1.BITNET (Brian Holmes)
To:        comp.protocols.tcp-ip
Subject:   Re: Encrypted SMTP Mail?

My notes havn't arrived from Interop yet, but I believe a company
with initials TIS is supposed to have front end encryption program for
network mailers by December or January.  I'll post an address as soon
as my stuff arrives unless someone beats me to it.

                        Brian Holmes
                        CSC Operating Systems & Communications

SNAIL    : Wayne State University, 5925 Woodward, Detroit MI 48202 U.S.A.
BITNET   : BHOLMES@WAYNEST1
INTERNET : Brian_Holmes@UM.CC.UMICH.EDU
UUCP     : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Oct 89 16:52:17 EDT
From:      Steve Kent <kent@BBN.COM>
To:        collins-c@osu-20.ircc.ohio-state.edu
Cc:        tcp-ip@nic.ddn.mil, kent@BBN.COM
Subject:   encrypted SMTP mail
Cilfford,

	Thanks for your interest in the privancy enhanced Internet
mail RFCs (1113-15).  Software implementing RFCs 1113 and 1115 is
now undergoing testing and will be distributed to members of the
IAB Privacy and Security Research Group for Beta test soon.  This
software does NOT support the key management system described in
RFC 1114 and thus is not suitable for widespread distribution. 
Also, RSA Data Security Inc. is not yet ready to support the 
registration procedure described in RFC 1114.

	We expect Beta test of a complete set of software in the
first quarter of 1990, including ancillary software for user and
organization registration, revoked certificate list managament, etc.
Feel free to contact me early next year if you want to be considered
for Beta test site designation.

Thanks,

Steve Kent
Chair, 
IAB Privacy and Security Research Group
-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 89 13:01:35 GMT
From:      galvin@TIS.COM (James M Galvin)
To:        comp.protocols.tcp-ip
Subject:   Re: Encrypted SMTP Mail?

> My notes havn't arrived from Interop yet, but I believe a company
> with initials TIS is supposed to have front end encryption program for
> network mailers by December or January.  I'll post an address as soon
> as my stuff arrives unless someone beats me to it.

We are:
	Trusted Information Systems, Inc.
	3060 Washington Road (Rt. 97)
	Glenwood, MD 21738

As announced at Interop, we will have an implementation of RFC 1113
freely available in the January or so timeframe.  The user interface is
integrated in to the MH user agent.

You may contact "balenson@tis.com" for more details, or watch here for
further announcements.

Jim

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 89 14:00:04 GMT
From:      liwen@software.org (Andrew Liwen)
To:        comp.protocols.tcp-ip
Subject:   Looking for SNMP

We have a large, diverse network of machines, including: Apollos (all flavors),
Suns, and VAXen.  We are interested in building some network management tools
for our network and are interested in looking in to SNMP.  In order to build
the needed tools, we will need access to source code (i.e. porting to VMS and
Apollo's NCS environment are being considered).  Could someone point me to a
supplier of SNMP.  We would prefer public domain source but will consider
acquiring a commercial package.

Please e-mail responses.  If there seems to be a large enough set of replys,
I'll post a summary.

//Andy
--
Andrew B. Liwen                                              voice 703/742-7289
Software Productivity Consortium,Inc.                          FAX 703/742-7200
SPC Building -- 2214 Rock Hill Road                          liwen@software.org
Herndon, Virginia 22070                                    ..!uunet!sunny!liwen

-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 89 15:13:49 GMT
From:      jbvb@VAX.FTP.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP sequence number sign change and wrap-around

Sorry, I got out my packet trace of the 386i SunOS 4.0.1 TCP
connection hang, and it turned out that the case it didn't handle
right was 0x7FFFFFFFFFFFFFFF to 0x8000000000000000.  I haven't
explicitly tested it for the other one (all ones to 0).

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 89 15:44:46 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Encrypted SMTP Mail?

In article <66649@tut.cis.ohio-state.edu> 
COLLINS-C@OSU-20.IRCC.OHIO-STATE.EDU (Clifford Collins) writes:
>I recently saw copies of RFC1113, 1114 and 1115 that address
>encrypted SMTP mail.  Are there any implementations out there?
>I would be very interested in acquiring what's out there to test
>and evaluate.  Any leads would be welcome. Please reply to me
>via e-mail.  Thanks!
>
	It is quite an interesting and imprssive effort, but there are
some things you aren't going to like, since the RSA guys have patented
the public key algorithms.

	The RFCs define a comprehensive framework for defining a
secure mail system that uses SMTP transport.

	Trusted Information Systems has developed software based on MH
mail to use encryption and is planning on widely distributing this.
However, the public key algorithms are licensed from RSA.

	RSA <something-or-other> is a spinoff of the RSA guys that is
in the business of providing a certification authority to make all
this work.

	Are you ready for the kicker?  You pay $25 to register each
and every user of secure mail in your institution for a period of two
years with said RSA company.

	Anyone out there ready to trust RSA to maintain a list of
users in your institution that can send and receive secure mail?  Are
you ready to pay $25 every two years for the privilege?

	--Kent England, Boston University

-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 89 16:30:38 GMT
From:      meissner@twohot.rtp.dg.com (Michael Meissner)
To:        comp.protocols.tcp-ip
Subject:   Re: Counting Internet Hosts (and Users)

In article <5346@shlump.nac.dec.com> michaud@devax.dec.com (Jeff Michaud) writes:
|  > Yes, but it probably takes about 136 YEARS to run (assuming that pings
|  > take about 1 second to either respond or time out).
|  
|  	Thats only if you were to actually wait for for a response/timeout.  If
|  	you just continuously sent one right after the other without waiting for
|  	the response (but sending just slow enough as to not create a traffic jam)
|  	and simply count the number of responses.  I wonder how long that would
|  	take?

Note that doing this may have two adverse affects.  It may cause
trouble with the beancounters, for sites that pay for their links to
the internet (can you say X.25?) if a large increase in the traffic
occurs because of 64K pings to a class B network.  Also, it will
undercount some networks, which have cisco boxes (or other such gear)
which are set up not do not allow inward connections except for
certain hosts and/or ports.
--

Michael Meissner, Data General.				If compiles where much
Uucp:		...!mcnc!rti!xyzzy!meissner		faster, when would we
Internet:	meissner@dg-rtp.DG.COM			have time for netnews?

-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 89 17:10:24 GMT
From:      pat@hprnd.HP.COM (Pat Thaler)
To:        comp.protocols.tcp-ip
Subject:   Re: Thin or Thick

> / hprnd:comp.protocols.tcp-ip / BEAME@McMaster.CA / 10:18 am  Oct 15, 1989 /
> 
> > RG58 is based on a nominal impedence of 50 ohms and can range from 50 to 53
> > ohms.  To use it for thinnet applications you need to ensure the type you
> > buy is rated at 50 ohms.
> 
> We had someone who shall remain nameless (he dosen't work at here anymore),
> wire several areas with 53 ohm RG58. Does anyone know what the ramifications
> of this are ? We are mostly running 3C501 :-( cards in PCs.
> 
>         - Carl
>         Beame@McMaster.CA
> ----------
The 802.3 10BASE2 specification for the average coax characteristic impedance
is 50 +- 2 ohms and impedance variations of +- 3 ohms sinusoidal centered
around that value are allowed.  (50 ohms +- 1% is the spec for the 
terminator.)  If your actual impedance is 53 ohms, you are slightly out
of spec.  If your impedance is 53 ohms nominal with variation a few
ohms to either side you are a little further out of spec.  

If your wire is all 53 ohm, you probably won't see problems (but if
you see problems, it may be hard to say whether it is the wire or the
other networking products.)  If you have a mix of 53 and 50 ohm wire
(perhaps 53 ohm wired in the walls and 50 ohm cables from the wall
to the station), there will be extra reflections which could cause
high bit error rates (CRC and alignment errors).

Pat Thaler

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      Mon, 16 Oct 89 18:00:06 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

In article <8910141823.AA20101@uunet.uu.net> rick@UUNET.UU.NET (Rick Adams) writes:
>	... The "% hack"
>	is ugly, difficult to parse correctly at Internet--othernet gateways,
>	and not needed.
>
>Funny, thats exactly how I (and lots of others) have been describing
>the rfc822 source routing. I assure you that the rfc822 source routing
>is MUCH more difficult to parse that the % hack.

Also, if I am not mistaken -- I am behind on my RFC reading, and could
be wrong about this -- the host-requirements RFCs say source routes may 
contain only Internet-registered domains.  That is, you *need* the %
hack to do *real* internetworking (talking to other networks).
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 89 18:27:07 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Downloading from Simtel ...


	>The problem with this is that MGET and MPUT don't work.  Tough luck.

	Just to expand on this a little....the reason MGET and MPUT from a BSD
	client to a TOPS-20 server don't work is because the remote server will
	return an error message in response to the NLST command. It complains that
	you must be in ascii mode to do an NLST.

The Host Requirements Working Group struggled with this issue, and reached
what seemed to be an acceptable decision.  See section 4.1.2.7 of RFC-1123.

Bob Braden

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 89 18:36:00 GMT
From:      WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho")
To:        comp.protocols.tcp-ip
Subject:   Downloading from SIMTEL20

Notwithstanding the mandate in RFC 1123, the FTP server should never
*assume* a transfer mode that has not been explicitly requested.  If
the current mode is obviously wrong, such as for directory listings,
which are *always* sent in NETASCII mode, the server has no choice
except to complain if the current transfer type is not ASCII.  If the
FTP client is set up for some form of binary mode (type l whatever),
and the server sends a directory listing in NETASCII, the resulting
display or redirected file will not contain the expected format.
Thus, it is up to the client to keep track of the requested file
transfer mode and switch temporarily to ASCII mode for directory
listings.

This discussion came up because a user wanted to use mget.  There is a
trap in this, even if the directory list is transferred correctly.
The user must be certain that all the files are of the same type.  For
example, an mget should work right now, modulo the filename trimming,
for a group of ASCII files.  But, mixed file types are a problem, not
just with this machine, but between any two machines which do not have
the same wordsize or byte order.  (I have been toying with the
possibility of extending our STAT filename to include bytesize
information without breaking TOPS20 FTP clients which depend on the
format of the reply.  The idea here is that the FTP client would
implement a mget to get a list of filenames from the remote, issue a
STAT filename prior to each get to parse the reply to set the
appropriate transfer type.)

Last comment: we have found several FTP clients which try to parse the
filename in a get into a local filename, and do it wrong.  For
example, VAX/VMS TWG ftp will try to parse "get alias:file.type" and
complain to the user that "alias:file.type" is a bad (local) filename.
The user is confused because it appears that the message came from the
FTP server, implying the file does not exist.  The workaround is to
have the user enclose the remote filename in double quotes and specify
a receiving filename.  Note that there are two problems: one with the
failed parse attempt, and the other with the error message not
properly identified as being a local error message.

--Frank

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 89 20:52:17 GMT
From:      kent@BBN.COM (Steve Kent)
To:        comp.protocols.tcp-ip
Subject:   encrypted SMTP mail

Cilfford,

	Thanks for your interest in the privancy enhanced Internet
mail RFCs (1113-15).  Software implementing RFCs 1113 and 1115 is
now undergoing testing and will be distributed to members of the
IAB Privacy and Security Research Group for Beta test soon.  This
software does NOT support the key management system described in
RFC 1114 and thus is not suitable for widespread distribution. 
Also, RSA Data Security Inc. is not yet ready to support the 
registration procedure described in RFC 1114.

	We expect Beta test of a complete set of software in the
first quarter of 1990, including ancillary software for user and
organization registration, revoked certificate list managament, etc.
Feel free to contact me early next year if you want to be considered
for Beta test site designation.

Thanks,

Steve Kent
Chair, 
IAB Privacy and Security Research Group

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      16 Oct 89 21:57:05 GMT
From:      lear@NET.BIO.NET (Eliot Lear)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs


I think you have it backwards.  Source routing MUST NOT be specified
in an RCPT command.  MUAs MAY circumvent source routing but MUST NOT
produce a 5xx error on receipt of a route addr (cf. RFC 1123 section
5.2.6).  The only way that compliant implementations must change is
that they may not send route addrs.  The goal here is to phase out
source routing.  The belief was that we should simply not go from a
MUST to a MUST NOT state on its handling, or we'd have mail bouncing
all over the place.
-- 
Eliot Lear
[lear@net.bio.net]

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 89 00:07:24 GMT
From:      rc10+@ANDREW.CMU.EDU (Richard Clemens)
To:        comp.protocols.tcp-ip
Subject:   PK-88 and MacNet works!

Earlier this year I wrote:

>I am still have problems with the PK-88 talking to the Macintosh
>when using MacNet Version 1.0.  The information is still stuck in
>the PK-88s buffer and will not dump to the computer until an exit
>from host mode occurs.

And got several responses but none worked.  Now Dick Rucker, KM4ML,
checked with AEA and they suggested a jumper between R5 and R7 on
their leads nearest the serial port connector for Macket and MacRatt
host mode and so I tried it for MacNet and it seems to work just fine
(no pun intended Steve)!

My cable is:

DB-25         MacPlus
              Mini-8
  1             4,6
  2             5
  3             3
  7             4,6
  8             1
 20             2

________________________________________________________________________
Rich Clemens                    Associate Professor, WV Wesleyan College
Phone:  304-473-8000 office            Bitnet: os360160@wvnvms.wvnet.edu
        304-472-3029 home                           rc10+@andrew.cmu.edu
TCP/IP: [44.058.000.003]                         Packet: KB8AOB @ WB8CQV
________________________________________________________________________

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 89 00:23:58 GMT
From:      sean@cadre.dsl.pitt.edu (Sean McLinden)
To:        comp.protocols.tcp-ip
Subject:   Re: RPC and DNS

In article <8910101354.AA25812@ucbvax.Berkeley.EDU> KA@ESOC.BITNET writes:
>     Does anybody know of a VAX/VMS based implementation of RPC
>(particularly the Port Mapper) and Domain Name Server/Resolver.

Try MultiNet from TGV.COM (netmail support@tgv.com), I don't have
the phone number handy. This is a slick, robust implementation of
the Internet protocol suite for VMS that also includes NFS and
the services that you mentioned and is one of the best software
packages I have ever worked with. Feel free to call for additional
comments and references but we (the University of Pittsburgh), looked
at a number of implementations of the Internet protocols for VMS
(including DEC's product), and MultiNet was the clear winner.

If only they'd tackle VM/MVS...

Sean McLinden
Decision Systems Laboratory
University of Pittsburgh
(412) 648-9600

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 89 03:40:14 GMT
From:      linimon@attctc.Dallas.TX.US (Mark Linimon)
To:        comp.protocols.tcp-ip
Subject:   question on common usage of select call

I know this isn't strictly a tcp-ip question so please excuse while I place
foot firmly in mouth...

A customer of ours is having problems porting code using the select ()
call (from a *NIX to another operating system, details on reuquest).  In
particular they (and now I) want to know if the practice of using
select () on other than sockets is widespread.  I already have proof
that it exists, and intuition that it's nasty -- I'm more concerned
with how widespread it is.

The documentation that comes to hand doesn't specifically address
the question of whether it is either allowed, disallowed, or whatever.

Email please, I will summarize if there is any interest and it isn't
"intuitively obvious to an extremely casual observer."

Mark Linimon
Software Engineer
Mizar, Inc.
reachable by linimon@attctc

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 89 06:55:15 GMT
From:      jh@tut.fi (Hein{nen Juha)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for SNMP

In article <428@sunny.software.org> liwen@software.org (Andrew Liwen) writes:

   to SNMP.  In order to build the needed tools, we will need access
   to source code (i.e. porting to VMS and Apollo's NCS environment
   are being considered).  Could someone point me to a supplier of
   SNMP.  We would prefer public domain source but will consider
   acquiring a commercial package.

there are atleast three public domain snmp implementations: mit's,
cmu's and nysernet's (agent only).  you can find the first two eg.
from our ftp archive at funet.fi.
--
--	Juha Heinanen, Tampere Univ. of Technology, Finland
	jh@tut.fi (Internet), tut!jh (UUCP), jh@tut (Bitnet)

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 89 14:55:04 GMT
From:      AVL@MATH.AMS.COM (Al Lazzareschi)
To:        comp.protocols.tcp-ip
Subject:   thin & thick

>Subject: Thin or Thick
 
>While we are on the subject would someone like to comment on
>the difference between RG58 and RG59 thinwire?
 
>Can you mix them or should you use just one type?


  I knew I would attract attention but I did not realize how 
fast and how much.   
  Thanks to all that replied so quickly and the concensusis 
that RG58 - is the correct thinwire coax that uses 50ohms and the
RG59 coax is used for CATV (cable TV) at 75ohms and never should the 
two be mixed, nor the latter used at all on an ethernet.


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+  Allan Lazzareschi                   American Mathematical Society +
+  Technical Specialist                P O Box 6248                  +
+  AVL@MATH.AMS.COM                    Providence, R.I. 02940        +
+                                      (401)272-9500  x272           +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 89 20:00:16 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Did DCA really shut down the mailbridges because of the SPAN worm?

Did DCA really have the ARPA/MILNet mailbridges shut down because of the
worm circulating on the SPAN DECnet?  It would appear so from here, but
I've not been able to confirm it with any authority.

	Brian Kantor	UCSD Network Operations

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 89 21:23:10 GMT
From:      dsmith@oregon.uoregon.edu (Dale Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: CNAME question

In article <8910141032.AA13345@ucbvax.Berkeley.EDU>, VSBENZI@WEIZMANN.BITNET (Benzi mizrahi) writes:

>  we have a name server that is primary to our local zone and sub-zone
>  within our local zone. Can I have CNAME RR in the upper zone that
>  his owner name is the same as the sub-zone? Consider the following
>  RRs:
>  our.local.zone.  IN SOA    ....
>                   IN NS     ns.our.local.zone
>  ns.our.local.zone. IN A     <ip.addr>
>
>  sub-zone.our.local.zone.   IN CNAME  sub-zone.sub-zone.our.local.zone.
>
>  sub-zone.our.local.zone. IN  SOA ...
>                           IN  NS ns.our.local.zone
>  sub-zone.sub-zone.our.local.zone. IN A  <his.ip.addr>
>  Is this a protocol error? thanx , Benzi

This is an error.  You should move the sub-zone.our.local.zone CNAME
record to below the SOA record for that name.  It only makes sense.  An
SOA record delimits a zone, but you already have defined RR's that
belong in that zone.  This should not be a problem (it will work) unless
you are delegating authority to another server.  In the case of using
Bind 4.8 based systems, I think you will get a duplicate SOA message
from the secondary during the zone transfer (assuming the secondary also
is secondary for both our.local.zone and sub-zone.our.local.zone).

Cheers,

Dale Smith, Assistant Director of Network Services
University of Oregon		Internet: dsmith@oregon.uoregon.edu
Computing Center		BITNET: dsmith@oregon.bitnet
Eugene, OR  97403-1212		Voice: (503)686-4394

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 89 21:42:00 GMT
From:      FILLMORE@EMRCAN.BITNET
To:        comp.protocols.tcp-ip
Subject:   Router interoperability

I have a (perhaps naive) question about the interoperability of routers:
We want to join Ethernet LANs in two different cities with a 56kbps sync
line.  The LANs run a variety of protocols such as XNS, TCP/IP, Decnet.
We want to use routers at each end of the line.  Do the two routers
have to be from the same manufacturer?  If so, why?  One of the routers
is a Cisco box but the other could be Proteon or some other make
(or does it have to be a Cisco?).
________________________
Bob Fillmore, Systems Software & Communications   BITNET:  FILLMORE@EMRCAN
  Computer Services Centre,                       Voice:   (613) 992-2832
  Energy, Mines, & Resources Canada               BIX:     bfillmore
  588 Booth St., Ottawa, Ontario, Canada  K1A 0E4

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 89 22:05:30 GMT
From:      geoff@FERNWOOD.MPK.CA.US (the terminal of Geoff Goodfellow)
To:        comp.protocols.tcp-ip
Subject:   FDDI/TCP-IP for Hammacher Schlemmer Chistmas Tree?

Does anyone have a FDDI interface and a TCP-IP driver for the Hammacher
Schlemmer Fiber Optic Christmas Tree?  Could we have one on the Show and
Tel-Net next year?  I quote from the recent catalog which arrived this
morning's mail:

	THE ONLY FIBER OPTIC CHRISTMAS TREE

	A Hammacher Schlemmer exclusive, this white Christmas tree is enhanced
	by advanced fiber optic lighting technology.  Two light sources
	encased at the base of the tree project through revolving colored
	filters to separate optic fibers cabled evenly among the branches.
	The fiber cables end in 200 glittering lights, each containing a
	spectrum of eight colors that change continuously, for a vision of
	great warmth and brilliance.  No lights to strings.  Shipped assembled
	--just lower the branches.  Transformer uses standard outlet.
	Height: 6'.

	37814W .............................. Postpaid $6500.00

Geoff Goodfellow
Anterior Technology

-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 89 22:10:37 GMT
From:      ji@close.cs.columbia.edu (John Ioannidis)
To:        comp.unix.i386,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Alpha-Test SLIP for System V R3.2 STREAMS-based TCP/IP

I wrote a SLIP driver for Interactive's 386/ix (SVR3.2) on Toshibas
T5200/100. It should run on any System V Release 3.2 machine that uses
STREAMS-based TCP/IP. The beast still needs some work, but if you want
to be an alpha-test site, you can request a copy by sending me mail to

		ji@cs.columbia.edu

and I'll mail you a shar file with the driver stuff in it. 

Please remember that THIS IS *NOT* A PRODUCTION VERSION! -- it's just
alpha-test, for people who are willing to put up with some flakiness,
report bugs and problems, and even fix bugs and add features if they
feel like it. You don't have to report anything, of course, but I
would appreciate it if you did. 

Depending on the kind of feedback I get, there should be a beta-test 
version out by the middle of next week, probably by anonymous-ftp
(instead of mail) this time. 

/ji

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 89 22:37:58 GMT
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: ether collision backoff

In article <42686@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
writes:
    At last week's Interop, I was told that a large workstation company's
    products can be configured to use non-standard retransmission-after-
    collision delays.

To my knowledge this is false rumor, which has been circulating for years.

    Is this true?  Does it cause big problems, as my informant implied?
    Exactly which parameter(s) is(are) changed--the exponent, the multiplier,
    the algorithm?  Does it really help NFS that much?  Is there a relevant
    de-facto or de-jurie standard?  Should Silicon Graphics do the same thing?
    Are the Protocol Police about to squash the idea?

Others have already pointed out that this is an extremely bad idea.  It
might help to prevent misguided experimentation if I try to explain why
it is a bad idea, instead of simply stating "it's against the law" (which,
in fact, it is).

The rationale behind the "binary exponential backoff" algorithm required
by the standard is explained in Robert Metcalfe's PhD thesis, although
the original CACM paper on Ethernet might be more available.  At any rate,
the point is that if there are Q hosts simultaneously wanting to
send a packet on an Ethernet, then in order to avoid congestive instability
each should attempt to transmit with probability 1/Q.

The problem is that each individual host has no global knowledge about
the number of other hosts wanting to transmit.  It must therefore make
an estimate of this number based on the only property of the network
it can observe, namely the number of times it has tried to send the
current packet and had a collision.  Clearly, it is important that
this estimate be nearly right, and that any remaining error be biased
in the direction of inefficiency rather than congestive collapse.

It turns out (if you believe the math in Metcalfe's thesis; I don't
intend to check it) that the "binary exponential backoff" algorithm
gives the right behaviour; the "estimate" of Q embodied in the backoff
count (which is really the base-2 logarithm of Q) is close enough to
work well even under heavy load.  (See the paper I co-authored with
Dave Boggs and Chris Kent in Proc. SIGCOMM '88; we measured a real
Ethernet under moderate overload and showed that it does work.)

One aspect of the Standard Ethernet is that, although a host is supposed
to attempt transmission up to 16 times, it is supposed to stop doubling
the delay after the 10th time; otherwise, the delays would get unreasonably
large.  Of these two constants, "16" is sort of an arbitrary choice, "10"
is not!  This is because the maximum number of hosts on an Ethernet is
set to be 1024 = 2^10; truncating the delay at less than 2^10 slot times
could (if someone was stupid enough to build a net that large) conceivably
cause congestive collapse.  Truncating the delay at more than 2^10 slot
times, on the other hand, doesn't buy you anything.

The reason why one is supposed to give up after 16 attempts is that
after a while it is pointless to continue.  Moreover, in order to
maintain both fairness and reasonable performance, it is important
to limit the time over which "history" of previous network behaviour
is retained.  That is why one starts the next transmission attempt with
a delay-count of 0, rather than trying to be clever and use something
based on the delay you used for the previous packet.  Note that there
are some pathological situations where, with small numbers of very
busy hosts, the Ethernet can be measurably unfair over rather long
time scales.  In general, though, the Ethernet works right.

So: obey the law, it's for your own good.  This law, at any rate.

-Jeff

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      17 Oct 89 23:32:35 GMT
From:      hwajin@wrs.wrs.com (Hwajin Bae)
To:        comp.protocols.tcp-ip
Subject:   Re: Number of TCP retries

In article <8910131437.AA06523@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes:
>> 4) When programming an Ethernet controller (e.g. Lance chip), how many
>>    times should the controller retransmit the packet when it detects
>>    collisions and other errors before giving up and reporting an error
>>    to the driver?

When transmission fails due to the collision LANCE will attempt to retry
up to 15 times.  The famous "truncated binary exponential backoff" algorithm
comes in to play between retries.  When collision jam signal is subsided,
LANCE will recalculate a delay before transmitting as an integral multiple
of the slot time (512 bit).  The number of slot times to delay before the
nth retransmission is chosen as a uniformly distributed random integer
in the range: 0 <= r <= 2^k where k = min (n, 10) according to the LANCE
manual.  If all 16 attempts fail, RTRY bit in TMD3 will be set.  You can't
control this logical from your driver so it's a given; you write your driver
to conform to this feature.  
-- 
Hwajin Bae
Wind River Systems, Emeryville, CA

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Oct 89 09:51:28 EDT
From:      Brian Holmes <BHOLMES%WAYNEST1.BITNET@CORNELLC.cit.cornell.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Looking for SNMP
A public domain version of SNMP is available from 128.2.13.21
I havn't tried it out but I belive source is there also.

                        Brian Holmes
                        CSC Operating Systems & Communications

SNAIL    : Wayne State University, 5925 Woodward, Detroit MI 48202 U.S.A.
BITNET   : BHOLMES@WAYNEST1
INTERNET : Brian_Holmes@UM.CC.UMICH.EDU
UUCP     : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES
-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 89 05:52:50 GMT
From:      root@netdev.UUCP (Alex Huppenthal)
To:        comp.protocols.tcp-ip
Subject:   KA9q for Excelan EX0S 205T ???



We just received a number of EX0S 205T smart ethernet controllers with
MSDOS software. Does anyone know if public domain packages, ( one that
we can get sources to ), support this I/O controller?

Specifically, KA9Q....... 


A package, commercial or otherwise for Unix 3.2 or Xenix 2.3 would be great
too.

-Alex

-- 
Communication Systems Research         (   Without Dr. Pepper......        )
SNAIL:  6045 Buffridge Tr, Dallas, TX 75252  (     what are we, really?  )
INTERNET:  alex@comsys.com      UUCP:  { texbell }!netdev!alex 

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 89 13:33:45 GMT
From:      melpar!toppin@uunet.uu.net  (Doug Toppin)
To:        tcp-ip@NIC.DDN.MIL
Subject:   'shutdown' vs. 'close' to free resources?
We have a problem with a large number of connections in
a short period of time exhausting the resources of the
host processor. I understand that after doing a close it
may be several minutes before the resources used by that
socket are completely freed for reuse and was wondering if
doing a shutdown would make any difference in the time
it takes to release all of the resources?
If anyone has an answer please let me know.
We are running Network Research Corp implemenation of TCP
(called Fusion) on IBM Xenix 2 on the 286.

thanks
Doug Toppin
uunet!melpar!toppin
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 89 13:51:28 GMT
From:      BHOLMES@WAYNEST1.BITNET (Brian Holmes)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for SNMP

A public domain version of SNMP is available from 128.2.13.21
I havn't tried it out but I belive source is there also.

                        Brian Holmes
                        CSC Operating Systems & Communications

SNAIL    : Wayne State University, 5925 Woodward, Detroit MI 48202 U.S.A.
BITNET   : BHOLMES@WAYNEST1
INTERNET : Brian_Holmes@UM.CC.UMICH.EDU
UUCP     : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 89 14:03:53 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Did DCA really shut down the mailbridges because of the SPAN worm?

Brian:

Yes, DCA did disconnect the MILNET Mail Bridges from the Internet Monday after-
noon.  They were reconnected Tuesday afternoon.  Using traceroute to probe the
net from the MILNET side produced a lot of port unreachables if the transition
from the MILNET occured on the West Coast and redirect storms if the transition
occured on the East Coast (primarily between Marina Del Ray and Cambridge).

NCC stated that the problem was related to a "worm"/"virus" which only affected
VMS systems.  No additional details were provided.

Merton

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 89 14:25:34 GMT
From:      AZ957@DK0RRZK0.BITNET
To:        comp.protocols.tcp-ip
Subject:   AIX-PS/2 and 3COM ethernet cards

We just have the opportunity to test AIX version 1.1 on a IBM PS/2 Model
80 and have some problems with the ethernet connection.
We learned from IBM that they only support an ethernet adapter from
Ungermann-Bass, in the machine however we have one from 3COM
(Etherlink/MC or 3C523), because it otherwise belongs to a local
PC-Net with 3COM net software.
Does anybody know if it is possible to get an ethernet driver for AIX
either from 3COM direct or from some other source?
I know that it would be best to ask 3COM themselves, but I have also
difficulties to find a technical support person from that company over
here in Germany.

Jochen Roderburg
Regional Computing Center
University of Cologne         Tel. :   +49-221/470-4564
Robert-Koch-Str. 10           BITNET:  A0045 @ DK0RRZK0 (CDC NOS/BE)
D-5000 Koeln 41                    or  A0045 @ DK0RRZK1 (IBM VM/CMS)
West Germany                       or  AZ957 @ DK0RRZK0 (Siemens SINIX)

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 89 16:06:28 GMT
From:      guy@guy.uucp (Guy Streeter)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for SNMP

jh@tut.fi (Hein{nen Juha) writes:

>there are atleast three public domain snmp implementations: mit's,
>cmu's and nysernet's (agent only).  you can find the first two eg.
>from our ftp archive at funet.fi.

The NYSERnet implementation is SOLD by NYSERNET.  It is not in the public
domain.

Guy Streeter
b11!guy!guy@ingr.com
...uunet!ingr!b11!guy!guy

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 89 16:29:19 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: Did DCA really shut down the mailbridges because of the SPAN worm?

In article <10059@ucsd.Edu> I wrote:
>Did DCA really have the ARPA/MILNet mailbridges shut down because of the
>worm circulating on the SPAN DECnet?  It would appear so from here, but
>I've not been able to confirm it with any authority.
>	Brian Kantor	UCSD Network Operations

The answer is yes, they did.  As detailed below:

From TomZ@ddn1.dca.mil Wed Oct 18 08:08:14 1989
Message-Id: <8910181507.AA01925@ucsd.edu>
Date: 18 Oct 89 09:29 EDT
From: TomZ@DDN1.DCA.MIL
Subject: In-Re: "Did DCA really shut down the mailbridges because of the SPAN worm?" 
To: Brian@UCSD.EDU
Cc: Fred@NIC.DDN.MIL
Status: R

Comment: Please see the fifth paragraph (after the boilerplate) of DDN
Security Bulletin #3 (below).  The MailBridge filters were activated because
at the time of the first report, it was _NOT_ clear that W.COM could not
"tunnel" (get connectivity by encapsulating a DECnet message within a
TCP/IP "envelope") to the over two hundred VMS sites on MILNET.  We were
criticized for assuming that the "Father Christmas" worm couldn't use
this trick last December.
/s/: Tom Zmudzinski (703) 285-5459
Forwarded Message(s):  
-----------------------------------------------------
From: TomZ @ DDN1.DCA.MIL
To: SCC @ NIC.DDN.MIL
Subject: DDN Security Bulletin #3
Date: 17 Oct 89 15:24 EDT
cc: B615-ALL @ DDN1.DCA.MIL, CERT @ SEI.CMU.EDU, April @ NIC.DDN.MIL,
MILNETMGR @ DDN3.DCA.MIL, ASOP-OI @ Hauchuca-EMH2.ARMY.MIL,
AF-SIMM @ Gunter-Adam.AF.MIL, Scherlis @ VAX.DARPA.MIL
Comment: Hi, April -- Please get this out ASAP.
/s/:  
Tom Zmudzinski, DDN Network Security Officer
Defense Communications Agency
Code DDEP (B615) McLean
Washington, DC  20305-2000
 
Office Phone: (703) 285-5459
Forwarded Message(s): 

**********************************************************************
 
DDN Security Bulletin 03         DCA DDN Defense Communications System
17 Oct 89               Published by: DDN Security Coordination Center
                                     (SCC@NIC.DDN.MIL)  (800) 235-3155
 
                        DEFENSE  DATA  NETWORK
                          SECURITY  BULLETIN
 
The DDN  SECURITY BULLETIN  is distributed  by the  DDN SCC  (Security
Coordination Center) under  DCA contract as  a means of  communicating
information on network and host security exposures, fixes, &  concerns
to security & management personnel at DDN facilities.  Back issues may
be  obtained  via  FTP  (or  Kermit)  from  NIC.DDN.MIL  [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest".  The bulletin
pathname is SCC:DDN-SECURITY-nn (where "nn" is the bulletin number).
 
**********************************************************************
 
                 W.COM ("WANK") WORM ON SPAN NETWORK
 
On 16 October, the CERT received word from SPAN network control that a
worm was attacking SPAN VAX/VMS  systems.  This worm affects only  DEC
VMS  systems  and  is  propagated  via  DECnet (not TCP/IP) protocols.
At least  two versions  of this  worm exist  and more  may be created.
Non-VMS systems are immune; TCP/IP networks are not at risk.
 
While this program  is very similar to last year's HI.COM  (or "Father
Christmas") worm (see DDN MGT Bulletin #50  23 Dec 88),  THIS IS NOT A
PRANK.  Instead of a "cute" Christmas greeting,  W.COM appends code to
.com files and displays this banner:
 
      W O R M S    A G A I N S T    N U C L E A R    K I L L E R S
    _______________________________________________________________
    \__  ____________  _____    ________    ____  ____   __  _____/
     \ \ \    /\    / /    / /\ \       | \ \  | |    | | / /    /
      \ \ \  /  \  / /    / /__\ \      | |\ \ | |    | |/ /    /
       \ \ \/ /\ \/ /    / ______ \     | | \ \| |    | |\ \   /
        \_\  /__\  /____/ /______\ \____| |__\ | |____| |_\ \_/
         \___________________________________________________/
          \                                                 /
           \    Your System Has Been Officically WANKed    /
            \_____________________________________________/
 
     You talk of times of peace for all, and then prepare for war.
 
Initial reports described the worm as destructive, i.e. it would erase
files.  Detailed  analysis by  the CERT,  Lawrence Livermore  National
Laboratory, and  FermiLab has  not found  any code  that would perform
file erasures.   However,  files are altered and new accounts created.
Serious security holes are left open by this worm.
 
It is very  important to understand  that someone in  the future could
launch this  worm on  any DECnet  based network.   Many copies  of the
virus have been mailed around.  Anyone running a DECnet network should
be warned.
 
When  the  DDN  PMO  received  these  initial  reports, the MailBridge
filters were activated  to preclude any  traffic from passing  between
MILNET and the rest of the  Internet.   The filters will be turned off
(restoring full interoperability)  Tuesday  17 October 1989  NLT 17:00
EDT.   (NOTE:  W.COM could traverse the MILNET only if encapsulated in
a TCP/IP  "envelope",  i.e. "assisted" by  a human  agent,  and cannot
"infect" the MILNET.)
 
R. Kevin Oberman from Lawrence Livermore National Laboratory reports:
 
    "This is a mean bug to kill and could have done a lot of damage.
    Since it notifies (by mail) someone of each successful penetration
    and leaves a trapdoor (the FIELD account), just killing the bug is
    not adequate.  You must go in an make sure all accounts have
    passwords and that the passwords are not the same as the account
    name."
 
The CERT also suggests checking every  .com  file on the system.   The
worm appends  code to  .com  files which will  reopen a  security hole
every time the program is executed.
 
An analysis of the  worm  (provided by R. Kevin Oberman  and used with
his permission)  appears below.   Included with  the analysis is a DCL
program that will block the current version of the worm.  This program
should provide enough time to close up obvious security holes.
 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 
Date: Mon, 16 Oct 89 15:30 PDT
From: "Kevin Oberman, LLNL, (415)422-6955" <OBERMAN@icdc.llnl.gov>
Subject: Report on network worm ***URGENT***
 
 
 
                          Report on the W.COM worm.
                               R. Kevin Oberman
                            Engineering Department
                    Lawrence Livermore National Laboratory
                               October 16, 1989
 
The following describes the action of the W.COM worm (currently based on the
examination of the first two incarnations). The replication technique causes
the code to be modified slightly which indicates the source of the attack and
learned information.
 
All analysis was done with more haste than I care for, but I believe I have all
of the basic facts correct.
 
First a description of the program:
 
1. The program assures that it is working in a directory to which the owner
(itself) has full access (Read, Write,Execute, and Delete).
 
2. The program checks to see if another copy is still running. It looks for a
process with the first 5 characters of "NETW_". If such is found, it deletes
itself (the file) and stops its process.
 
                                     NOTE
A quick check for infection is to look for a process name starting with
"NETW_". This may be done with a SHOW PROCESS command.
 
3. The program then changes the default DECNET account password to a random
string of at least 12 characters.
 
4. Information on the password used to access the system is mailed to the user
GEMTOP on SPAN node 6.59. Some versions may have a different address.
 
5. The process changes its name to "NETW_" followed by a random number.
 
6. It then checks to see if it has SYSNAM priv. If so, it defines the system
announcement message to be the banner in the program:
      W O R M S    A G A I N S T    N U C L E A R    K I L L E R S
    _______________________________________________________________
    \__  ____________  _____    ________    ____  ____   __  _____/
     \ \ \    /\    / /    / /\ \       | \ \  | |    | | / /    /
      \ \ \  /  \  / /    / /__\ \      | |\ \ | |    | |/ /    /
       \ \ \/ /\ \/ /    / ______ \     | | \ \| |    | |\ \   /
        \_\  /__\  /____/ /______\ \____| |__\ | |____| |_\ \_/
         \___________________________________________________/
          \                                                 /
           \    Your System Has Been Officically WANKed    /
            \_____________________________________________/
 
     You talk of times of peace for all, and then prepare for war.
 
7. If it has SYSPRV, it disables mail to the SYSTEM account.
 
8. If it has SYSPRV, it modifies the system login command procedure to
APPEAR to delete all of a user's file. (It really does nothing.)
 
9. The program then scans the accounts logical name table for command
procedures and tries to modify the FIELD account to a known password
with login form any source and all privs. This is a primitive virus,
but very effective IF it should get into a privileged account.
 
10. It proceeds to attempt to access other systems by picking node numbers at
random. It then used PHONE to get a list of active users on the remote system.
It proceeds to irritate them by using PHONE to ring them.
 
11. The program then tries to access the RIGHTSLIST file and attempts
to access some remote system using the users found and a list of
"standard" users included with the worm. It looks for passwords
which are the same as that of the account or are blank. It records all
such accounts.
 
12. It looks for an account that has access to SYSUAF.DAT.
 
13. If a priv. account is found, the program is copied to that account and
started. If no priv account was found, it is copied to other accounts found on
the random system.
 
14. As soon as it finishes with a system, it picks another random system and
repeats (forever).
 
Response:
 
1. The following program will block the worm. Extract the following code
and execute it. It will use minimal resources. It create a process named
NETW_BLOCK which will prevent the worm from running.
-------
Editors note:  This fix will work only with this version of the worm.
Mutated worms will require modification of this code; however, this
program should prevent the worm from running long enough to secure
your system from the worms attacks.
-------
==============================================================================
$ Set Default SYS$MANAGER
$ Create BLOCK_WORM.COM
$ DECK/DOLLAR=END_BLOCK
$LOOP:
$ Set Process/Name=NETW_BLOCK
$ Wait 12:0
$ GoTo loop
END_BLOCK
$ Run/Input=SYS$MANAGER:BLOCK_WORM.COM/Error=NL:/Output=NL:/UIC=[1,4] -
    SYS$SYSTEM:LOGINOUT
==============================================================================
 
2. Enable security auditing. The following command turns on the MINIMUM
alarms. The log is very useful in detecting the effects of the virus left by
the worm. It will catch the viruses modification of the UAF.
$ Set Audit/Alarm/Enable=(ACL,Authorization,Breakin=All,Logfailure=All)
 
3. Check for any account with NETWORK access available for blank passwords or
passwords that are the same as the username. Change them!
 
4. If you are running VMS V5.x, get a copy of SYS$UPDATE:NETCONFIG_UPDATE.COM
from any V5.2 system and run it. If you are running V4.x, change the username
and password for the network object "FAL".
 
5. If you have been infected, it will be VERY obvious. Start checking the
system for modifications to the FIELD account. Also, start scanning the system
for the virus. Any file modified will contain the following line:
$ oldsyso=f$trnlnm("SYS$OUTPUT")
It may be in LOTS of command procedures. Until all copies of the virus are
eliminated, the FIELD account may be changed again.
 
6. Once you are sure all of the holes are plugged, you might kill off
NETW_BLOCK. (And then again, maybe not.)
 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 
If you have any technical questions or have an infected system, please
call the CERT:
 
Computer Emergency Response Team
Email: cert@sei.cmu.edu
Telephone: 412-268-7090 (answers 24 hours a day)
 
 
If you have any general questions, please call the SCC:
 
Security Coordination Center
Email: scc@nic.ddn.mil
Telephone: 1-800-235-3155 or 415-859-3695 (7 a.m. to 5 p.m. Pacific time).
 
-------
 
-------------END OF FORWARDED MESSAGE(S)-------------

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      Wed, 18 Oct 89 15:25:34  +0100
From:      <AZ957%DK0RRZK0.BITNET@CUNYVM.CUNY.EDU>
To:        aix-l@pucc, tcp-ip@sri-nic.arpa
Subject:   AIX-PS/2 and 3COM ethernet cards
We just have the opportunity to test AIX version 1.1 on a IBM PS/2 Model
80 and have some problems with the ethernet connection.
We learned from IBM that they only support an ethernet adapter from
Ungermann-Bass, in the machine however we have one from 3COM
(Etherlink/MC or 3C523), because it otherwise belongs to a local
PC-Net with 3COM net software.
Does anybody know if it is possible to get an ethernet driver for AIX
either from 3COM direct or from some other source?
I know that it would be best to ask 3COM themselves, but I have also
difficulties to find a technical support person from that company over
here in Germany.

Jochen Roderburg
Regional Computing Center
University of Cologne         Tel. :   +49-221/470-4564
Robert-Koch-Str. 10           BITNET:  A0045 @ DK0RRZK0 (CDC NOS/BE)
D-5000 Koeln 41                    or  A0045 @ DK0RRZK1 (IBM VM/CMS)
West Germany                       or  AZ957 @ DK0RRZK0 (Siemens SINIX)
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 89 17:25:28 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re: 'shutdown' vs. 'close' to free resources?


	UNIX's shutdown(2) corresponds to the TCP ABORT function and is NOT
generally a good way to free socket resources, unless you have another way of
determining (through the upper level protocol) that no more data need be sent.
	In particular, if you do a shutdown(2) after you've written your data,
if the data is still in a kernel buffer on your end waiting to be sent, it will
be discarded and the other guy will never see it. Close(2) is the only way to
guarantee delivery of all pending written data short of doing this in the upper
protocol.
	In other words, close(2) isn't hanging onto everything just to be mean
to you... :-) It's where some of TCP's reliability comes from.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 89 18:43:32 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   Router interoperability


   Date: 	Tue, 17 Oct 89 17:42:00 EDT
   From: <FILLMORE%EMRCAN.bitnet@ugw.utcs.utoronto.ca>

   I have a (perhaps naive) question about the interoperability of routers:

This question is not really naive, in fact there is a real deep
understanding of "compatability" involved.

   We want to join Ethernet LANs in two different cities with a 56kbps sync
   line.  The LANs run a variety of protocols such as XNS, TCP/IP, Decnet.
   We want to use routers at each end of the line.  Do the two routers
   have to be from the same manufacturer?  If so, why?  One of the routers
   is a Cisco box but the other could be Proteon or some other make
   (or does it have to be a Cisco?).

The simple answer is that TODAY the two gateways at opposite ends of a
serial line have to be from the same company.  Presently the framing
used on serial lines by the various gateways is different.  There are
a few standards for this, but they aren't comprehensive enough.  Each
vendor had some feature or facility they needed to support which did
not fit and they each developed a framing system independantly.  This
means the framing is not compatible.

There is presently a Working Group within the IETF (the Point-to-Point
Protocol [PPP] WG) which is addressing this problem and it should be
issuing an RFC RSN.  Drew Perkins gave a presentation on the protocol
at InterOp '89.  When this gets finalized all (most?) of the gateway
vendors will be implementing it so that you can mix them as you
describe, but it won't be possible before then.

	    __
  /|  /|  /|  \		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. :-)

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 89 20:14:24 GMT
From:      cochrane@TIS.COM (Pam Cochrane)
To:        comp.protocols.tcp-ip
Subject:   TMail System

Trusted Information Systems (TIS) has developed the Trusted Mail
System (TMail) as part of a DARPA sponsored research project.  TMail 
is a prototype privacy enhanced mail system designed to investigate 
embedded cryptography within a trusted system.  It was based on the
message processing procedures described in RFC 1040.  At the request
of DARPA and the Privacy and Security Research Group (PSRG), TIS is
planning to modify the TMail system to be compliant with the recently 
released RFC 1113, RFC 1114 and RFC 1115 and to make it available to 
the Internet.  We are working closely with RSADSI and BBN with respect
to the release of TMail and other software necessary to support  
message processing and the key management procedures described in 
the RFCs.

The TMail system has been incorporated into the Rand Message
Handling System.  It runs on Sun Workstations using SunOS (UNIX).
We are currently in alpha testing between our East and West coast
offices and with NIST.  We are planning to release the system to 
the PSRG members for beta testing before the end of the year.  This
requires some modifications to the TMail software and packaging the
system for release.  Release to the general public is planned for
early 1990.

For further information contact:

		Pamela Cochrane
		Trusted Information Systems
		3060 Washington Road (Rt. 97)
		Glenwood, Md. 21738

		cochrane@tis.com

-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 89 20:43:31 GMT
From:      michaud@decvax.dec.com (Jeff Michaud)
To:        comp.protocols.tcp-ip
Subject:   Re: 'shutdown' vs. 'close' to free resources?

> Close(2) is the only way to
> guarantee delivery of all pending written data short of doing this in
 the upper
> protocol.

	Note that, at least in the OSI model, transport isn't really the right layer
	to do "orderly release".  "Orderly release" is a job for the OSI
Session layer.
	Since on the IP stack we really don't have a Session layer, it should be done
	in another higher layer (ie. the application protocol).  For example, both
	FTP and SMTP have an explicit release handshake.

/--------------------------------------------------------------\
|Jeff Michaud    michaud@decwrl.dec.com  michaud@decvax.dec.com|
|DECnet-ULTRIX   #include <standard/disclaimer.h>              |
\--------------------------------------------------------------/

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 89 20:46:30 GMT
From:      bernstei@hpuxa.ircc.ohio-state.edu (Dan Bernstein)
To:        comp.mail.misc,news.admin,comp.protocols.tcp-ip
Subject:   Pilot Project: Hosts Table To Be Available Over Internet

As a pilot project, we are going to make available to the Internet a
hosts table. Please note that this project is not an official project of
The Ohio State University.

Sites with reliable name server access should not need this table.

To reduce network load we plan to distribute the table in stages. If you
administer an FTP site or would like to help distribute the table in other
ways, type ``telnet 128.146.1.5 5555'' and fill out the questionnaire.
We hope to organize distribution within a week and prepare the FTP sites
in a few days.

The hosts table is compiled from public information only, by automatic
methods; approximately 96% of its information was culled from the Domain
Name Server system. For the moment we will not accept changes, additions,
or corrections to the table. The hosts table will remain reasonably static.

As of October 18, the table contains over one hundred thousand Internet
addresses and host domain names. It uses several megabytes of disk space.
The Internet is estimated to have between 120,000 and 150,000 hosts, so
the table is reasonably complete. However, we do not guarantee accuracy,
reliability, or completeness.

Mail any lengthy comments to this address. If you complain about the
operation of the table, make sure to suggest something better.

---Dan Bernstein, brnstnd@acf10.nyu.edu, bernstei@hpuxa.ircc.ohio-state.edu

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      18 Oct 89 21:18:03 GMT
From:      jbvb@ftp.COM (James Van Bokkelen)
To:        comp.protocols.tcp-ip.ibmpc,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   FTP Software LANWatch customer-written parsers solicited

Any LANWatch users who have written parsers or post-processing programs
that would be of general interest and want them included in a supported
release should get in touch with me (jbvb@ftp.com).  The next one uses
MSC 5.1 medium model, so size is much less of a problem.


-- 
James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 89 02:21:06 GMT
From:      shevett@labii.UUCP (Dave Shevett)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.sys.ibm.pc
Subject:   PC-NFS - What is it?

I've seen mention of a package called 'PC-NFS' floating around in various
net.groups, and I'm curious about it.

We've just come upon a problem at work where we need to get files back and
forth from an SCO Xenix system (about 15-25 users) to a Wang VS.  There is
a program for the VS to move files to a PC hard drive via a serial link.
That's no problem.  Can I use PC-NFS to make those files available to the
SCO system like a Unix NFS system?  

Example:
	The VS downloads a file to the PC (unattended), and the file appears on
	the PC as FILE.MOO in D:\

	The SCO system references that file as /usr/PC1/d/file.moo and copies
	via ethernet onto the Unix box.

Can this work?  Can I make a PC hard drive accessible via NFS from a Unix
box?

Question 2 - what does this kind of system (PC-NFS) do to the performance
of the PC (is it a background program, or do I run PCNFS, and the machine
is permanently linked to its Ethernet card?)

This are not just idle thoughts - My customer is keen to make sure this
can work...

/--------------------+ 'The shortest distance +------------------\
|    Dave Shevett    |  between two puns is a | Labyrinth II BBS |
| shevett@labii.UUCP |  straight line...'     |  W. Trenton, NJ  |
\--------------------+       - Doc Webster    +------------------/

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 89 06:54:15 GMT
From:      gnu@hoptoad.uucp (John Gilmore)
To:        comp.protocols.tcp-ip
Subject:   Re: Fax over tcp/ip

sl@van-bc.UUCP (Stuart Lynne) wrote:
> I would suspect that if a fax transfer standard is implemented it should 
> involve a handshake at the beginning where each end tells the other what 
> it understands. Then if you have a format which the other end doesn't 
> understand you know you have to convert before sending otherwise you just 
> send it.

Clearly what we want on the Internet is more like what computer fax
over phone lines should be doing (except that the designers of fax
didn't think about extensibility, and the people who implement it are
too busy (hacking slimy binary MSDOS software) to support real
computers or consider the larger issues).  You should hand it a
document in ANY format; it sends it to the recipient in the recipient's
choice of format.  E.g. you hand it troff source; if the recipient can
handle troff source, it gets sent that way; backoffs to ditroff
intermediate form, PostScript, MacDraw, HPGL, bitmaps, G3 and G4 fax,
etc, are all possible depending on what the recipient can handle.  This
has to be negotiated separately for each recipient, since one could be
a phone-fax relay service and another a window system or something.

Note that data modems have the same sort of problem:  when answering a
call, the two modems need to negotiate to decide what mutually agreeable
protocol will be used over the line.  Current modems use a horrid solution:
try one, wait a while, try another, ...  burning billable time at your
expense.  A better solution would have been to send a burst of touchtone
digits, each digit pair or triple indicating a supported protocol.
The other side would send its best choice among them and it all happens in a
second or two.  (This protocol is stolen from the uucp startup sequence.)

For tcp/fax negotiations I'd define a standard set of format names in
ASCII, rather than using numeric codes; it's easier to use and extend a
set of names.  Also, we probably want to send more information during
the negotiation, like the file name and size, sender's identification,
etc, so the recipient can use the info in deciding what format to
request (e.g. if I know that I get a message weekly from you, and it
works best in PostScript, I can set up to request PostScript from you
even though you are supplying it in TeX).
-- 
John Gilmore      {sun,pacbell,uunet,pyramid}!hoptoad!gnu      gnu@toad.com
		"Watch me change my world..." -- Liquid Theatre

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 89 08:28:33 GMT
From:      colin@tenset.UUCP (Colin Manning)
To:        comp.protocols.tcp-ip
Subject:   email address for Jon Postel


Could someone give me Jon Postel's up to date email/postal address.

Thanks,

- Colin
-- 
-----------------------------------------------------------------------
| colin@tenset.uucp or        | Post: Tenset Technologies Limited,    |
|  ..!ukc!acorn!tenset!colin  |       Norfolk House,                  |
| Phone: +44 223 328886       |       301 Histon Road,                |
| Fax:   +44 223 460929       |       Cambridge CB4 3NF, UK.          |
-----------------------------------------------------------------------

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 89 10:26:41 GMT
From:      mrose@CHEETAH.NYSER.NET (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for SNMP

> there are atleast three public domain snmp implementations: mit's,
> cmu's and nysernet's (agent only).

Just as a clarification:  NYSERNet has a proprietary implementation of
the SNMP which consists of an agent along with many, many tools for
running a network management station.  In addition, a second, completely
independent implementation of an SNMP agent was done for 4BSD/OSI under
partial support from US DARPA.  This latter work is what Hein{nen Juha
means by "nysernet's (agent only)". 

It is important not to confuse the two as they serve entirely different
purposes:

    -   As with all NMS implementations, the NYSERnet proprietary
	implementation is there to provide NMS functionality to manage
	your network.

    -   In contrast, the 4BSD/OSI implementation (which appears in the
	next release of the ISODE), was written in order to maximize the
	number of hosts in the Internet that are network manageable.
	Since Berkeley UNIX tends to be what the majority of platforms
	are based on, producing an agent for 4BSD should help in this regard.
	A number of people felt that network managability was such a 
	critical problem, that this mandated the generation of an openly
	available implementation of an SNMP agent that would work with
	the next release of BSD UNIX (whenever that is).  Since that
	release will contain OSI protocols, it was also felt that
	support for managing those protocols with the SNMP would also be
	a good thing.  So, (in my opinion) NYSERNet did a very
	forward-thinking thing by allowing me to write an SNMP agent for
	4BSD/OSI and then put it in the ISODE.

    -	I hear lots of good things about both the MIT and CMU public
	domain implementations of the SNMP, which both include an agent
	and NMS tools.  These are meant to be highly portable
	implementations which vendors (among others) can deploy on
	various platforms.  As such, they really serve a different
	purpose than the 4BSD/OSI implementation of the SNMP.

/mtr

ps: this is only one of many forays the SNMP crowd--a large collection
of people from all walks of life (researchers, users, providers,
vendors) and with all kinds of interests (routers, workstations,
bridges, concentrators, etc.)--will be engaging in over the next year.
Look for the SNMP to be at the center of dozens of interesting
management solutions as people start getting together to solve various
problems with network management.  (A shameless plug from the chair of
the SNMP Working Group!)

pps: I am sensitive to the "appropriate use" issue on the net, and was
very careful not to make this sound like an advertisement for my
employer.  But then again, when you do forwarding-thinking things, a
little praise should be forthcoming.

/mtr

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 89 14:37:52 GMT
From:      mstar!mstar.morningstar.com!bob@tut.cis.ohio-state.edu  (Bob Sutterfield)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet
In article <353@nisca.ircc.ohio-state.edu> bernstei@hpuxa.ircc.ohio-state.edu (Dan Bernstein) writes:
   As a pilot project, we are going to make available to the Internet
   a hosts table.

It's been done before, and the idea discarded as unworkable.

   Sites with reliable name server access should not need this table.

Sites without reliable name server access should get reliable name
server access.

   To reduce network load we plan to distribute the table in stages.

The name server system is designed to (among other things) reduce
network load by distributing only the parts of the name and number
space that an individual user needs, at the time she needs it.

   For the moment we will not accept changes, additions, or
   corrections to the table. The hosts table will remain reasonably
   static.

That means it's already outdated, inaccurate, and misleading, and will
get more so unless you continually traverse the nameserver trees to
incrementally update your table.  Then at least the most recently
updated sections will be correct for a little while.  Still, how do
you intend to re-broadcast the updated sections?  Hmmm, sounds like a
name service system, eh?

   ...we do not guarantee accuracy, reliability, or completeness.

You can't, with a static table.

   If you complain about the operation of the table, make sure to
   suggest something better.

I'd suggest ucbarpa.berkeley.edu:pub/4.3/bind.4.8.tar.Z.  If you're
running an operating system to which you can't manage to port a
resolver, persuade the company that sold the system to you to do one
for you.  Beat them over their collective heads with RFC1123 sections
5.3.5 and 6.1.1 until they succumb.  That's why it was written.

Really, this is a noble goal, but misdirected.  Better to spend the
programmer and administrator time, disk space, and net bandwidth
implementing a resolver.
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 89 15:20:28 GMT
From:      eli@spdcc.COM (Steve Elias)
To:        comp.protocols.tcp-ip
Subject:   Re: Fax over tcp/ip

In article <8734@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>
>Clearly what we want on the Internet is more like what computer fax
>over phone lines should be doing (except that the designers of fax
>didn't think about extensibility, and the people who implement it are
>too busy (hacking slimy binary MSDOS software) to support real
>computers or consider the larger issues).  

	i won't argue with you regarding the slimosity of DOS...

	but you are wrong that nobody is worrying about supporting
	real computers and addressing the larger issues.  these
	things are happening at MANY companies out there.  nobody
	appears to have announced anything yet, though.  


-- 
 ... Steve Elias (eli@spdcc.com);6178906844;6179325598; {}
 /* free email2fax!  send email for info. */

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 89 15:49:33 GMT
From:      jos@idca.tds.PHILIPS.nl (Jos Vos)
To:        comp.protocols.tcp-ip
Subject:   Info about TFTP and BFTP wanted (utilities, not protocols!)

Can anyone answer me (by mail) the following questions:

-  What UNIX implementations for TFTP do exist? Are they all interactive?

-  The same questions for BFTP.

-  Is BFTP based on a BFTP protocol or on the FTP protocol?

Thanks.

-- 
-- ######   Jos Vos   ######   Internet   jos@idca.tds.philips.nl   ######
-- ######             ######   UUCP         ...!mcvax!philapd!jos   ######

-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      Fri, 20 Oct 89 01:38:24 PDT
From:      cire|eric <cire@cisco.com>
To:        <FILLMORE%EMRCAN.bitnet@ugw.utcs.utoronto.ca>
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Router interoperability

Bob,

This is not at all a naive question.  Both routers have to currently
be from the same manufacturer.  That is because they are on the end
of a serial line and there currently isn't an agreed upon standard
for how to talk across these lines in general.  You could use X.25
and in some cases that would work for different vendor's equipment but
that is shall we say a less than optimal solution.

There is currently an effort under IETF auspices to standardize a decent
way of communicating and interoperating across serial lines.  It is called
the Point-to-Point Protocol (PPP) and should see light of day sometime
later this year or in 1990.  Cisco plans on supporting it and from what
I understand others will as well.

-c
cisco engineering
-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      19 Oct 89 19:13:31 GMT
From:      jmwobus@cmx.npac.syr.edu (John Wobus)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

In article <8910122223.AA06605@jessica.Stanford.EDU> almquist@JESSICA.STANFORD.EDU writes:
>	As one of the authors of the Host Requirements RFCs, I don't
>think that there was ever any intention that a host would be
>non-compliant simply because it didn't choose to support certain
>applications.  In my opinion, a host which doesn't support email is
>compliant with the SMTP requirements of RFC1122.  However, if the vendor
>claims a compliant implementation of SMTP, you can expect that he will
>meet the requirements put forth in the SMTP chapter (and also the
>chapters describing protocols needed to support SMTP, such as TCP, DNS,
>...).
>> Perhaps it could also address the different protocols below IP too.
>	The Host Requirements RFCs defer to the Gateway Requirements RFC
>for layers below IP (since these are the same for hosts and gateways).
>						Philip

Thanks.  That is how I should have said it.

I have two other comments on other follow-ups to my original comment:
(1) When I referred to source routing, I meant IP source routing rather
    than mail source routing.  However, I don't mind hearing discussion
    of mail source routing.
(2) I have been reassurred to hear some of the authors remind us that
    vendors will comply.  However, I remain uncomfortable that my
    original comment hasn't brought forth even ONE protestation from
    any vendor, either on the list or private.  Nor did I hear even
    one vendor promise more than an "attempt" at Interop.

John Wobus
Syracuse University

P.S. The more I look at RFCs 1122 and 1123, the more impressed I am.

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 89 02:24:57 GMT
From:      kwang@infmx.UUCP (Kwang Sung)
To:        comp.protocols.tcp-ip
Subject:   ISODE-5.0

Hi.... there,

	1. Does anyone know how much works should be done on ISODE-5.0
	   with "SunLink 6.0" and "SunOS 4.0" for Sun-4 ???

	2. Does anyone have an "earthquake-resistant" car ???
	   I like to buy it.

      					Kwang Sung
					Informix Software, Inc
					415 / 926 - 6758
					UUCP: ...!uunet!infmx!kwang

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 89 08:38:24 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Re: Router interoperability


Bob,

This is not at all a naive question.  Both routers have to currently
be from the same manufacturer.  That is because they are on the end
of a serial line and there currently isn't an agreed upon standard
for how to talk across these lines in general.  You could use X.25
and in some cases that would work for different vendor's equipment but
that is shall we say a less than optimal solution.

There is currently an effort under IETF auspices to standardize a decent
way of communicating and interoperating across serial lines.  It is called
the Point-to-Point Protocol (PPP) and should see light of day sometime
later this year or in 1990.  Cisco plans on supporting it and from what
I understand others will as well.

-c
cisco engineering

-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 89 13:25:39 GMT
From:      dasa@vax87.aud.auc.dk (Sren Andersen, Aalborg Universitets Datacenter)
To:        comp.protocols.tcp-ip
Subject:   Re: FTP (the company, not the protocol) required

In article <39700@bu-cs.BU.EDU>, madd@bu-cs.BU.EDU (Jim Frost) writes:
> In article <46653@bbn.COM> wbe@BBN.COM (Winston Edmond) writes:
> |Try:	FTP Software, Inc.
> |	501 Cambridge St.
> |	Cambridge, MA  02141
> |	(U.S.) 617-868-4878 [phone]
> 
> They have moved, although I would be surprised if you couldn't find
> out to where by either mailing or calling the old address/number.
> Sorry but I don't have the new address.
> 
> jim frost
> madd@std.com


The address is

FTP Software. Inc.
26 Princess St.
Wakefield, MA 01880-3004
Internet: cws@ftp.com(617) 246-0900

-- 
Sxren Andersen                               X.25    :  23830212124500::dasa
Aalborg Universitets Datacenter              Internet:  dasa@vax87.aud.auc.dk
Strandvejen 19                               Tlf.    :  +45 98 13 87 88
DK 9000 Aalborg                              Fax     :  +45 98 11 70 16

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 89 13:49:58 GMT
From:      chan@dciem.dciem.dnd.ca (Kam Tim CHAN)
To:        comp.protocols.tcp-ip
Subject:   Internet Subnetting ...

I am in the process of setting up a new subnetting environment, and
I noted the following comment :

In RFC950 (Internet Standard Subnetting Procedure) : 
:      Special Addresses:
:
:         From the Assigned Numbers memo [9]:
:
:            "In certain contexts, it is useful to have fixed addresses
:            with functional significance rather than as identifiers of
:            specific hosts.  When such usage is called for, the address
:            zero is to be interpreted as meaning "this", as in "this
:            network".  The address of all ones are to be interpreted as
:            meaning "all", as in "all hosts".  For example, the address
:            128.9.255.255 could be interpreted as meaning all hosts on
:            the network 128.9.  Or, the address 0.0.0.37 could be
:            interpreted as meaning host 37 on this network."
:
:         It is useful to preserve and extend the interpretation of these
:         special addresses in subnetted networks.  This means the values
:         of all zeros and all ones in the subnet field should not be
:         assigned to actual (physical) subnets.

However, I was thinking of using just 1 bit to be the subnet field,
therefore my subnet field is either all zero or all one. Would any one of
you comment on this special case issue, please ?

Thanks in advance.

Tim Chan
-- 
          Tim Chan, Systems Specialist  (416)-635-2073
     Defence and Civil Institute of Environmental Medicine
UUCP:   uunet!mnetor!dciem!chan or {decvax|ihnp4|watmath}!utzoo!dciem!chan
Internet:  chan@dretor.dciem.dnd.ca or chan%dretor@zorac.dciem.dnd.ca

-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 89 14:52:26 GMT
From:      sater@cs.vu.nl (Hans van Staveren)
To:        comp.protocols.tcp-ip
Subject:   Lifetime of routes added by redirects

I just noticed that on our Suns, running SunOS 4.0.3 dynamically added
routes are kept infinitely. This runs you into problems when gateways
change. Is this up-to-date software behaviour?

A little thought suggested the following protocol to me:

Each dynamically added route(by an ICMP redirect) is aged after a
reasonable time(10 minutes?) and the first packet after the age
is sent to the default router. Any new ICMP redirect for that route
replaces the current one, if no new one comes, when the gateway is down
for example you keep using the old one and try the default route every
say 100 packets.

Does this seem reasonable? Is something like this already in newer software?

	Hans van Staveren, Vrije Universiteit, Amsterdam, Holland

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 89 18:28:07 GMT
From:      medin@NSIPO.NASA.GOV ("Milo S. Medin" [NASA ARC NSI Project Office])
To:        comp.protocols.tcp-ip
Subject:   Re: Router interoperability


That's not exactly true.  I believe the routers will interoperate at
least for IP if you use X.25 as your serial line protocol.  Both 
Proteon and Cisco support X.25 framing now.  It's not a very nice
solution, but it should work. 

Both Proteon and Cisco have committed to implement PPP, and both
companies had active participation in the working group. 


						Thanks,
						   Milo

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 89 18:39:37 GMT
From:      barns@GATEWAY.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

The HR RFCs don't seem to explicitly state that source routes are limited
to Internet-registered domains, but that was certainly the idea in mind.
The possibility of allowing non-Internet-registered names was brought
up and discussed quite a bit during the lengthy discussion of mail
source routing in the HRWG.  The mail source route discussion probably
constituted 10 or 15% of the total verbiage burning up the wires during
that effort.  I have a file containing most if not all of the relevant
messages which I hereby offer (not without misgivings) to mail to anyone
who wishes to read about 280KB on the subject.  I might edit it down a
bit first if I have some free time - not to remove the content on this
subject, but to strip out other topics from multi-topic messages.

A big part of the justification (or excuse, depending on your religion)
for sticking with Internet-registered names was a feeling that most of
the uses of the %-hack could be replaced by an appropriate usage of MX
records, including perhaps some strategically chosen wildcard MX's.
This theory holds that even if you're not on the Internet, you can
register yourself and get your name into some server with an MX pointing
to the appropriate gateway(s) for mail to your non-Internet network.
According to this reasoning, you don't actually need the % hack for
what (I think) Henry Spencer is talking about.

Perhaps there are objections to this.  Some people seem to object in
principle to universal registries; this leads back to the Absolute vs.
Relative issue, which is even older than TCP/IP.  RFC 733 defined a
sort of source route syntax using multiple @ characters; when some
people started using it, there were loud screams and (so I am told,
I wasn't working in the mail arena at the time so I can't speak from
direct knowledge) a meeting was called by or at DARPA at which it was
outlawed.  This was probably about 8 to 10 years ago - I've forgotten.
Anyhow, there is religion involved here, I think.

A different objection might be that it is difficult in practice, for
one reason or another, for the off-Internet people to get registered
with appropriate MX's.  I haven't heard this specific complaint, but if
it is a problem in practice, maybe the people hurt by it should speak
up, and perhaps something can be worked out eventually to improve matters.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 89 19:44:44 GMT
From:      merlin@smu.edu (David Hayes)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Terminal Servers

SMU is looking for recommendations on terminal servers.
The units must speak TCP/IP, but DEC LAT protocol would be
a help, also.  We want 48 ports total, in one or more units.
Modem control on these ports would be valuable, but is
not strictly required.

I'm particularly concerned that the host computers be able to
contact an output device, such as a printer, connected to one
of these terminal server ports.  I've no idea how this is
accomplished under TCP/IP.  Our workstations don't have enough
serial ports for all our printers, though, so we need to be
able to do this.

I'd appreciate any recommendations or experiences you want
to share.  I've already got cisco routers, so I'd lean towards
cisco terminal servers if all other considerations were equal.
I'm also thinking about Annex, Bridge, and DEC devices, though.
Please let me know how you're solving these problems,


David Hayes	School of Engineering	Southern Methodist University
merlin@smu.edu	uunet!smu!merlin
"Argue for your limitation, and, sure enough, they're yours." - Richard Bach

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 89 23:25:21 GMT
From:      fitz@wang.UUCP (Tom Fitzgerald)
To:        comp.protocols.tcp-ip,misc.wanted
Subject:   Anyone have Excelan TCP/IP code for Vax SysV.2?

Does anyone have the Excelan TCP/IP software for a Vax750 running
AT&T System V.2?  Excelan has stopped supporting it, and we need
some of the utilities which have disappeared off of our system.
(No, we can't upgrade to a better Unix.  I tried this already.)

This is Excelan product code 8015-01.  We have version 3.2 of the
software, but not everything works.  Version 3.3 is known to exist
(we have some of it, but not all) and later versions may as well.

Can anybody send any info or references on this?  You will get my
eternal gratitude at least - material rewards can be discussed.

---
Tom Fitzgerald   fitz@wang.com          There's nobody the government can't
Wang Labs        ...!uunet!wang!fitz    nail if it really goes after him.
Lowell MA, USA   1-508-967-5278         -- James Neal, Watergate prosecutor

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      20 Oct 89 23:44:49 GMT
From:      mx!cbcscmrs@csun.edu
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI/TCP-IP for Hammacher Schlemmer Chistmas Tree?

I heard from a friend that has one that he hooked up to his local net
that it causes massive problems with his routers.  After attaching a
$20,000 sniffer to his net he found that some illegally formatted packets
were coming from atnas.sualc.com.

In article <8910172205.AA23356@fernwood.MPK.CA.US> geoff@FERNWOOD.MPK.CA.US (the terminal of Geoff Goodfellow) writes:
|Does anyone have a FDDI interface and a TCP-IP driver for the Hammacher
|Schlemmer Fiber Optic Christmas Tree?  Could we have one on the Show and
|Tel-Net next year?  I quote from the recent catalog which arrived this
|morning's mail:
|
|	THE ONLY FIBER OPTIC CHRISTMAS TREE
|
|	A Hammacher Schlemmer exclusive, this white Christmas tree is enhanced
|	by advanced fiber optic lighting technology.  Two light sources
|	encased at the base of the tree project through revolving colored
|	filters to separate optic fibers cabled evenly among the branches.
|	The fiber cables end in 200 glittering lights, each containing a
|	spectrum of eight colors that change continuously, for a vision of
|	great warmth and brilliance.  No lights to strings.  Shipped assembled
|	--just lower the branches.  Transformer uses standard outlet.
|	Height: 6'.
|
|	37814W .............................. Postpaid $6500.00
|
|Geoff Goodfellow
|Anterior Technology

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 89 02:42:33 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: Lifetime of routes added by redirects

The host requirements RFCs addresses this point, but the issue is far
from settled.  Basically, they call for hosts to implement some sort
of dead gateway detection code; the route should be squashed at such
times.  If the gateways, negotiating amidst themselves, decide that
a different gateway is now better -- and each gateway is assumed to
know such things -- then the old gateway will send out a new redirect
message.  (Dead gateways can be detected by things like the sudden absence
of ACKs to TCP.)

Personally, I'm not completely convinced.  Dead gateway detection
is often hard, and other factors, notably security considerations,
make me less than fond of redirects in the first place.  But the
RFCs are certainly the place to start.

-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Oct 89 08:03:57 CDT
From:      Mike Rackley <RACKLEY%MSSTATE.BITNET@CORNELLC.cit.cornell.edu>
To:        <TCP-IP@SRI-NIC.ARPA>
Subject:   Re: FDDI/TCP-IP for Hammacher Schlemmer Chistmas Tree?
You will probably want an SNMP agent also.

Mike Rackley                         |  Rackley@MsState.BITNET
Mgr. Systems & Networks Programming  |  Rackley@CC.MsState.EDU
P.O. Drawer CC                       |  Phone:   (601)325-2942
Mississippi State, MS 39762          |  FAX:     (601)325-3299
-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 89 04:23:37 GMT
From:      nisca.ircc.ohio-state.edu!hpuxa.ircc.ohio-state.edu!bernstei@tut.cis.ohio-state.edu  (Dan Bernstein)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Hosts Table Distributors: Mail Questionnaire
We apologize for the interruption in service on hpuxa's port 5555.
If you want to help distribute the hosts table, please fill out the
questionnaire below and send it to bernstei@hpuxa.ircc.ohio-state.edu
with subject !HQ. Thanks.

---Dan Bernstein, bernstei@hpuxa.ircc.ohio-state.edu

Host domain name (e.g., uunet.uu.net): 
Host Internet address (e.g., 192.48.96.2): 
Username (e.g., root): 
Real name: 
Position: 
The hosts table includes over a hundred thousand hosts.
It takes up several megabytes.
Where and how do you plan to distribute the table?
And how do you plan to keep network load low?

Any further comments?
-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      Sat, 21 Oct 89 12:09:54 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   SUBSCRIPTION
I have lost my previous supplier of this mailing list.
Could you please subscribe me at my new address.

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 1989 14:16-EDT
From:      CERF@A.ISI.EDU
To:        FILLMORE%EMRCAN.bitnet@UGW.UTCS.UTORONTO.CA
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re:  Router interoperability
Today it is a likely that you would need routers from the same
vendor, linked by pt-pt channel to provide you the multiprotocol
functionality you want. The IAB and IETF are working towwards the
development of an Internet standard for multiprotocol routing
which could be supported by all vendors of routers.

Vint Cerf

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 1989 15:24-EDT
From:      CERF@A.ISI.EDU
To:        mstar!mstar.morningstar.com!bob@TUT.CIS.OHIO-STATE.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet

Folks, 

with my IAB hat on, I STRONGLY endorse every effort to move
to a Domain Name System basis as soon as possible. As we 
begin to introduce connections to outside email systems
like CompuServe, Telemail, MCI Mail, etc. and introduce X.400
facilities, we are going to need DNS more than ever.

If I thought there was a way to enforce it, I'd vote for
a ban on use of host tables after July 4, 1990 (Independence Day!).

Vint Cerf
-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 1989 15:52-EDT
From:      CERF@A.ISI.EDU
To:        mcsun!ukc!acorn!tenset!colin@UUNET.UU.NET
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: email address for Jon Postel
postel@isi.edu


-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 89 13:03:57 GMT
From:      RACKLEY@MSSTATE.BITNET (Mike Rackley)
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI/TCP-IP for Hammacher Schlemmer Chistmas Tree?

You will probably want an SNMP agent also.

Mike Rackley                         |  Rackley@MsState.BITNET
Mgr. Systems & Networks Programming  |  Rackley@CC.MsState.EDU
P.O. Drawer CC                       |  Phone:   (601)325-2942
Mississippi State, MS 39762          |  FAX:     (601)325-3299

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 89 14:44:09 GMT
From:      km@mathcs.emory.edu (Ken Mandelberg)
To:        comp.protocols.tcp-ip
Subject:   TCPDUMP for SunOS 4.x?

Is there a version of TCPDUMP for SunOS 4.x yet? 

If not is there any other PD monitoring software that will
run on 4.0 that details NFS packets?

(We also have NeXT and A/UX machines in case there is
something similar for those).
-- 
Ken Mandelberg      | km@mathcs.emory.edu          PREFERRED
Emory University    | {decvax,gatech}!emory!km     UUCP 
Dept of Math and CS | km@emory.bitnet              NON-DOMAIN BITNET  
Atlanta, GA 30322   | Phone: (404) 727-7963

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 89 17:09:54 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   SUBSCRIPTION

I have lost my previous supplier of this mailing list.
Could you please subscribe me at my new address.

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 89 18:16:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Router interoperability

Today it is a likely that you would need routers from the same
vendor, linked by pt-pt channel to provide you the multiprotocol
functionality you want. The IAB and IETF are working towwards the
development of an Internet standard for multiprotocol routing
which could be supported by all vendors of routers.

Vint Cerf

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 89 18:40:58 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   Router interoperability


   Date: Fri, 20 Oct 89 11:28:07 -0700
   From: "Milo S. Medin [NASA ARC NSI Project Office]" <medin@nsipo.nasa.gov>

   That's not exactly true.  I believe the routers will interoperate at
   least for IP if you use X.25 as your serial line protocol.  Both 
   Proteon and Cisco support X.25 framing now.  It's not a very nice
   solution, but it should work. 

That's not my understanding.  They both use X.25 framing to set off
the packets on the line, but they use different encapsulation to
provide header compression, protocol identification, etc.  This is
sort of analogous to ISO 802.3 vs Ethernet V2.  They are electrically
compatable and the low level framing is the same, but if one machine
speaks 802.3 and another speaks only Ethernet V2, they won't
communicate.  Packets sent by one are rejected as mal-formed by the
other.

   Both Proteon and Cisco have committed to implement PPP, and both
   companies had active participation in the working group. 

That's correct.  Basically the design of PPP is intended to give
enough flexibility to let them have any special handling they need and
a compatable framework to allow any two machines to work together with
whatever common features they implement.

	Mike Patton

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 89 19:24:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet


Folks, 

with my IAB hat on, I STRONGLY endorse every effort to move
to a Domain Name System basis as soon as possible. As we 
begin to introduce connections to outside email systems
like CompuServe, Telemail, MCI Mail, etc. and introduce X.400
facilities, we are going to need DNS more than ever.

If I thought there was a way to enforce it, I'd vote for
a ban on use of host tables after July 4, 1990 (Independence Day!).

Vint Cerf

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 89 19:52:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: email address for Jon Postel

postel@isi.edu

-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 89 22:56:25 GMT
From:      bernstei@hpuxa.ircc.ohio-state.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet

In article <[A.ISI.EDU]21-Oct-89.15:24:28.CERF>
CERF@A.ISI.EDU (Vint Cerf) writes:
> I STRONGLY endorse every effort to move
> to a Domain Name System basis as soon as possible.

We also encourage all sites to move to a distributed database if possible.
Our hosts table is aimed at sites that do not have reliable DNS access.

---Dan Bernstein, bernstei@hpuxa.ircc.ohio-state.edu

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      21 Oct 89 23:22:04 GMT
From:      wiltzius@lll-lcc.UUCP (Dave P. Wiltzius)
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP sources


I retrieved some PD SNMP software from the following:
CMU @ lancaster.andrew.cmu.edu (128.2.13.21)
MIT @ allspice.lcs.mit.edu

Both FTPable from pub, etc.
  Dave (wiltzius@lll-lcc.llnl.gov)

-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 89 02:12:53 GMT
From:      medin@NSIPO.ARC.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet


This doesn't make sense.  Let's say you go out and map out the whole
Internet DNS space by walking the tree (let's ignore the problem of
servers who refuse zone XFER requests for now).  You may have the
equivalent of all the A records in the DNS, but you have missed out
on all the MX records out there that many domains depend upon for
proper mail transfer.

As an example, you can send mail to user@host.span.nasa.gov, and that
points to an Internet<->DECNET mail relay.  There are oodles of hosts
that are serviced by this relay, and the DNS doesn't know anything
about those DECNET machines out there, so you can't get that information.

There are also many sites who have MX records that point to a mail relay
machine for local internal distribution.  Even for hosts that are 
Internet capable, but may not have advanced or properly configured mailers.
In this case, you'll try and deliver directly rather than go through the
relay like a DNS capable system would have.  

The DNS does more than just hosttable functionality.  People even use this
functionality!  If the host doesn't support DNS functionality, don't
attempt to use it as a general purpose Internet host.  Certainly,
don't attempt to mail from it!  Most major hardware vendors support the DNS.
I can't think of any that have no support.  Even the PC's and Mac's support
it.  Just exactly what systems out there are you trying to build this for?
DNS support is required, not just recommended.  Building in resolver
support is trivial if you have UDP support.  You can use some nameserver
out there on a real machine if you can't run one yourself.

This seems like a very bad idea, not just because it goes against current
good practices, but that people may actually think they can get by
with this, because the tables puportedly have all the hosts in them.  We have
enough problems to debug in the Internet already.  We don't need needless
ones.

						Thanks,
						   Milo

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 89 09:40:13 GMT
From:      carlson@uxh.cso.uiuc.edu
To:        comp.protocols.tcp-ip
Subject:   Re: Internet Subnetting ...


(This is a perfect example of quoting ASCII documents; 
I couldn't do this with a PostScript file!)

RFC1122                      INTERNET LAYER                 October 1989

            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.
	    ^^ ^^^^^ ^^^ ^^^^ ^^^^

Internet Engineering Task Force                                [Page 31]
--------------------
Brad Carlson  <carlson@mrcnext.cso.uiuc.edu> or <brad-carlson@uiuc.edu>
University of Illinois -- Consultant -- NeXT guru -- Windows Programmer

-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 89 16:57:04 GMT
From:      rick@UUNET.UU.NET (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet


	If I thought there was a way to enforce it, I'd vote for
	a ban on use of host tables after July 4, 1990 (Independence Day!).

Get DCA (or whoever) to have the NIC stop providing hosts.txt and
you'll make a hell of an impact.

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 89 17:56:06 GMT
From:      RAF@CU.NIH.GOV ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  New Host-Requirement RFCs

> A different objection might be that it is difficult in practice, for
> one reason or another, for the off-Internet people to get registered
> with appropriate MX's.  I haven't heard this specific complaint, but if
> it is a problem in practice, maybe the people hurt by it should speak
> up, and perhaps something can be worked out eventually to improve matters.

Much of BITNET does not support domain addressing (and therefore cannot
register with MXs) and is not likely to in the near future.  Many
people, including me, would like to see it happen.  Unfortunately there
are quite significant problems to be overcome and few resources to
overcome them.  Defacto standards on BITNET support domain addressing
for mail, but there's no standard protocols for domain addresses with
file transfer and interactive messages.

Why not, you may say, just do away with BITNET?  Well, BITNET, EARN,
and NETNORTH go to a lot of places that the Internet does not.  It's
easier and cheaper for some machines (mainly, but not entirely, IBM
mainframes) to connect to BITNET.  And BITNET has services, primarily
the sender-initiated file transfer and interactive messages, that
aren't available on the Internet.  LISTSERV makes use of these
functions to offer services that would be difficult to duplicate on the
Internet.  The point is that BITNET and related networks, while not
without their problems, provide a number of useful services that the
Internet currently does not.

That's not to say that the Internet could not provide those functions,
but little interest has been shown so far in doing so.  So, for the
time being, we'll stay connected to BITNET and continue to work on
getting our Internet connection to work better so that our users can
make use of what each network does best.  Perhaps the recent merger of
BITNET and CSNET will help the networks to move closer together.

Roger Fajman
RAF@CU.NIH.GOV  (Internet)
RAF@NIHCU  (BITNET)

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 89 21:08:56 GMT
From:      ESC1814@ESOC.BITNET (dave stafford)
To:        comp.protocols.tcp-ip
Subject:   Re: Router interoperability

Hi Milo,

Why isn't X.25 a nice solution? We use it between sites here
and it makes for a convenient solution, not only for routing
but to connect different flavours of routing devices.

Dave Stafford
Networking Eng.
European Space Operations Centre
Darmstadt, W. Germany

-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Sun, 22 Oct 89 20:54:58 SET
From:      dave stafford <ESC1814%ESOC.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Router interoperability
Hi Milo,

Why isn't X.25 a nice solution? We use it between sites here
and it makes for a convenient solution, not only for routing
but to connect different flavours of routing devices.

Dave Stafford
Networking Eng.
European Space Operations Centre
Darmstadt, W. Germany
-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      22 Oct 89 23:03:56 GMT
From:      phil@BRL.MIL (Phil Dykstra)
To:        comp.protocols.tcp-ip
Subject:   Re:  Pilot Project: Hosts Table To Be Available Over Internet

I used to joke that the Domain Name System was simply a way of replacing
an ever increasingly large disk file with an ever increasingly large chunk
of memory (named).  But seriously, the DNS is a necessary move to keep up
with the exponential growth of the InterNet.  Hosts that don't run it are
starting to lose more and more all the time.

However, keeping some version of a host table around, if only for user
information, is a good thing.  Sort of like the postscript debate, I can't
"grep" on the DNS, and I can't even count the number of times the DNS failed
but I could still get through by looking up and typing in dotted quads.

At BRL we run a script every night that converts our own domain tables,
along with hosts.txt, into /etc/hosts form for internal distribution.
When network problems arise and you want to traceroute or ping, that table
is indispensable.

- Phil
<phil@brl.mil>

-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 89 00:49:08 GMT
From:      roger@busmn.waiariki.ac.nz (Roger Hill)
To:        comp.unix.xenix,comp.protocols.tcp-ip
Subject:   SCO TCP/IP ARP

Followup-To:comp.unix.xenix


Hello all from down under.

I am using SCO TCP/IP (ver 1.0 beta) and am having a problem with ARP,
could somebody out there please help me.

 When trying to create an arp entry to have this host act as an
 Arp server ( arp -s mypc 0:0:c0:cf:c6:12 pub ) I get the following
 message:
    ioctl failed errno = 1
    mypc : Not owner

 Yes I did run this command as root, What is mypc not the owner of ?

I would be most interested in hearing from anybody else that is useing
SCO TCP/IP. Has anybody heard when a new release is due.

Many thanks in advance :-)

Roger ...

=- Roger Hill  Computer studies Tutor & System Administrator             -=
=- Snail mail: Waiariki Polytechnic, Private Bag, Rotorua, New Zealand   -=
=- Phone: work +64 73 468 999 , home +64 73 477 635                      -=
=- Dom: roger@waiariki.ac.nz  , Bang: uunet!vuwcomp!nzfc!mof!busmn!roger -=

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 89 01:27:47 GMT
From:      epsilon@wet.UUCP (Eric P. Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI/TCP-IP for Hammacher Schlemmer Chistmas Tree?

In article <8910172205.AA23356@fernwood.MPK.CA.US>
	geoff@FERNWOOD.MPK.CA.US (the terminal of Geoff Goodfellow) writes:
>Does anyone have a FDDI interface and a TCP-IP driver for the Hammacher
>Schlemmer Fiber Optic Christmas Tree?

Of course not, the HSFOCT uses an incompatible star topology.
The Fiber Optic Christmas Wreaths are another story entirely.

					-=EPS=-

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 89 13:31:12 GMT
From:      mep@AQUA.WHOI.EDU (Michael E. Pare)
To:        comp.protocols.tcp-ip
Subject:   Re:  TCP/IP Terminal Servers

A company called Datability puts out a terminal server that supports
either TCP/IP or LAT, and as of November will support both at the same
time.  They are the least expensive servers I've ever seen (with a
20% educational discount).  For more info you can call 1-800-342-5377.
Their RS232 cards come with either full modem support (8 ports per card)
or with RJ12 conectors (RS423 6 wire) for 16 or 32 ports per card.  A
chassis can hold up to 4 cards (up to 128 ports).  The network card
supports thick, thin or twisted pair (Synoptics) connections (jumper
selectable).

No, I'm not affiliated with them.  Just passing on the info.

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 89 16:01:34 GMT
From:      finco@ficc.uu.net (gary finco)
To:        comp.protocols.tcp-ip
Subject:   Re: Router interoperability

In article <89Oct17.165048edt.57354@ugw.utcs.utoronto.ca>, FILLMORE@EMRCAN.BITNET writes:
> I have a (perhaps naive) question about the interoperability of routers:
> We want to join Ethernet LANs in two different cities with a 56kbps sync
> line.  The LANs run a variety of protocols such as XNS, TCP/IP, Decnet.
> We want to use routers at each end of the line.  Do the two routers
> have to be from the same manufacturer?  If so, why?  One of the routers
> is a Cisco box but the other could be Proteon or some other make
> (or does it have to be a Cisco?).
> ________________________

After talking to both Cisco and Proteon about the same question,
I was told that it is recommended that the routers be from the
same manufacturer at both ends of the link.  The reason they gave
me was that they have their own data link implementation which
most likely will not match exactly with a different vendor's.  

I also feel that having one vendor per link will eliminate the
finger pointing that could arise from a failure to communicate.

Disclaimer:  I speak for myself and no one speaks for me.  

gjf

-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 89 17:02:14 GMT
From:      stev@VAX.FTP.COM (Stev Knowles)
To:        comp.protocols.tcp-ip
Subject:   Pilot Project: Hosts Table To Be Available Over Internet

*In article <[A.ISI.EDU]21-Oct-89.15:24:28.CERF>
*CERF@A.ISI.EDU (Vint Cerf) writes:
*> I STRONGLY endorse every effort to move
*> to a Domain Name System basis as soon as possible.
*
*We also encourage all sites to move to a distributed database if possible.
*Our hosts table is aimed at sites that do not have reliable DNS access.
*
*---Dan Bernstein, bernstei@hpuxa.ircc.ohio-state.edu
*
*

you would be better off expending effort to fix the problem rather
than kludging a symptom. if you cannot get *anything* better, you
*can* run BIND on a dedicated PC.

stev knowles
stev@ftp.com
617-246-0900

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Oct 89 17:07:33 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Router interoperability

In article <8910181843.AA23496@gaak.LCS.MIT.EDU> MAP@LCS.MIT.EDU (Michael A. Patton) writes:
>There is presently a Working Group within the IETF (the Point-to-Point
>Protocol [PPP] WG) which is addressing this problem and it should be
>issuing an RFC RSN...

Is there a current estimate of the first digit of the calendar year
in which the PPP RFC will appear?  It's been "presently a Working Group"
and "addressing this problem" and "RSN" for a longish time...
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 89 17:13:47 GMT
From:      hellier@skat.usc.edu (Chuck Hellier)
To:        comp.protocols.tcp-ip
Subject:   Verbose Domain listing

Does anyone have a current list of Domain names and their verbose
mappings (e.g. .usc.edu -> University of Southern California)?

Please eMail direct to me.

Thanks_In_Advance();

Chuck Hellier (hellier@skat.usc.edu)		For you are young and life
PC Systems Programmer				is long and there is time
University of Southern California	 	to kill today.

-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Mon, 23 Oct 89 17:38:55 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

In article <8910201839.AA29376@arcturus.mitre.org> barns@GATEWAY.MITRE.ORG writes:
>This theory holds that even if you're not on the Internet, you can
>register yourself and get your name into some server with an MX pointing
>to the appropriate gateway(s) for mail to your non-Internet network.
>According to this reasoning, you don't actually need the % hack...

The problem with this theory is that it doesn't really address the issue
of *inter*networking at all.  What it says is "join our network, then
there's no problem".  Defining the problem out of existence is not the
same as solving it.  At any time in the foreseeable future, there *will*
be unregistered sites that one wants to get mail to.  So the people in
charge of moving mail will continue to do what they've always done:  move
the mail, and ignore inconvenient RFCs that try to legislate a perfect
world.  The % hack, or something similar, remains necessary.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 89 18:06:15 GMT
From:      DKRUGER@vm.ucs.UAlberta.CA (Dwight Kruger)
To:        comp.protocols.tcp-ip
Subject:   3270 terminal support on ethernet

I have a large investment in IBM 3274 and 3174 controllers servicing three IBM
mainframes.  Attached to these controllers are approximately 1000 3270
terminals via Network Systems HYPERbus terminal network.  Network Systems
has informed us that they have frozen this product, we are therefore looking
for alternatives to replace HYPERbus.
 
In order to maintain our investment in 3274 and 3174 controllers and 3270
terminals, we are looking for alternatives which allow the controllers and
terminals to be attached to either ethernet or token ring.  In this scheme,
as with the existing HYPERbus terninal network, any terminal can dial all of
the IBM hosts.
 
                              +---------+  +---------+  +---------+
                              | IBM host|  | IBM host|  | IBM host|
                              +----+----+  +----+----+  +----+----+
  +----------+                     |            |            |
  |   user   |                +----+----+  +----+----+  +----+----+
  |   3270   |                |   3174  |  |   3174  |  |   3174  |
  | terminal |                |controllr|  |controllr|  |controllr|
  +----+-----+                +----+----+  +----+----+  +----+----+
       |                           |            |            |
  +----+-----+                +----+----+  +----+----+  +----+----+
  | magic box|                |magic box|  |magic box|  |magic box|
  +----+-----+                +----+----+  +----+----+  +----+----+
       |                           |            |            |
  =====+===========================+============+============+======
             ethernet   or   token-ring   (was HYPERbus)
 
Using this scheme, users on 3270 terminals can dial any IBM host.  I am aware
of IBM's token-ring card for their 3174 controller, however 3270 terminals
can not attach to token-ring.  Also, a remote 3174-3R controller forces us to
hard wire the 3270 terminals to it preventing the user from connecting to
multiple hosts.  We do not and cannot use VM passthrough.
 
Does anyone make a product for either ethernet or token-ring (shown as the
magic boxes in the above diagram) which would allow our 3270 terminals to
dial and connect to one of a family of IBM hosts via 3174 and 3274 controllers.
 
HYPERbus did this for us.

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 89 18:41:30 GMT
From:      deschon@VENERA.ISI.EDU (Annette DeSchon)
To:        comp.protocols.tcp-ip
Subject:   Re: Info about TFTP and BFTP wanted (utilities, not protocols!)

Jos,

BFTP uses the FTP protocol.  It is implemented in C, and it runs 
on various BSD systems.  You can get the source via anonymous FTP
from the "pub/" directory on venera.isi.edu.

--Annette

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 89 18:45:53 GMT
From:      deepak@hpindda.HP.COM (Deepak Sabnis)
To:        comp.protocols.tcp-ip
Subject:   TN3270 Help Request

Hi Folks,

TN3270 is a software package, which has been available from Berkeley
in the past. This package allows a IBM 3278 emulation on a UNIX machine
connected to the IBM host over Ethernet via a TCP-IP Telnet connection.
The front end to the IBM host is supposed to be a Fibronics box called
K-200 or a IBM 8232 Channel Adapter.

I have also heard that the software package is standard with BSD4.3
release. I have the following questions and will appreciate any help.

1. Is the software package really standard part of Telnet service
   on BSD 4.3?

2. Does it, or will it support color (i.e. support 3179G emulation).

3. Are there any plans to further enhance this, like making it work
   as a X11 client etc.

Any help will be greatly appreciated. Thanks.


Deepak S. Sabnis   ...!hplabs!hpda!deepak
Tel. (408)447-2947

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 89 20:08:55 GMT
From:      kent@tfd.UUCP (Kent Hauser)
To:        comp.protocols.tcp-ip
Subject:   How do you string a thinnet?


Beginners question:  How do you physically hook up a thinnet?
Specifically, how do you handle multiple BNC `T' connections.

1) Is it a bad idea to use a, say, 5-foot drop cable from the `T' to
the host?

2) Can you hang multiple hosts off in all directions from a `T'?

3) Does the cabling have to be a multiple of some magic length?

4) How can you test your network to see if you screwed something up?

5) Or, if you've only got 6 hosts & a couple of hundred feet of RG-58,
does it really not matter to much?

Now the $64k question: Is there a good reference for this kind of
info.

Thanks much in advance.

	Kent
-- 
Kent Hauser			UUCP: {uunet!cucstud, sun!sundc}!tfd!kent
Twenty-First Designs		INET: sundc!tfd!kent@sun.com

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 89 21:58:23 GMT
From:      cliff@violet.berkeley.edu (Cliff Frost)
To:        comp.protocols.tcp-ip
Subject:   Re:  New Host-Requirement RFCs

In article <8910231055.AA04607@alw.nih.gov> RAF@CU.NIH.GOV ("Roger Fajman") writes:
>> it is a problem in practice, maybe the people hurt by it should speak
>> up, and perhaps something can be worked out eventually to improve matters.
>
>Much of BITNET does not support domain addressing (and therefore cannot
>register with MXs) and is not likely to in the near future.  Many

Actually, any BITNET domain can register with the NIC and MX record
support will be supplied by UC Berkeley and Harvard U.  There are
currently 43 domains taking advantage of this--this is available for
BITNET and related nets; eg Singapore (*.SG), Taiwan (*.TW), etc.

As Rick Adams pointed out, though, it is far easier to deal with
the %-hack syntax.  Consider the problem faced by a mail
relay into the Internet (eg relay.x.edu):  It gets mail destined
for an Internet host, from node "JOE" on the non-internet side.

It can no longer just say it comes from user%JOE@relay.x.edu, nor
can it even say [@relay.x.edu:user@joe].  In order to be "correct"
it now has to figure out what is the Internet name of node "JOE", in
order to construct a return address like [@relay.x.edu:user@joe.foo.gov].
(I think I messed up the source route syntax, but I hope the idea
is clear.)

So, by requiring all names to be valid, registered names, you require
all mail relays to keep reverse MX tables for all their non-internet
nodes.  That might be a tremendous amount of extra work.

	Cliff Frost
	Central Computing Services
	UC Berkeley

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      23 Oct 89 22:43:23 GMT
From:      micky@cunixc.cc.columbia.edu (Micky Liu)
To:        comp.protocols.tcp-ip
Subject:   Client side bootp anywhere?

I am attempting to implement something similar to bootp and would appreciate
any pointers to any code/docs about the client side of bootp.  I have
read RFC951 and have the bootp server sources already.  Thank you for
your kind attention.

Micky Liu

  arpa: micky@cunixc.cc.columbia.edu
  uucp: ...!rutgers!columbia!cunixc!micky
bitnet: malua@cuvmc

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 89 01:11:22 GMT
From:      pasteur!agate!bionet!sdsu!usc!cs.utexas.edu!mailrus!jarvis.csri.toronto.edu!utgpu!utzoo!bnr-vpa!bnr-fos!bnr.ca@ucbvax.Berkeley.EDU  (Rick Wedge)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Encryption device for WAN
------------------------------------------------------------------------

Can anybody direct me to encryption devices for a WAN?  I know of
one available for 19.2 Kbps, but does one exist for T1 or 56 Kbps links?
I am interested in DES or other forms of encryption.

Please mail your responses directly to me and I will post a summary.

------------------------------------------------------------------------
Rick Wedge            
(613) 763-8730
WEDGE@BNR.CA
-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 89 02:51:50 GMT
From:      wiltzius@lll-lcc.UUCP (Dave P. Wiltzius)
To:        comp.protocols.tcp-ip
Subject:   CMU's PD SNMP

Due to my last posting I received several requests
for the PD SNMP sources from folks that cannot do
FTP.  Sorry that I can't oblige.  However, I did
find the following Email address to obtain info re
the 0.9 release of the CMU SNMP package (the README
made reference to Steve Waldbusser):
 sw0l+snmp@andrew.cmu.edu

  Dave (wiltzius@lll-lcc.llnl.gov)

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 89 14:41:00 PDT
From:      "MIKE ANELLO" <manello@bi1.simpact.com>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   IP over 802.5

	I have a question about running IP over 802.5. 

	RFC 1042 says that the largest frame field of the routing control bytes
	for source routing are as follows:

Postel & Reynolds                                               [Page 8]
RFC 1042            IP and ARP on IEEE 802 Networks        February 1988


         The RIF consists of a two-octet Routing Control (RC) field
         followed by 0 to 8 two-octet Route-Designator (RD) fields.  The
         RC for all-routes broadcast frames is formatted as follows:

                         0                   1
                         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |  B  |   LTH   |D|  LF |   r   |
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Note that each tick mark represents one bit position.

            LF - Largest Frame: 3 bits

               The LF bits specify the maximum MTU supported by all
               bridges along a specific route.  All multi-ring broadcast
               frames should be transmitted with a value at least as
               large as the supported MTU.  The values used are:

                       LF (binary)   MAC MTU      IP MTU

                           000          552         508
                           001         1064        1020
                           010         2088        2044
                           011         4136        4092
                           100         8232        8188

               All other values are reserved for future use.

	The TMS380 Adapter CHipset User's Guide Supplement uses the following:
		page 7-4

                         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |  B  |   LTH   |D|  LF   | r   |
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       LF (4 bits)  

                           0000         reserved
                           0001         upto 516 octets in the information field
                           0010         reserved
                           0011         upto 1500 octets in the info field
                           0100         reserved
			   0101		upto 2052 octets in the info field
                           0110         reserved
			   0111		upto 4472 octets in the info field
			   1000		reserved
			   1001		upto 8191 octets in the info field
			   1010 - 1110  reserved
			   1111		initial value of broadcast frames

	Does anyone know which values should be used for the LF bits and what
	IP MTU should be used?
	Is there a standard for 4-Mb Token Ring and 16-Mb Token RIng?


Mike Anello
Simpact Associates
manello@simpact.com

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Tue, 24 Oct 89 18:32:24 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   HELP!!!
I recently lost my connection that was supplying me with a feed of the
TCP-IP Mailing List.   Could someone please give me the address where
I can request a new SUBSCRIPTION??

Thanks in Advance.

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 89 13:46:03 GMT
From:      almes@RICE.EDU (Guy Almes)
To:        comp.protocols.tcp-ip
Subject:   Re: Router interoperability

It is well known that you can't currently put different makes of
router on different ends of a serial line.  The easiest explanation
is data link and encapsulation.
  Will support by the various vendors of the coming point-to-point
protocol correct this situation?  I know that it's intended to be
a move in the right direction, but is there a claim that it will
be sufficient?
  I'd like to hear from people on the PP protocol IETF WG, and
from knowledgeable others.
  One benchmark question: will the situation be as good as when
routers of multiple makes are placed on an Ethernet?
	-- Guy

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 89 15:13:39 GMT
From:      stev@VAX.FTP.COM (Stev Knowles)
To:        comp.protocols.tcp-ip
Subject:   How do you string a thinnet?


*Beginners question:  How do you physically hook up a thinnet?
*Specifically, how do you handle multiple BNC `T' connections.
*
*1) Is it a bad idea to use a, say, 5-foot drop cable from the `T' to
*the host?
yes.
*2) Can you hang multiple hosts off in all directions from a `T'?
no. a T connector is intended to connect one "device" to the 
network. this device can be a tranciever fan out box, though
(i am refering to qa DELNI type device here.)
*3) Does the cabling have to be a multiple of some magic length?
idealy. it is sold in pre made magic lengths. we wired some thin net
into the walls here, and did not worry abotu magic lenghts.
*4) How can you test your network to see if you screwed something up?
as you construct each run, test the cable with an ohm meter. you can
also place a machine at one end, and ping it from each drop as you add them.
*
*5) Or, if you've only got 6 hosts & a couple of hundred feet of RG-58,
*does it really not matter to much?
it does not matter that much, but remember, few LANS stay that trival.
it is worth investing in doing it correctly now so you dont have to
fix it later, when it may not be as convienent.
*
*Now the $64k question: Is there a good reference for this kind of
*info.
not that i have found, although most vendors of fan out boxes and
bridges take a shot at it. most of the information conflicts though .
. .
*
*Kent Hauser			UUCP: {uunet!cucstud, sun!sundc}!tfd!kent
*Twenty-First Designs		INET: sundc!tfd!kent@sun.com

stev knowles
ftp software
stev@ftp.com

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 89 16:41:05 GMT
From:      karl@cheops.cis.ohio-state.edu (Karl Kleinpaste)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

I have to disagree, Henry.  If the problem is reaching unregistered
sites, the solution is to register them - somewhere - I'm not sure I
care where.  NIC-registered domains are fine, comp.mail.maps UUCP
registration is nearly as fine in a practical sense; other registries
exist, but those are the two I deal with most.

This is not a "join our network" coercion technique, either.
CompuServe has not "joined" the Internet by any stretch of the
imagination.  But they are registered (in both registries; I
registered compuserve.com before I even told CServe what I was
building), and mail gets there as seamlessly as it gets anywhere else.
I considered the RFCs not to be inconvenient, but to provide the
standard against which to implement.  Since the first time that email
has been able to get between CServe and The Greater Out Here, no %
hack (or other ill-advised routing nonsense) has ever been necessary.

Getting registered is easy.  Building a gateway is easy.  They're both
too easy to go to the effort of avoiding the issue with things like %
hacks.

--Karl

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 89 17:00:12 GMT
From:      Gene.Hastings@BOOLE.ECE.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Router interoperability

Bear in mind a potential gotcha: Once the router vendors support PPP, there
is still the potential for disagreement about the encapsulation of other
protocols (such as D*CN*T), and some of us need to support multiprotocol
routers.

Would any of the router vendors like to respond?

Gene

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 89 18:05:03 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   How do you string a thinnet?


   Date: 23 Oct 89 20:08:55 GMT
   From: cucstud!tfd!kent@uunet.uu.net  (Kent Hauser)

   Beginners question:  How do you physically hook up a thinnet?
   Specifically, how do you handle multiple BNC `T' connections.

   1) Is it a bad idea to use a, say, 5-foot drop cable from the `T' to
   the host?

Extremely bad!  There should be NO drop cable, the T connector goes
right on the machine.  Ethernet is a bus network, any stubs from the
main run need to be as small as possible, much more than an inch
(including what's inside the machine, typically around 3/4 of an inch)
is probably pushing it for thin-wire Ethernet, the thick-wire spec is
a little more sensitive which is why it allows longer runs and more
hosts.

   2) Can you hang multiple hosts off in all directions from a `T'?

No, for the same reasons, there should be a T on each host and they
should be connected end-to-end, no T except at a host.

   3) Does the cabling have to be a multiple of some magic length?

No, but there is a minimum spacing which I can't recall right now (the
people who we have making cables just don't make any shorter than
this).  In practice this seldom comes into play on a thin-wire, you
probably don't want two machines that close anyway.  On thick-wire the
cable is marked with stripes at this spacing the idea being that if
you only insert transceivers at the stripes they can't be closer than
the minimum spacing.  Some people have extrapolated from this
technique to deduce that they need to be on a regular pattern, this is
not true.

   4) How can you test your network to see if you screwed something up?

Try operating it and see if it works :-).  I don't think there is any
way, after the fact, to determine that some entire installation meets
the specs.  The only way to determine this is by carefully observing
the installation and seeing that it's done right.  The technique I use
is to continually remind the people who install our cable about the
things not to do.  Whenever someone posts a message to any list I read
with rights and wrongs of Ethernet installation, I forward them a copy
(and they'll probably get this one when it comes back).  The one
technology that might be useful for after the fact testing is a TDR,
but for small installation (like you seem to be talking about below),
this might increase the cost of your network by an unacceptable amount.

   5) Or, if you've only got 6 hosts & a couple of hundred feet of RG-58,
   does it really not matter to much?

Well, when your net is that small it may not matter.  But your net
won't stay small, and if you don't obey the rules from the start you
will find someday that you add something in a legal fashion and the
net breaks.  Then your only choice is to pull it all out and start
over, doing it right.  Let me tell you, this can be quite painful.

   Now the $64k question: Is there a good reference for this kind of
   info.

Gee, you found one I don't have a good answer to.  I use lots of
references, the most important being my experience and what I've
learned talking to others (in forums like this and just standing
around in the corridors at conventions :-).  I've been hacking
Ethernet (and Ethernet-like technologies) since the late 70's and
haven't found the need recently of an overview book specifically
oriented at Ethernet and I don't seem to have such in my collection.

   Thanks much in advance.

Your welcome.  I'm sorry about missing on your last question,
hopefully someone else will chime in with some references.

	    __
  /|  /|  /|  \		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. :-)

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 89 18:24:00 GMT
From:      mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

In article <KARL.89Oct24124105@cheops.cis.ohio-state.edu> karl@cheops.cis.ohio-state.edu (Karl Kleinpaste) writes:
>no %
>hack (or other ill-advised routing nonsense) has ever been necessary.
>
>Getting registered is easy.  Building a gateway is easy.  They're both
>too easy to go to the effort of avoiding the issue with things like %
>hacks.

As one of the originators of the % hack, I'd like to point out that
the % hack predated the ability to get registered.  The % hack may be
ill-advised today, but in its time it was a clean way around a nasty
problem.

Mark Crispin / 6158 Lariat Loop NE / Bainbridge Island, WA 98110-2020
mrc@CAC.Washington.EDU / MRC@WSMR-SIMTEL20.Army.Mil / (206) 842-2385
Atheist & Proud / 450cc Rebel pilot -- a step up from 250cc's!!!
tabesaserarenakerebanaranakattarashii...kisha no kisha ga kisha de kisha-shita
sumomo mo momo, momo mo momo, momo ni mo iroiro aru
uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 89 19:22:00 GMT
From:      wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs)
To:        comp.protocols.tcp-ip
Subject:   Re: FDDI/TCP-IP for Hammacher Schlemmer Chistmas Tree?

]In article <8910172205.AA23356@fernwood.MPK.CA.US>
]	geoff@FERNWOOD.MPK.CA.US (the terminal of Geoff Goodfellow) writes:
]>Does anyone have a FDDI interface and a TCP-IP driver for the Hammacher
]>Schlemmer Fiber Optic Christmas Tree?
	Perhaps you should have crossposted to
	comp.protocols.tcp-ip.eniac?  They're good at finding things
	like this.
-- 
# Bill Stewart, AT&T Bell Labs 4M312 Holmdel NJ 201-949-0705 ho95c.att.com!wcs
# also 201-271-4712 tarpon.att.com!wcs Somerset 4C423 Corp.Pk 3 FAX 469-1355

#		.... counting stars by candlelight ....

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 89 21:04:00 GMT
From:      jbuffum@apollo.HP.COM (Jeffrey Buffum)
To:        comp.protocols.tcp-ip
Subject:   Split Horizons for Routed

Has anyone run across a public domain implementation of routed which supports
split horizons like gated?   While running gated is an option, I would prefer 
a modified routed.

Thanks in advance for any help!


-------------------------------------------------------------------------------
Jeffrey Buffum          
Apollo Systems Division - Hewlett Packard    
Chelmsford, MA 01824          Phone: (508) 256-6600
INTERNET: jbuffum@apollo.hp.com  UUCP:  ...mit-eddie!apollo!jbuffum
-------------------------------------------------------------------------------

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 89 21:23:00 GMT
From:      FILLMORE@EMRCAN.BITNET
To:        comp.protocols.tcp-ip
Subject:   Local Ethernet bridge survey

I would like some information on the availability of
local (ethernet-to-ethernet) bridges, such as:
     - Manufacturer
     - Price
     - Performance (packets/sec forwarding)
     - Filtering capabilities (security filtering)
     - Management tools such as SNMP
Any information about your favorite local bridge will be much appreciated.
I will post a summary of the responses.
________________________
Bob Fillmore, Systems Software & Communications   BITNET:  FILLMORE@EMRCAN
  Computer Services Centre,                       Voice:   (613) 992-2832
  Energy, Mines, & Resources Canada               BIX:     bfillmore
  588 Booth St., Ottawa, Ontario, Canada  K1A 0E4

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 89 21:41:00 GMT
From:      manello@BI1.SIMPACT.COM ("MIKE ANELLO")
To:        comp.protocols.tcp-ip
Subject:   IP over 802.5


	I have a question about running IP over 802.5. 

	RFC 1042 says that the largest frame field of the routing control bytes
	for source routing are as follows:

Postel & Reynolds                                               [Page 8]
RFC 1042            IP and ARP on IEEE 802 Networks        February 1988


         The RIF consists of a two-octet Routing Control (RC) field
         followed by 0 to 8 two-octet Route-Designator (RD) fields.  The
         RC for all-routes broadcast frames is formatted as follows:

                         0                   1
                         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |  B  |   LTH   |D|  LF |   r   |
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Note that each tick mark represents one bit position.

            LF - Largest Frame: 3 bits

               The LF bits specify the maximum MTU supported by all
               bridges along a specific route.  All multi-ring broadcast
               frames should be transmitted with a value at least as
               large as the supported MTU.  The values used are:

                       LF (binary)   MAC MTU      IP MTU

                           000          552         508
                           001         1064        1020
                           010         2088        2044
                           011         4136        4092
                           100         8232        8188

               All other values are reserved for future use.

	The TMS380 Adapter CHipset User's Guide Supplement uses the following:
		page 7-4

                         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        |  B  |   LTH   |D|  LF   | r   |
                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       LF (4 bits)  

                           0000         reserved
                           0001         upto 516 octets in the information field
                           0010         reserved
                           0011         upto 1500 octets in the info field
                           0100         reserved
			   0101		upto 2052 octets in the info field
                           0110         reserved
			   0111		upto 4472 octets in the info field
			   1000		reserved
			   1001		upto 8191 octets in the info field
			   1010 - 1110  reserved
			   1111		initial value of broadcast frames

	Does anyone know which values should be used for the LF bits and what
	IP MTU should be used?
	Is there a standard for 4-Mb Token Ring and 16-Mb Token RIng?


Mike Anello
Simpact Associates
manello@simpact.com

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 89 22:04:40 GMT
From:      news@bbn.COM (News system owner ID)
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet

bernstei@hpuxa.ircc.ohio-state.edu (Dan Bernstein) writes:
< We also encourage all sites to move to a distributed database if possible.
< Our hosts table is aimed at sites that do not have reliable DNS access.
< 
< ---Dan Bernstein, bernstei@hpuxa.ircc.ohio-state.edu

As a service to the SOA of Ohio-State.edu (among others), I feel
obliged to point out that the "we" in this series of statements is the
_Royal_ "We", rather than one indicating any offical part of the Ohio
State University.

The people in charge there really do understand why this is, in
general, a Bad Thing.

In other words:

	g/We/s//I/g
	g/Our/s//My/g

Now, if someone wants to do something more useful, one could make the
tools for collecting and verifying such a host table, so that those
without DNS service could "fake it" in some quasi-reasonable way...

		-- Paul Placeway <pplaceway@bbn.com>
		   formerly at cis.ohio-state.edu, speaking as an
		   alumnus (i.e. _not_ for BBN)

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      24 Oct 89 23:32:24 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   HELP!!!

I recently lost my connection that was supplying me with a feed of the
TCP-IP Mailing List.   Could someone please give me the address where
I can request a new SUBSCRIPTION??

Thanks in Advance.

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 00:05:23 GMT
From:      glen@aecom.yu.edu (Glen M. Marianko)
To:        comp.protocols.tcp-ip
Subject:   Xylogics ANNEX terminal servers testimonials requested


I'm looking for customer testimonials on Xylogics' Annex terminal
server 16/32 port versions for TCP/IP networks.  Specifically, I'm looking for
experiences in the following areas:

- SLIP (and use with FTP Software/NCSA Telnet-PC SLIP drivers)
- Rotarys of computer ports tailed into the box
- Printers back-ended into the box

Thanks.
-- 

-- Glen M. Marianko  Manager, LAN Services  Glasgal Communications, Inc.
   151 Veterans Drive  Northvale, New Jersey 07647  201-768-8082
   glen@aecom.yu.edu - {uunet}!aecom!glen (Courtesy of AECOM & unaffiliated)

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 01:21:49 GMT
From:      RAF@CU.NIH.GOV ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  New Host-Requirement RFCs

> >> it is a problem in practice, maybe the people hurt by it should speak
> >> up, and perhaps something can be worked out eventually to improve matters.
> >
> >Much of BITNET does not support domain addressing (and therefore cannot
> >register with MXs) and is not likely to in the near future.  Many
>
> Actually, any BITNET domain can register with the NIC and MX record
> support will be supplied by UC Berkeley and Harvard U.  There are
> currently 43 domains taking advantage of this--this is available for
> BITNET and related nets; eg Singapore (*.SG), Taiwan (*.TW), etc.

43 isn't very many.

Yes, of course that's true.  But you have to have the software on your
machine to support domains.  Many BITNET sites don't have it.  In some
cases it exists, but the site does not use it for one reason or
another.  In other cases it just doesn't exist.  Domains on BITNET are
supported only for mail, so it's not currently feasible to convert over
completely to domain naming.  BITNET protocols for domain naming for
file transfer and interactive messages have yet to be standardized.

Even if BITNET converted over completely to domain naming, the
difference between BITNET and the Internet would not be transparent to
the user.  The two networks use very different methods for transfering
files.  Interactive messages are not widely implemented on the
Internet.  Remote logon is not possible on BITNET.

I wish the Internet had BITNET-style sender-initiated file transfer
that did not require the sender to know the receiver's password.  It's
very convenient.  Sending files as email is not very user friendly.
UUENCODEing binary files in email is a horrible thing to have to do.
Does X.400 have the capability for attaching arbitrary files to an
email message, as many PC-based email systems do?  That would satisfy
the need.

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 02:49:21 GMT
From:      amanda@intercon.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: Router interoperability

In article <1989.10.24.16.57.48.Gene.Hastings@boole>,
Gene.Hastings@BOOLE.ECE.CMU.EDU writes:
> Bear in mind a potential gotcha: Once the router vendors support PPP, there
> is still the potential for disagreement about the encapsulation of other
> protocols (such as D*CN*T), and some of us need to support multiprotocol
> routers.
> 
> Would any of the router vendors like to respond?
> 
> Gene

Well, I'm not a router vendor, but I have looked over the draft PPP, and
it's got a 16-bit "type" field that is basically the equivalent of the
Ethernet type field (same numbers and everything, by some strange
coincidence :-)).  One of the features of PPP as opposed to SLIP is this
very capability to run multiple protocols over a PPP link layer.

Unless I have misread the draft RFC, it doesn't leave much room for
disagreement...

--
Amanda Walker <amanda@intercon.com>

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 04:35:54 GMT
From:      smart@ditmela.oz (Robert Smart)
To:        comp.protocols.tcp-ip
Subject:   MX-registration vs %-hack (was Re: New Host-Requirement RFCs)

And of course it works the other way. MX-registration allows a host
with a proper domain name to be reached from the Internet. If the
Internet wants to be reachable from other networks they have to go
and ask those other networks to put in a gateway.

For example the Internet could ask ACSnet's minder to put in a gateway
from ACSnet to the Internet so that (for example) an ACSnet user
can send mail by

    sendfile -amailer user@host.university.edu <message

and it would magically work just as if host.university.edu was
a real part of ACSnet. This could be made to work. Perhaps the
Internet is too BIG and IMPORTANT to ask other networks to put in
gateways. In which case there seems to be a certain asymmetry in
arrangements.

Actually I don't see the problem. "user%node" is a perfectly legitimate
"local part" of an RFC-822 address, and I don't see why I shouldn't
set up my RFC-822 compliant domain to have that local part mean that
the mail should be forwarded to some local host that is too insignificant
to register. Certainly we shouldn't mandate that meaning of "%". If
other RFC-822 compliant domains want to have actual users with %s in
their names then that is also ok.

Bob Smart <munnari!ditmela.oz.au!smart> or <smart%ditmela.oz.au@uunet.uu.net>

P.S. I think I'll stick to %-hacked address in my signature until my
faith in the Domain System goes up a lot.

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Wed, 25 Oct 89 11:03:11 CDT
From:      "Linda Winkler,   312-972-7236" <B32357@ANLVM.CTD.ANL.GOV>
To:        <sun-spots@rice.edu>,     <TCP-IP@SRI-NIC.ARPA>
I have recently subnetted by Class B network and have a few questions/
problems.
Problem 1:  I have a Sun-3/280 running SunOS 3.5 and gated 1.9.1.3.
            My subnet mask is 0xfffffc00.  The Sun sends RIP updates
            with an IP destination address of 130.202.20.0 which is
            his broadcast address.  According to RFC1009, I believe
            this is an invalid address for an IP destination.
            It also causes machines on the network who do not
            subnet to send ARPs for destination 130.202.20.0
            because they think they should try to help out and
            forward the packets even though they are not gateways.
            The question is can I change the Sun's broadcast
            address under 3.5?  I have tried to set it to
            0xffffffff with no success.

Problem 2:  I have hosts who send a UDP packet to IP destination
            130.202.23.255.  I have three Suns acting as IP gateways
            (Sun OS 4.0 and 4.0.3) who rebroadcast the packet onto
            the same interface they received it on.  According to
            RFC1009 this is not allowed.  Because I have hosts on
            the network which do not understand subnetting, it
            causes a flurry of ARPs and rebroadcasts.  The question
            is why do the Suns rebroadcast the packet onto the
            same network/interface they received the packet on?

Thanks, Linda
-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 07:20:59 GMT
From:      barmar@kulla (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: MX-registration vs %-hack (was Re: New Host-Requirement RFCs)

In article <7696@ditmela.oz> smart@ditmela.oz.au (Robert Smart) writes:
>Perhaps the
>Internet is too BIG and IMPORTANT to ask other networks to put in
>gateways. In which case there seems to be a certain asymmetry in
>arrangements.

Are these other networks using standardized protocols?

Yes, there's an asymmetry.  The Internet is an order of magnitude larger
than most other networks.

>Actually I don't see the problem. "user%node" is a perfectly legitimate
>"local part" of an RFC-822 address, and I don't see why I shouldn't
>set up my RFC-822 compliant domain to have that local part mean that
>the mail should be forwarded to some local host that is too insignificant
>to register. Certainly we shouldn't mandate that meaning of "%". If
>other RFC-822 compliant domains want to have actual users with %s in
>their names then that is also ok.

No one has proposed legislating away the % hack.  It can't be done, for the
reason you state: every host is free to interpret the local part as it sees
fit.  They're just trying to encourage people to switch to the better
solutions that have been devised since % was invented.  The % hack has
several problems:

1) Users have to remember gateways.  smart@ditmela.oz.au is easier to
remember than smart%ditmela.oz.au@uunet.uu.net.

2) % isn't the only such hack, and it's not always clear what happens when
multiple hacks are used together.  What is the meaning of foo!bar%baz@quux?
Is it quux -> foo -> baz -> user bar or quux -> baz -> foo -> user bar?

3) Problems occur when network topology changes.  If uunet.uu.net is
replaced as the Internet->UUCP gateway, all the %host@uunet.uu.net
addresses are invalidated.  This means that users must learn a new gateway,
and mailing lists all over the place have to be updated.  The domain system
simply requires updating the database, and users never notice.  This can be
very important if the topology change is temporary (for instance, uunet
goes down for a week because the company is moving to a new location, so
someone else takes over gatewaying in the interim).

4) The domain facility has additional features.  For instance, there can be
multiple MX records for a host, so that mail can still go through when the
default forwarder is down.  With %, the decision of which forwarder is used
is made statically by the sender.

5) You're dependent on an arcane, nonstandard feature being implemented on
a host over which you have no control.  Uunet may decide at any time to
stop supporting %, and you'll run into problems.

Besides encouraging hosts to switch away from %, I think they are also
encouraging new systems NOT to implement it in the first place.  More
importantly, it sends a signal to implementors not to try related kludges.
For instance, I've heard of systems that try to parse non-local local
parts, in an attempt to optimize routes.  They see foo%bar@baz, realize
that they know a host named "bar", so send the message directly to bar
rather than routing through baz; this loses if baz doesn't interpret % as
they think it does, or if baz has a different notion of the host bar.
Barry Margolin, Thinking Machines Corp.

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

-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 12:12:41 GMT
From:      smart@ditmela.oz (Robert Smart)
To:        comp.protocols.tcp-ip
Subject:   Re: MX-registration vs %-hack (was Re: New Host-Requirement RFCs)

In article <31038@news.Think.COM> barmar@kulla (Barry Margolin) writes:
>
> Are these other networks using standardized protocols?

Who's to say that protocols that have been dragged through a long tedious
standardization process are better than those created by a few hackers
in a back room. And which category does TCP/IP fit into. Certainly TCP/IP
standards are not registered with the Standards Association of Australia,
unlike some others I could name.
>
> Yes, there's an asymmetry.  The Internet is an order of magnitude larger
> than most other networks.
>

Well I strongly support the domain name system. I was just stirring in case
there was some unconscious arrogance going on. Since it is conscious
arrogance I'll just forget the whole thing.

Bob Smart <smart@ditmela.oz.au>

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 14:14:14 GMT
From:      dcrocker@DECWRL.DEC.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: MX-registration vs %-hack (was Re: New Host-Requirement RFCs)

I hope that everyone takes note of your simple, but fundamental observation
that use of '%' is a) a legal part of the local-part of an RFC822
address, and therefore b) its use is strictly up to the administrator(s)
of the host that interprets the local-part.  I.e., the host referenced
in the right-hand-side of the address.

The Host Requirements working group spent quite a bit of time considering
whether to make the %-hack a formal part of the document.  We decided that
such a section would formally constrain something that is, by definition,
a matter of local choice. (I suppose we could travel down the road of
analogies, looking at state vs. federal rights, here, but I can't think
of a funny ending to it.)

Use of MX requires formal, inter-organization registration and
maintenance.

Use of the %-hack is a much more localized decision and may be modified
much more easily.

The first makes Internet email users think that you are actually on the
Internet, the latter means that new off-net mail hosts do not need to
be registered in the Domain system.

Dave

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 14:28:33 GMT
From:      awaldfog@wellfleet.com (Asher Waldfogel)
To:        comp.protocols.tcp-ip
Subject:   Re: Router interoperability


>Bear in mind a potential gotcha: Once the router vendors support PPP, there
>is still the potential for disagreement about the encapsulation of other
>protocols (such as D*CN*T), and some of us need to support multiprotocol
>routers.
>
>Would any of the router vendors like to respond?
>
>Gene

As a member of the PPP working group and a multiprotocol router vendor,
I can vouch that one of the goals of PPP is multiprotocol interoperability.
We have even discussed bridge interoperability.  So far only IP-oriented
vendors have participated in PPP.  I wouldn't count on Decnet- or
bridge- only systems to implement PPP.

Asher Waldfogel
Wellfleet Communications

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 15:34:17 GMT
From:      dcrocker@DECWRL.DEC.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Source for ftp for Ultrix (LONG)

I am new to Digital and to Ultrix.  Why do the include files that you
mentioned need to be modified?

Thanks.

Dave

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 15:34:46 GMT
From:      mk@bilbo.informatik.uni-dortmund.de (Michael Kuschke)
To:        comp.protocols.tcp-ip
Subject:   Automatic notification about new RFC's

Hello,

is there a way to get an automatic notification when there's a new RFC
oder IDEA avaible ???

	Thanks,

	  -Michael

  Michael Kuschke				  uucp: mk@unido.uucp
  Computer Science Department - IRB		  BITNET: MK@DDOINF6.BITNET
  University of Dortmund			  FAX:    +49 231 751532
  D-4600 Dortmund 50,PO-Box 500500, W.-Germany	  voice:  +49 231 755 2422

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 15:42:16 GMT
From:      messingr@KODAK.COM (Rich Messinger x24361 B83, Rm 528, RL, 02221)
To:        comp.protocols.tcp-ip
Subject:   Question on Fusion Software

Hi Netlanders,
	We have some people in Japan that are using a tcp-ip package called
	FUSION on their Fujitsu fmRT pc's.  The question is, Is this the
	same Fusion software that we have here in the States?  We need some
	documentation on how it works to do some testing.

	Thanks for the help.

Rich Messinger
Eastman Kodak

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 16:03:11 GMT
From:      B32357@ANLVM.CTD.ANL.GOV ("Linda Winkler,   312-972-7236")
To:        comp.protocols.tcp-ip
Subject:   (none)

I have recently subnetted by Class B network and have a few questions/
problems.
Problem 1:  I have a Sun-3/280 running SunOS 3.5 and gated 1.9.1.3.
            My subnet mask is 0xfffffc00.  The Sun sends RIP updates
            with an IP destination address of 130.202.20.0 which is
            his broadcast address.  According to RFC1009, I believe
            this is an invalid address for an IP destination.
            It also causes machines on the network who do not
            subnet to send ARPs for destination 130.202.20.0
            because they think they should try to help out and
            forward the packets even though they are not gateways.
            The question is can I change the Sun's broadcast
            address under 3.5?  I have tried to set it to
            0xffffffff with no success.

Problem 2:  I have hosts who send a UDP packet to IP destination
            130.202.23.255.  I have three Suns acting as IP gateways
            (Sun OS 4.0 and 4.0.3) who rebroadcast the packet onto
            the same interface they received it on.  According to
            RFC1009 this is not allowed.  Because I have hosts on
            the network which do not understand subnetting, it
            causes a flurry of ARPs and rebroadcasts.  The question
            is why do the Suns rebroadcast the packet onto the
            same network/interface they received the packet on?

Thanks, Linda

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 16:12:21 GMT
From:      billy@vaxb.acs.unt.edu
To:        comp.protocols.tcp-ip
Subject:   WKS Records

HI,

My question is about the Well Known Services records in the name server.
I was recently told that the WKS records are not actually used.  I started
checking around the Internet and discovered that a lot of nodes either
don't set their WKS records or they are wrong.  

What purpose does the WKS records service and when are they used?  If many 
nodes don't set their WKS records right (or at all), why would I mess with 
it?  

================================================================================
Billy Barron                  Bitnet : BILLY@UNTVAX
VAX system manager            THENET : NTVAXB::BILLY
University of North Texas   Internet : billy@vaxb.acs.unt.edu
                                SPAN : UTSPAN::UTADNX::NTVAXB::BILLY
================================================================================

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 17:04:46 GMT
From:      randall@uvaarpa.virginia.edu (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re:  BITNET -- Internet capabilities

In article <8910251138.AA11562@alw.nih.gov> RAF@CU.NIH.GOV ("Roger Fajman") writes:

>I wish the Internet had BITNET-style sender-initiated file transfer
>that did not require the sender to know the receiver's password.  It's
>very convenient.  Sending files as email is not very user friendly.

The ability of some arbitrary user elsewhere on a network I'm connected
to to put files in my account without (at least) password protection 
is a security hole.  I'm glad my systems aren't directly connected to BITNET.

ftp and sending files as mail do work, though I concede a better user
interface could be devised if someone had the time (I don't).

By the way, those of you running a sendmail that has a "decode" alias
built-in (as I gather a number of popular workstations do) may well
want to remove it.  An acquaintance at a workstation firm tried to mail
some font files to me using "decode@domain" and was startled that my
systems have that disabled and apparently hadn't realised what a security
hole it can be...

Regrettably security isn't something most vendors have been paying
much attention to until just now and the continuing problems with
DECnet virii and worms and the infamous Internet worm seem to have
had limited impact on most folks...

  Ran
  randall@virginia.EDU

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 17:32:03 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: MX-registration vs %-hack (was Re: New Host-Requirement RFCs)


There was a time when I sneered at the %-laden From: lines from
berkeley.edu and other places.  That time has passed.  Sgi.sgi.com now
rewrites From:'s for internally originated mail to something of the form
user%host.dom.sgi.com@sgi.sgi.com.  (Of course, stuff passing thru is not
touched.)

This happened when people exhausted my tolerance to complaints that replies
to our mail did not work.  It took hundreds of such complaints before I
yielded.

Our problem was made worse by many of things, including my mistakes, broken
DNS-servers out there, having thousands of hosts in several domains behind
the sgi.sgi.com gateway, not wanting to burden our secondary servers with
our not too small and ever changing host files, and the security worries of
some people.

We tried using simple wildcard MX records.  That does not work.  The
obnoxious "%" does work.


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 17:40:00 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   New draft of ISO IS-IS Routeing Spec

Dave Oran, the Project Editor of what is formally known as
"ISO 8473", and is better known as the ISO IS-IS Routeing
specification, has asked me to make available via public FTP
a PostScript file containing a new draft of the spec.

To retrieve this file, FTP to gatekeeper.dec.com, login as
user "anonymous", giving your username as a password.  There
are two versions of the file

	pub/ISO/isis.psf	Plain-ASCII PostScript	1144 Kbytes
	pub/ISO/isis.psf.Z	"Compressed" format	 368 Kbytes

If you can handle the compressed form of the file, please use
it, since it's about 1/3 as big.  This will save you time and
save us network bandwidth.  Remember that compressed files must
be retrieved in binary mode.

Please do not ask me to mail you this file, or for any format
besides PostScript, or for help in printing the PostScript, or
any questions about the content.

This document is a preliminary draft of a proposal for an ISO
standard.  It is provided for your information only, and does not
necessarily represent the position of ISO or of Digital.

-Jeff

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 18:49:03 GMT
From:      allan@didsgn.uucp (didsgn)
To:        comp.protocols.tcp-ip
Subject:   One-way Sun Net

I've got a problem with my Sun SPARCStation 330. The problem is the
ethernet connection with a SYSV machine that I have (and the problem
is that it doesn't work, not that it is connected! :-). The symptoms
are that the Sun can rlogin or telnet to the SYSV machine, but the
SYSV machine cannot rlogin or telnet to the Sun. Rsh and rcp work
fine in either direction. Ftp also works in either direction. When
running telnet on the SYSV machine, the connection is opened, but the
login process is not started on the Sun. However, keystrokes get across
the net and can be seen in the I/O buffer of the telnet daemon on the
Sun. Similarly, rlogin connection is easily made, however rlogin does
some communicating with the remote daemon (on the Sun) and decides that
something is wrong and kills the connection.

I am running SunOS 4.0.3. Apparently this used to work under SunOS 3.x.
Sun support isn't much use. They just keep calling us to see if we still
have the problem, as if it was going to fix itself!

Any clues or pointers would be appreciated. Please e-mail your responses
to me.

Thanks in advance.


Allan G. Schrum                 | Sign it? Without reading the fine print?
Digital Design, Inc.            |-----------------------------------------
3060 Business Park Drive        | (404) 447-0274
Norcross, GA 30071              | ...!gatech!rebel!didsgn!allan
-- 
Allan G. Schrum                 | Sign it? Without reading the fine print?
Digital Design, Inc.            |-----------------------------------------
3060 Business Park Drive        | (404) 447-0274
Norcross, GA 30071              | ...!gatech!rebel!didsgn!allan

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 18:49:53 GMT
From:      baker@VITAM6.UUCP (Fred Baker)
To:        comp.protocols.tcp-ip
Subject:   Router Line Interoperability

Line Interoperability of Routers can occur only to the degree that the vendors
can agree on what the line is to carry.  If the line is *only* to carry one
protocol, say IP, and best effort service (as opposed to reliable service) is
adequate, then no datalink header is required at all.  If multiple network
layer protocols (say, add CLNS) are to be carried, then some identification
of the message format is required. If the backbone is to carry non-datagram
traffic (SNA anyone?), it takes more, and if Remote MAC Bridging of any LAN
is going over the backbone, then there's more yet.

I have looked at one of the drafts of the point to point protocol, and feel
that if the protocols that they are targeting are the ones you're using, then
it is probably as good as any of the proprietary offerings.  The question
that I'll ask - and any vendor will ask - is 'but what about <mumble> which
that doesn't support and my customers use?'  When the P-P comes out, I think
the vendors will support it as 'one of the options', touting their proprietary
protocols as well.

Fred
baker@vitalink.com

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 19:01:37 GMT
From:      jstewart@sce.carleton.ca (John Stewart)
To:        comp.protocols.tcp-ip
Subject:   3Com/Bridge CS/100 routing problem

We recently started using class C subnetting on our class B network.  One
problem we ran into was that our 3Com/Bridge CS/100 terminal servers were
unable to connect to machines on another subnet.  I managed to fix that
problem by adding the routed port number to the list of "listener" port
numbers so the Bridge boxes would look at RIP packets.

Now the problem has returned.  Only the 3Com/Bridge CS/100 boxes seem to
be affected, everyone else on our subnet (mostly Sun's) has the "right"
routing information to reach machines on other subnets.

I've checked the configuration and the boxes should still be picking up
RIP information.  Does anyone have any idea of how to fix this problem?
-- 
Support the President's War On Long Usenet Signatures Committee

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 19:31:43 GMT
From:      mrb1@cbnewsh.ATT.COM (maurice.r.baker)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   TCP-IP over X.25 between 3B2 and 6386E PC

Hi ---

I would like to run TCP-IP between a 3B2/600 and a 6386E [both under UNIX
System V].  To be more specific, the two systems are about 1500 miles
apart, and are interconnected by a 9600 baud private line equipped with
synchronous modems at each end.  Performance is not an issue at this time.
I have found reference to an X.25 "spigot"
for TCP-IP on the 3B2 end using the SPSC board (is this some derivative
of the ISC board?)  However, I've got no information yet on its companion
hardware/software on the 6386E end (we do have the AT&T X.25 card for the
6386E already, along with the 3B2 ISC card).  Can anyone advise, comment,
or otherwise shed some light on this?

Thanks in advance --

M. R. Baker
AT&T-BL, Holmdel, NJ
email to: hoqub!mrb (will also watch these newsgroups for replies)
201-949-7935

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 20:50:26 GMT
From:      randall@uvaarpa.virginia.edu (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   Re: MX-registration vs %-hack (was Re: New Host-Requirement RFCs)

In article <43522@sgi.sgi.com> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:

>Our problem was made worse by many of things, including my mistakes, broken
>DNS-servers out there, having thousands of hosts in several domains behind
>the sgi.sgi.com gateway, not wanting to burden our secondary servers with
>our not too small and ever changing host files, and the security worries of
>some people.
 
>We tried using simple wildcard MX records.  That does not work.  The
>obnoxious "%" does work.

Actually if you'll check the GE nameserver, you will find that we have
hidden our entire internal DECnet (hordes of ever changing hosts)
behind an MX record for *.DNET.GE.COM and the domain I look after is
has a MX for *.CHO.GE.COM.

We had a *&^% of a time when we tried to observe the "%" hack and I have
had _zero_ complaints from users since we got our MX records straight last
spring and eliminated all usage of the "% hack" whereas I had near daily
gripes until the changeover about lost or delayed mail.

We exchange mail regularly with most of the known Internet including
Asia and Europe.  No problems.  I wonder if SGI's problem was really
getting the MXs straight rather than something else.  Use of the
%-hack can hide from view problems with one's nameserver's MX records.
My own experience is why I feel so strongly about eliminating the
%-hack from common usage and reserving it for the few special cases
wher an MX record won't work for political or technical reasons and
no other solution is present.

I hear gripes that MILNET users are the problem since many don't
have nameservers.  I haven't experienced any problems with folks on
MILNET myself though.

  Ran
  GE-Fanuc North-America

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Oct 89 04:21:10 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Cc:        list: ;
Subject:   Call for Participation




	           CALL FOR PARTICIPATION

	    Internet Research Steering Group (IRSG)
	Workshop on Architectures for Very-High-Speed Networks

		      January 24-26, 1990
		    Cambridge, Massachusetts


The workshop is a working meeting, designed as a forum in which 
members of the academic, industrial and standards community can
meet to discuss research issues in the design and implementation of
environments to support very high-speed (e.g. gigabit) data communication.
Suggestions on how these ideas may related to the evolution of the
Internet are also of interest.  This is a one-time workshop sponsored
by the Internet Research Steering Group and is being organized by
Dave Clark and Craig Partridge.

The goal of the meeting is foster discussion and the exchange of new
ideas.  Topics to be discussed at the workshop include: Lightwave
Technology, High-Speed Data Networking and the Phone System, Flow
and Congestion Control at Very-High Speeds, Applications and
Application Support Paradigms, and Issues in Attaching Hosts to
Very-High Speed Networks.  Sessions on additional topics will be
set up based on the ideas and interests of the attendees.

The workshop will last two and a half days, and consist of a series
of 90 minute sessions.  Each session will begin with a handful of
short (ten minute) presentations followed by discussion.  On the
first day, invited speakers will introduce each session with
a slightly longer talk (about 30 minutes long) designed to give
a somewhat broader perspective.

There will be no paper presentations.  (We do expect to produce
an informal workshop report).  Authors interested in publishing
papers are encouraged to consider the SIGCOMM '90 Symposium, which
is actively soliciting submissions on high speed networking. 
(Contact the SIGCOMM '90 Program Chair, Phil Karn,
karn@thumper.bellcore.com for more information).

Attendance at the workshop is strictly limited to 50 people.  People
interested in attending the workshop should apply to the program committee.
Applications should be about two paragraphs in length and should outline
the applicant's areas of interest in the field and relevant work
on related topics.  Applications will be judged, in large part, on
new or interesting ideas that the applicant can bring to the workshop so
please be sure to highlight innovative work.  Note that due to the
large number of expected applications, we encourage team projects or
close collaborators to restrict themselves to one attendee, and
suggest that organizations limit themselves to two applicants, with
differing areas of interest.  The deadline for applications is Thursday,
November 16th, 1989.  Notification of the decisions on applications
will be sent out no later than December 1st, 1989.

Local Arrangements:  The workshop will be held in the BBN Conference
Center in Cambridge, Mass.  We expect to arrange discount airfares and
hotel accomodations.  The workshop fee, if any, will be nominal.

E-mail or mail applications to:

    Craig Partridge (craig@bbn.com)
    c/o BBN Systems and Technologies Corporation
    10 Moulton St, MS-6/5B
    Cambridge MA 02138

    (617) 873-2459

The program committee is:

    Dave Clark (MIT), Gary Delp (IBM), Keith Lantz (Olivetti),
    Craig Partridge (BBN), Dave Sincoskie (Bellcore), Don Tolmie (LANL)
-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 21:52:54 GMT
From:      jhm+@andrew.cmu.edu (Jim Morris)
To:        comp.protocols.tcp-ip
Subject:   Fwd: PostScript in PostScript

The PostScript communication idea is being discussed on the PostScript
bb now. Here is a sensible comment.

---------- Forwarded message begins here ----------

X-Andrew-WideReply: netnews.comp.lang.postscript
X-Andrew-Authenticated-as: 0;andrew.cmu.edu;Network-Mail
Received: via nntppoll with nntp; Wed, 25 Oct 89 10:09:33 -0400 (EDT)
Path:
andrew.cmu.edu!pt.cs.cmu.edu!tut.cis.ohio-state.edu!pacific.mps.ohio-stat
e.edu!
gem.mps.ohio-state.edu!ginosko!uunet!crdgw1!crdgw1.ge.com!barnett
From: barnett@crdgw1.crd.ge.com (Bruce Barnett)
Newsgroups: comp.lang.postscript
Subject: Re: PostScript in PostScript
Keywords: graphical newsgroup
Message-ID: <3566@crdgw1.crd.ge.com>
Date: 25 Oct 89 13:28:23 GMT
References: <7800@cg-atla.UUCP>
Sender: news@crdgw1.crd.ge.com
Reply-To: barnett@crdgw1.crd.ge.com (Bruce Barnett)
Distribution: comp
Organization: GE Corp. R & D, Schenectady, NY
Lines: 13
In-reply-to: felleman@cg-atla.UUCP (John Felleman)

%!
( <7800@cg-atla.UUCP> felleman@cg-atla (John Felleman)
 (Let's start a discussion about the feasibility and
  desirability of this concept.) CiteReference

(There would be great benefit if there were a way of isolating
libraries from data. That is, there should be a way of sending
PostScript libraries ahead, so that once your machine received the
library,
you would be able to keep it around and avoid the cost of sending
the library over and over and over again...
) ShowText

BruceBarnett Signature

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 22:09:00 GMT
From:      mogul@DECWRL.DEC.COM (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Clarification: new draft of ISO IS-IS Routeing spec

That document is NOT ISO 8473; my mistake.  The draft IS-IS Routeing
spec is "ISO/IEC JTC1/SC 6/WG 2 N 329".  Sorry if I confused anyone.

-Jeff

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 22:23:52 GMT
From:      rlm@mcspdx.UUCP (Rich Morgan)
To:        comp.sources.wanted,comp.dcom.lans,comp.protocols.tcp-ip
Subject:   request for tftp/tftpd public domain source

If anyone has public Domain source for tftp and tftpd please contact me.
I would like to get a copy. My system is based on Unix System V release
3. I could convert a Berkley version if necessary.
Rich Morgan
Motorola, Portland Or.

-- 
Rich Morgan                           Motorola Inc., Computer Systems Division
rlm@pdx.csd.mot.com                 . . . tektronix!nosun!cvedc!mcspdx!rlm
Voice: (503) 643 6247                 . . . .  uunet!apple!motcsd!mcspdx!rlm

-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 22:37:28 GMT
From:      RAF@CU.NIH.GOV ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  New Host-Requirement RFCs

> This is not a "join our network" coercion technique, either.
> CompuServe has not "joined" the Internet by any stretch of the
> imagination.  But they are registered (in both registries; I
> registered compuserve.com before I even told CServe what I was
> building), and mail gets there as seamlessly as it gets anywhere else.
> I considered the RFCs not to be inconvenient, but to provide the
> standard against which to implement.  Since the first time that email
> has been able to get between CServe and The Greater Out Here, no %
> hack (or other ill-advised routing nonsense) has ever been necessary.
>
> Getting registered is easy.  Building a gateway is easy.  They're both
> too easy to go to the effort of avoiding the issue with things like %
> hacks.

But CompuServe is essentially a single host (as it appears to the
outside world, anyway).  When you have a network of many non-Internet
hosts operated by independent organizations the problem becomes much
more difficult.  One can either adopt domain naming on the non-Internet
network (as the UUCP network did, I believe) or build some sort of
translation between the two name spaces into the gateway.  Neither one
is necessarily very easy to do.  In the latter case, the biggest
problem is getting all the organiztions registered and collecting the
information to do the translation.  And when you are done, users still
have to be aware of two forms of addresses.  If I'm on XYZ net (which
does not use domains) and I want to tell my friend on the Internet how
to mail to me, I will still have know the name of my host on the
Internet.

P.S. - If it's all so easy, how come the From address in the message
that I am replying to had an ! in the local part?

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      25 Oct 89 23:40:31 GMT
From:      rwolski@lll-lcc.UUCP (Richard Wolski)
To:        comp.protocols.tcp-ip,comp.unix.wizards
Subject:   4.X implementations of TCP, initial sequence numbers, and windows


Hello everyone.

I have a BSD implementation question regarding the initial sequence
number and the advertised window.  In some of the BSD code that we have
(vendors will remain nameless to protect the innocent) the following
piece of code appears:

if(win > 0 && SEQ_GT(tp->rcv_nxt+win, tp->rcv_adv))
	tp->rcv_adv = tp->rcv_nxt + win;

What we notice is that another vendor's implementation of TCP chooses an
initial sending sequence number with the sign bit set (sometimes) and that
the rcv_adv field in the tcpcb always remains 0.  I think the following thing
is happening.  SEQ_GT is defined as:

#define SEQ_GT(a,b)  ((int)((a)-(b)) > 0)

When expanded in the above code, (a) has the sign bit set, (b) is zero, so the
test fails and rcv_adv never gets set properly.  This manifests itself
as unusually large windows where one would not expect them.

My first question:  Am I reading this right?  I checked the code to set the
iss on the sending side, and it periodically increments a global variable
which eventually results in a negative number (when viewed as an int).

But wait, there's more...

We looked further at the sender's code for setting iss and saw the following
statements:

#ifdef TCP_COMPAT_42
	if((int)tcp_iss < 0)
		tcp_iss = 0;			/* XXX */
#endif

This makes me believe that the problem is somehow fixed at 4.3.  Is that
true?  We looked at yet another vendor's implementation which was supposed
to be 4.3, and nothing seems to be different. 

Any thoughts that you might have in this matter will be gratefully appreciated,
and I apologize if I am asking for the answer to a question that everybody
except me is privy to.

Rich Wolski
rwolski@lll-lcc.llnl.gov		inter-net
(415)423-8594				bell-net
P.O. Box 808, L-60			mail-net
Livermore, CA  94538

-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 02:13:00 GMT
From:      chapman@acf4.NYU.EDU (Gary W. Chapman)
To:        comp.protocols.tcp-ip
Subject:   SNMP Proxy Agents

Are there existing examples of SNMP proxy agents?

 -- Gary Chapman, Academic Computing Facility, New York University

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Oct 89 08:17 CDT
From:      Larry Owen <OWEN@ducvax.auburn.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re:  BITNET -- Internet capabilities
>>I wish the Internet had BITNET-style sender-initiated file transfer
>>that did not require the sender to know the receiver's password.  It's
>>very convenient.  Sending files as email is not very user friendly.
 
>The ability of some arbitrary user elsewhere on a network I'm connected
>to to put files in my account without (at least) password protection
>is a security hole.  I'm glad my systems aren't directly connected to BITNET.

This may be the first (or the tenth!) of a series of similar responses, but:
 
Just in case this misconception is shared by many others, files sent over
Bitnet (at least on most operating systems) don't go in your directory.
You have to actively receive the files from a holding area into your
directory.  This does not present a security hole.

Larry Owen
Mgr., Network Support
Technical Support Services
Auburn University

Bitnet:   owen@auducvax
Internet: owen@ducvax.auburn.edu
-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Thu, 26 Oct 89 08:21:38 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   THANKS
My thanks to everyone who responded to my request for help.
I have now renewed my subscription to all the Mailing Lists I was
receiving at my old address.  Boy, was Joni Mitchell right, "You don't
know what you've got til it's gone."

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 05:38:35 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.protocols.tcp-ip
Subject:   Re: MX-registration vs %-hack (was Re: New Host-Requirement RFCs)

UCSD continues to rewrite outgoing Internet From: lines as
	user%campushost@ucsd.edu
because that is the only format that works with everyone we correspond
with, especially &^*%^&*$ MILNET hosts that are still using the damn
hosts table and will be until the next war.

And I refuse to register all 2000+ of our hosts with the NIC (no doubt
they're overjoyed by that!).

We have MX registrations for all our campus hosts that can receive mail,
and we'll cheerfully accept mail for them in the form
	user@campushost.ucsd.edu
but we aren't going to show that as a return address until I'm well
convinced that I'm not gonna have screaming faculty members phoning me
up to tell me about some babyburner on a FOONLY somewhere on MILNET whose
permanent latrine orderlyXXXX er, system manager says they can't send us
mail because our hostname isn't in their hosts file.  

I've been down that road before.

Warmest personal regards,
	- Brian

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 08:30:11 GMT
From:      sater@cs.vu.nl (Hans van Staveren)
To:        comp.protocols.tcp-ip
Subject:   NOVELL internals documentation wanted.  Especially on packets.

This article actually is from cjs@cwru.cwru.edu. No replies to me

I am looking for information on Novell internals.  Specifically, the format of
the different packets Novell uses to communicate between the file server(s) and
the client machine.

I don't have routine access to a USENET feed, so please reply directly to me.
I will summarize and post (through a friend) any answers I receive.

Thanks in advance.

Christopher Seline

cjs@cwru.bitnet
cjs@cwru.cwru.edu (internet)

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 13:17:00 GMT
From:      OWEN@DUCVAX.AUBURN.EDU (Larry Owen)
To:        comp.protocols.tcp-ip
Subject:   Re:  BITNET -- Internet capabilities

>>I wish the Internet had BITNET-style sender-initiated file transfer
>>that did not require the sender to know the receiver's password.  It's
>>very convenient.  Sending files as email is not very user friendly.
 
>The ability of some arbitrary user elsewhere on a network I'm connected
>to to put files in my account without (at least) password protection
>is a security hole.  I'm glad my systems aren't directly connected to BITNET.

This may be the first (or the tenth!) of a series of similar responses, but:
 
Just in case this misconception is shared by many others, files sent over
Bitnet (at least on most operating systems) don't go in your directory.
You have to actively receive the files from a holding area into your
directory.  This does not present a security hole.

Larry Owen
Mgr., Network Support
Technical Support Services
Auburn University

Bitnet:   owen@auducvax
Internet: owen@ducvax.auburn.edu

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 13:21:38 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   THANKS

My thanks to everyone who responded to my request for help.
I have now renewed my subscription to all the Mailing Lists I was
receiving at my old address.  Boy, was Joni Mitchell right, "You don't
know what you've got til it's gone."

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 13:47:01 GMT
From:      mark@alias.UUCP (Mark Andrews)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Stanford enetfilter

Recently, I have seen references to an ethernet filter for BSD systems
written at Stanford:

	On 4.3 BSD systems, these functions are implemented using
	the Stanford enetfilter device driver in the user-contributed
	software.

Is this filter available anywhere. I don't have easy access to the internet, so
if it is not too big, I would appreciate it if someone could mail it to me.

	Thanks,

		Mark

------------------------------------------------------------------------------
	Mark Andrews
	Systems Programmer,
	Alias Research,
	Toronto, Canada
Phone:	(416)-362-9181
UUCP:	mark%alias@csri.utoronto.ca

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 13:47:47 GMT
From:      fasteddy@sdcdcl.span.nasa.gov (John McMahon - NASA GSFC ADFTO - 301-286-2045)
To:        comp.protocols.tcp-ip
Subject:   BITNET clarifications...

***> In article <8910251138.AA11562@alw.nih.gov> RAF@CU.NIH.GOV ("Roger
***> Fajman") writes:
***>  
***> >I wish the Internet had BITNET-style sender-initiated file transfer
***> >that did not require the sender to know the receiver's password.  It's
***> >very convenient.  Sending files as email is not very user friendly.
***>  
***> From:         Randall Atkinson <haven!uvaarpa!randall@AMES.ARC.NASA.GOV>
***> 
***> The ability of some arbitrary user elsewhere on a network I'm connected
***> to to put files in my account without (at least) password protection is
***> a security hole.  I'm glad my systems aren't directly connected to
***> BITNET.

Hmm...  my systems are directly connected to BITNET, and I am pretty
happy...

But seriously, to clarify about BITNET file transfer...

Files sent to a user on BITNET are stored in a "Receive/Spool" area,
they are not deposited into a users directory.  While in the "Receive/Spool" 
area, the user has an opportunity to see where the file comes from and
examine it before it gets into the users directory.  It's a fairly safe
system as long as you are careful about what you receive to disk.

/-------------------------------------+----------------------------------------\
| John "Fast Eddie" McMahon           |    Span: SDCDCL::FASTEDDY (Node 6.9)   |
| Advanced Data Flow Technology Office|    Arpa: FASTEDDY@DFTNIC.GSFC.NASA.GOV |
| Code 630.4 - Building 28/W255       |  Bitnet: FASTEDDY@DFTBIT               |
| NASA Goddard Space Flight Center    |GSFCmail: JMCMAHON                      |
| Greenbelt, Maryland 20771           |   Phone: 301-286-2045 (FTS: 888-2045)  |
 +-------------------------------------+----------------------------------------+
| "Living a 9600 Baud Lifestyle in a 1200 Baud World" - R.A.J.                 |
 \------------------------------------------------------------------------------/

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 14:56:54 GMT
From:      tannenba@cat17.cs.wisc.edu (Todd Tannenbaum)
To:        comp.protocols.tcp-ip
Subject:   Where can i get a POP3 server for 4.3 BSD UNIX ?


I am trying to locate a POP3 (Post Office Protocol ver 3) server that will
run on 4.3 BSD UNIX.  It is important to me to obtain version 3, NOT version
2.  It does not have to be version 3 extended, although that would be
nice..... If someone knows how to obtain a POP3 server (via anonymous ftp,
preferably), please respond to me either directly or in this newsgroup.
	Thanx!  -Todd Tannenbaum
		 tannenba@garfield.cs.wisc.edu 
			-- OR --
                 tannenba@zs.engr.wisc.edu

-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 15:35:32 GMT
From:      merlin@smu.edu (David Hayes)
To:        comp.protocols.pcnet,comp.protocols.tcp-ip
Subject:   Need information on Novell packet formats

I am looking for information on Novell internals.  Specifically, the format of
the different packets Novell uses to communicate between the file server(s) and
the client machine.

I don't have routine access to a USENET feed, so please reply directly to me.
I will summarize and post (through a friend) any answers I receive.

Thanks in advance.

Christopher Seline

cjs@cwru.bitnet
cjs@cwru.cwru.edu (internet)


David Hayes	School of Engineering	Southern Methodist University
merlin@smu.edu	uunet!smu!merlin
"Argue for your limitation, and, sure enough, they're yours." - Richard Bach

-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 16:39:41 GMT
From:      maxwell@wessex.dec.com (Dave Maxwell)
To:        comp.protocols.tcp-ip,comp.protocols.iso
Subject:   RFC 1006

I'm doing some investigation into running an ISO stack using TCP/IP as the
network service provider, as outlined in rfc 1006 'ISO Transport Services
on top of the TCP'.  I would like to know if someone could give me a more
detailed description of how this can be done.  I would also interested in
any existing implementations.

Please mail any replies to maxwell@wessex.dec.co.uk as I do not have direct
acces to usenet at the moment.

Thanks

	Dave Maxwell

-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 16:50:32 GMT
From:      jqj@RT-JQJ.STANFORD.EDU (JQ Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re:  BITNET -- Internet capabilities

>>I wish the Internet had BITNET-style sender-initiated file transfer
 
>The ability of some arbitrary user elsewhere on a network I'm connected
>to to put files in my account without (at least) password protection
>is a security hole.

This BITNET feature is usually implemented as writing the files to a
remote spool area where disk space is charged to the system rather than
the target user, and the target user may retrieve the files or not
within some reasonable time.  As such, it is not any more a security
hole than the ability to send electronic mail to /usr/spool/$USER.  The
key feature that it has which SMTP-based email lacks is a standard
(sort of) for sending non-textual data.  X.400 with its provision for
arbitrary binary attachments may make this BITNET feature obsolete.
But Internet-only users should not be so narrowminded as to think that
ftp is the "one true way" to manage file transfer!

As Ran remarks, security is a problem on the Internet.  One might argue
that it is less of a problem on BITNET because the BITNET world
developed from the paranoid computing-center-production-IBM-mainframe
environment rather than the casual departmental-Unix-workstation
environment.

JQ Johnson                              voice: 415-723-3078
Manager, Special Projects               Internet: jqj@jessica.stanford.edu
Networking and Communications Systems
Pine Hall Rm 125-A 
Stanford University
Stanford, CA 94305-4122

-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 17:34:36 GMT
From:      ittai@SHEMESH.GBA.NYU.EDU (Ittai Hershman)
To:        comp.protocols.tcp-ip
Subject:   Re: BITNET -- Internet capabilities


    >I wish the Internet had BITNET-style sender-initiated file transfer
    >that did not require the sender to know the receiver's password.  It's
    >very convenient.  Sending files as email is not very user friendly.

    The ability of some arbitrary user elsewhere on a network I'm
    connected to to put files in my account without (at least) password
    protection is a security hole.  I'm glad my systems aren't directly
    connected to BITNET.

    ftp and sending files as mail do work, though I concede a better user
    interface could be devised if someone had the time (I don't).

I manage a site with both BITnet and Internet connections.  I have never
held BITnet in high esteem (on a technical level), but I have changed my
view on this subject.

There are many legitimate cases where sender-initiated file transfer
is warranted.  The one that comes most quickly to mind, is the case
where two (or more) researchers are collaborating on a paper and need
to send drafts back and forth; they are also working on other papers
and therefore do not want to swap password information.  On the
Internet, this basically leaves them at the mercy of using e-mail.
And not all e-mail UA's are capable of being used as file-transfer
utilities.

While not perfect, and decidedly implemented for brain damaged
reasons, the BITnet service is adaptable at low risk.  The security
mechanism is quite simple -- all sender-initiated file transfers are
collected in a spool directory, and users run a "RECEIVE" utility (a
la Joiner's JNET implementation of RSCS for VMS) to actually bring the
file into their directory.  The spool area then becomes a DMZ, no more
risky than anonymous FTP.

Yes, I agree this is not optimal.  Yes, I agree that this service
could be abused.  I think, though, that this would be a terribly
useful service to add until such a time when a more elegant solution
is found.

-Ittai

-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 17:44:58 GMT
From:      cutter@cutsys.UUCP (Bernie Hoffstadt)
To:        comp.protocols.tcp-ip
Subject:   Re: How do you string a thinnet?

--------
In article <8910241805.AA26176@gaak.LCS.MIT.EDU> Michael A. Patton writes:
>>
>> Now the $64k question: Is there a good reference for this kind of
>> info.
>
>Gee, you found one I don't have a good answer to.  I use lots of
>references, the most important being my experience and what I've
>learned talking to others (in forums like this and just standing
>around in the corridors at conventions :-).  I've been hacking
>Ethernet (and Ethernet-like technologies) since the late 70's and
>haven't found the need recently of an overview book specifically
>oriented at Ethernet and I don't seem to have such in my collection.
>
	Seeing that this seems to be the question that no one else
has been able to answer, maybe you should write one yourself -- there
may be some money in it! :-)  We have an installation much like Kent's,
And I have had a few of the questions that he asked, but fortunately
had no real problems with them (I stuck with what I *was* able to
read about here and there).

	That is, until I started thinking about extending our net-
work to the Sales building.  It's currently confined to our Service
building.  We already have a bunch of (presumably twisted-pair,
though I wouldn't swear to it -- looks like a gob of 22 guage solid
wire packed into a sheath) phone wiring installed between the two
buildings, only half of which is in use for the phones.  I wanted to
use this to make the link.  I thought that I should be able to put a
balun on an end machine in each building, and run the twisted pair
between these.

	I purchased a couple of baluns from Altex electronics which
a salesman told me were for thinnet->twisted pair, but they didn't
work, not even for replacing a short section of thinnet that I knew
was working.  I suspect that the baluns were really for IBM networks
(RG62, I think -- I've seen lots of these for the ~$6 I paid Altex)
and for obvious reasons wouldn't work anyway.  But since I haven't
seen any manufacturer explicitly explicitly list this scheme as a
workable configuration, I'm not even sure it can be done.  A guy I
talked to at Black Box in CA seemed to think so, and they DO have
thinnet->twisted pair baluns.  But these things are $75 a pop
(probably the same thing as 3-com's "pair-tamers"  @ $119), and the
catalog still doesn't say I can do what I want to with these.  Says
you use them with repeaters...

	Well, what do you think?  Would it work?  Or do I need to buy
a bunch more expensive hardware?  In which case I'd save us money by
digging a trench and burying some RG58.  BTW, the length of cabling
in the Service building runs about 150-200' end-to-end, and in Sales
it will be about 100'.  The distance between the two is about 150'.
Thanks in advance for any advice you might offer!

			Bernie.
--
Bernie Hoffstadt   (503) 752-5929 * Internet: cutter%cutsys.UUCP@CS.ORST.EDU
1437 N.W. 9th st.   -or- 753-1646 *   -or-    cutter@jacobs.CS.ORST.EDU
Corvallis, Oregon  97330  **** UUCP: {tektronix,hp-pcd}!orstcs!cutsys!cutter 

-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 18:49:42 GMT
From:      jln@accuvax.nwu.edu (John Norstad)
To:        comp.protocols.tcp-ip
Subject:   Re: Where can i get a POP3 server for 4.3 BSD UNIX ?

In article <3469@puff.cs.wisc.edu> tannenba@garfield.cs.wisc.edu (Todd Tannenbaum) writes:
>
>I am trying to locate a POP3 (Post Office Protocol ver 3) server that will
>run on 4.3 BSD UNIX.  

I just finished installing a POP3 server on a SparcStation.  The server is
part of Marshall Rose's "MH Message Handling System".  I believe that it
is available via anonymous FTP from louie.udel.edu.

I had quite a few problems with the installation, but finally managed to get
it to work.  Email me if you have any questions.

John Norstad       Northwestern University      jln@acns.nwu.edu

-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 20:17:55 GMT
From:      tuula@gvlf6-j.gvl.unisys.com (Tuula Kunzman)
To:        comp.protocols.tcp-ip
Subject:   private mib variables

Does anybody know the procedure to get your own private_enterprise MIB
variables for SNMP ? From whom do I request the number(s) from? Is there
a cost involved? If so, how much?

Also, if anyone has experience making their own private_enterprise specific
MIB variables, would you please tell me how you went about it?

I apologize for making these questions so broad, but I've never had to create
an enterprise specific MIB variable before.

			       Thanks in advance,


			       Tuula 

			       tuula@gvlf6.gvl.unisys.com

-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 21:49:09 GMT
From:      latzko@pilot.njin.net (Alex )
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject:   Re: TCP-IP over X.25 between 3B2 and 6386E PC

In reference to using X.25 to connect them..  You would save yourself
much grief if you punt X.25 entirely and get a pair of XT's and use
pcroute.

Not only do you ace the X.25 overhead, but you also get rid of the
cost of X.25 ( which has got to be more than the 1.5K two pcrouters 
would cost.  Want details give me a yell

alex

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 21:50:53 GMT
From:      scooter@genie.UUCP (Scooter Morris)
To:        comp.protocols.tcp-ip
Subject:   Re: Where can i get a POP3 server for 4.3 BSD UNIX ?

From article <3469@puff.cs.wisc.edu>, by tannenba@cat17.cs.wisc.edu (Todd Tannenbaum):
> 
> I am trying to locate a POP3 (Post Office Protocol ver 3) server that will
> run on 4.3 BSD UNIX.  It is important to me to obtain version 3, NOT version
> 2.  It does not have to be version 3 extended, although that would be
> nice..... If someone knows how to obtain a POP3 server (via anonymous ftp,
> preferably), please respond to me either directly or in this newsgroup.
> 	Thanx!  -Todd Tannenbaum
> 		 tannenba@garfield.cs.wisc.edu 
> 			-- OR --
>                  tannenba@zs.engr.wisc.edu

Genentech has written a POP3 server for 4.3 BSD, as well as a Macintosh
client.  It uses /usr/spool/mail as the postoffice file, so this
implementation may not be for everyone.  If anyone is interested,
send me a mail message, and I would be happy to make it available.

					Scooter Morris
					Scientific Computing
					Genentech, Inc.
					scooter@genie.gene.com

-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 23:06:58 GMT
From:      rick@NRC.COM (Rick Wagner)
To:        comp.protocols.tcp-ip
Subject:   Re: Question on Fusion Software

In article <8910251542.AA10077@Kodak.COM> you write:
>Hi Netlanders,
>	We have some people in Japan that are using a tcp-ip package called
>	FUSION on their Fujitsu fmRT pc's.  The question is, Is this the
>	same Fusion software that we have here in the States?  We need some
>	documentation on how it works to do some testing.
>
>	Thanks for the help.
>
>Rich Messinger
>Eastman Kodak


Yes it is, though the Japanise version is a little older, and somewhat
modified from the locally distributed version.  The program interface
and related docs should be the same, however.  I passed your message
to our customer support guy.  You can get mail to him at
bruce@NRC.COM.  I don't have the mail addrss for NRCJ, but if you need
it, I might be able to get it for you.  I they are not on the
Internet, but they MIGHT have UUCP access.  Usually we just FAX them.
-- 
===============================================================================
Rick Wagner						Network Research Corp.
rick@nrc.com	rick@nrcvax.UUCP			2380 North Rose Ave.
(805) 485-2700	FAX: (805) 485-8204			Oxnard, CA 93030

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      26 Oct 89 23:47:23 GMT
From:      wicinski@zamna.sgi.com
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs


In article <KARL.89Oct24124105@cheops.cis.ohio-state.edu> you write:
>I have to disagree, Henry.  If the problem is reaching unregistered
>sites, the solution is to register them - somewhere - I'm not sure I
>care where.  NIC-registered domains are fine, comp.mail.maps UUCP
>registration is nearly as fine in a practical sense; other registries
>exist, but those are the two I deal with most.

Sorry dude, but i have to disagree. To say "register your domain" is
easier said than done. As someone who has registered his own .COM domain,
(not sgi.com) after growing tired of .US domains, it is NOT trivial. If
you're not connected to the Internet, you dig up a uucp connection (no
problem), then you fill out all the NIC forms and try to comprehend the
catch-22 (do you need a network #, well you need a domain. you need a
domain? you have someone to sponsor you? etc, ad nauseum). THEN you
have to go around and grovel at people who have MX nameservers to see
if they will put in records for you (luckily i found two people who
did), and then MAYBE if the net dieziens decide you are "okay", they
give you a domain.  Sure, you could pay uunet 35 bucks for almost the
same thing, but their forms are just the NIC forms redone, and they
stay make you look for the nameservers yourself.

>Getting registered is easy.  Building a gateway is easy.  They're both
>too easy to go to the effort of avoiding the issue with things like %
>hacks.

Becoming registered is NOT easy.   Getting connected is not a simple
task either. If you really want people to "join your network" there
should be a place where the rules are laid out CLEARLY (the nic is
helpful in general, but not that awesome), and perhaps there could be a
place where people can go look at past registrations to get an idea
(that's the main bitch), AND if there was some place joe geek who wants
to register his pc with a .COM domain can go look for a list of people
who will be willing put an alias in his/her nameserver for them, THEN
MAYBE it might become easier to join, and then we can do away with the
damn % hack.

tim

-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 00:10:25 GMT
From:      peiffer@umn-cs.CS.UMN.EDU (Tim J. Peiffer)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   Networking alternatives

With all of the talk of Ethernet alternatives, and serial line multiplexing,
I would like to find out the status of projects such as SLIP with reference
to workstation devices such as IBM PCs, Macintosh's, and Sun's.  I have heard
that device drivers work for these, but I have not seen a complete 
implementation yet.  Can anybody point me to them?

I would like to make use of an existing slip network driver such as an
Annex II terminal server to expand our building network out to remote research
sites, giving our Prof's and grad students the horsepower and flexibility 
of ethernet without the expense and bother of leased line or ethernet.  Another
possibility I am interested in is making a MacII as a router between a slip 
gateway and his localtalk net.

Tim Peiffer		peiffer@cs.umn.edu	or
Computer Science Dept	...!rutgers!umn-cs!peiffer
University of Minn
Mpls, MN	55455

-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 01:22:30 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: How do you string a thinnet?

In article <431@cutsys.UUCP>, cutter@cutsys.UUCP (Bernie Hoffstadt) writes:
> 	That is, until I started thinking about extending our net-
> work to the Sales building.  It's currently confined to our Service
> building.  We already have a bunch of (presumably twisted-pair,
> though I wouldn't swear to it -- looks like a gob of 22 guage solid
> wire packed into a sheath) phone wiring installed between the two
> buildings, only half of which is in use for the phones.  I wanted to
> use this to make the link.

Well, you could use any of the 10BaseT (draft) twisted pair stuff,
but -- if you're going between buildings I *very* strongly suggest
that you use fiber.  It's worth it for a variety of reasons, especially
during thunderstormseason.

-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 03:31:41 GMT
From:      rick@uunet.UU.NET (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

In article <8910252236.AA14405@alw.nih.gov>, RAF@CU.NIH.GOV ("Roger Fajman") writes:

> P.S. - If it's all so easy, how come the From address in the message
> that I am replying to had an ! in the local part?


Why do you care whats in the LOCAL part? It's none of your business.

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Oct 89 10:49:20 -0400
From:      Andy Malis <malis@BBN.COM>
To:        tcp-ip@nic.ddn.mil
Cc:        malis@BBN.COM
Subject:   ISO specs online?
Does anyone know if or where the following ISO specs are
available by FTP?

8473 - Connectionless-mode network service

9542 - ES-to-IS routing exchange protocol

Thanks much,
Andy Malis <malis@bbn.com>    UUCP: {harvard,rutgers,uunet}!bbn!malis
-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      Fri, 27 Oct 89 08:39:23 EDT
From:      steve@umiacs.UMD.EDU
To:        brian@ucsd.edu (Brian Kantor)
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: MX-registration vs %-hack (was Re: New Host-Requirement RFCs)
   The kludge solution I use (and which seems to work fairly well) is to
have a number of central maildrop names, all of which can accept mail for
any user or alias within the group of machines they hide.  Each maildrop
is listed in HOSTS.TXT, and has both an A record (even if it *shouldn't*)
and a set of MX records within the DNS.  All of the hosts hiding behind 
a particular maildrop rewrite their headers so that 'local' addresses are
qualified with the name of the maildrop.

   For example, consider maildrop umiacs.umd.edu.  This is a nicname for
grinch.umiacs.umd.edu in HOSTS.TXT.  A nameserver lookup for A records for
this name will return 128.8.120.3.  (These records should not be needed, but
there's a nontrivial number of broken sendmails Out There that are smart
enough to look for A records in the DNS, but not smart enough to look for MX
records.  Sigh.)  There are also two MXes for umiacs.umd.edu, pointing at
hosts skippy.umiacs.umd.edu and whizbang.umiacs.umd.edu.  Any machine within
my organization sends mail that appears to be from (or From:)
user@umiacs.UMD.EDU.  Grinch, skippy, and whizbang all know how to reforward
any mail to the machine the mail should have gone to in the first place.

   It Just So Happens that almost every machine within my organization is
capable of receiving mail directly, so mail to (say)
user@fnord.umiacs.umd.edu still works.  There are MXes in place where
necessary to redirect mail or to help with the (less common these days,
since the Internet is so much improved) no-MX race condition.  By hiding
information in this way, I can make almost arbitrarily brain-dead hosts
happy with a relatively small number of glue records.  I also realize that
having the maildrop name as a nickname in HOSTS.TXT is somewhat wrong (a
technical violation of RFC 822, I think), and that having this synthesized A
record sitting around is also somewhat gross and is perhaps wrong itself,
but if someone is running broken software, they deserve what they get.

   Having names like umiacs.umd.edu or cs.umd.edu also means that people in
the Internet don't have to remember so many individual mail addresses, and
when they have to guess an address ("gee, let's send to Joe, he's at the
UMCP CS Department"), they've got a bigger chance of getting it right.
Having an easy-to-guess and easy-to-remember name is enough of a good idea
that even the X.500 people thought it worth mentioning.  (See section A.3.3
in X.500.)

   The biggest pain is (for many organizations, though it wasn't bad in the
CSD/UMIACS corner here) in getting the administrative clout to ramrod such a
scheme through in the first place.  Keeping a set of aliases on the primary
maildrops up-to-date is also a pain, but some thought and a thousand or so
lines of C takes care of that problem.  Lots of sites do this; I mention my
scheme for the benefit of those who might be thinking about putting
something similar in place.  (Finding out about the A-but-no-MX sendmails
was something I should have expected, but a surprise nonetheless...)

	-Steve

Spoken: Steve Miller    Domain: steve@umiacs.umd.edu    UUCP: uunet!mimsy!steve
Phone: +1-301-454-1808  USPS: UMIACS, Univ. of Maryland, College Park, MD 20742
-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 09:39:27 GMT
From:      palowoda@fiver.UUCP (Bob Palowoda)
To:        comp.protocols.nfs,comp.protocols.tcp-ip,comp.dcom.lans
Subject:   PC-NFS and 386 UNIX


  Has anyone configured large NFS systems with DOS NFS 3.0 clients?
  (NFS on a 386 type UNIX)

  I'm interested on comments about which eithernet card you used?
  8bit, 16bit dumb or intelligent.

  I have been useing Excelans which seem to be fast and was wondering
  if the WD8003E would work without to much performance degradation.
 
  Did anyone compile SOS on NFS 3.0 and get a server working on the
  DOS side?  Or has anyone tried SOS on Interdrive?

---Bob 

-- 
Bob Palowoda  pacbell!indetech!palowoda    *Home of Fiver BBS*  login: bbs
Home {sun|daisy}!ys2!fiver!palowoda         (415)-623-8809 1200/2400
Work {sun|pyramid|decwrl}!megatest!palowoda (415)-623-8806 2400/9600/19200 TB
Voice: (415)-623-7495                        Public access UNIX XBBS   

-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 12:56:14 GMT
From:      mcneill@eplrx7.uucp (Keith McNeill)
To:        comp.protocols.tcp-ip
Subject:   Re: How do you string a thinnet?

From article <431@cutsys.UUCP>, by cutter@cutsys.UUCP (Bernie Hoffstadt):
> --------
> In article <8910241805.AA26176@gaak.LCS.MIT.EDU> Michael A. Patton writes:
>>>
>>> Now the $64k question: Is there a good reference for this kind of
>>> info.
>>
>>Gee, you found one I don't have a good answer to.  I use lots of
>>references, the most important being my experience and what I've
>>learned talking to others (in forums like this and just standing
>>around in the corridors at conventions :-).  I've been hacking
>>Ethernet (and Ethernet-like technologies) since the late 70's and
>>haven't found the need recently of an overview book specifically
>>oriented at Ethernet and I don't seem to have such in my collection.
>>

I've found that 

"Unix System Administation Handbook" by Evi Nemeth (ISBN #0-13-933441-6) a
really good reference.  It's mostly based on BSD unix.  There is a large
chapter on networking.  

Keith
-- 
    Keith D. McNeill              |    E.I. Du Pont de Nemours & Co.
    eplrx7!mcneill@uunet.uu.net   |    Engineering Physics Laboratory
    (302) 695-9353/7395           |    P.O. Box 80357
                                  |    Wilmington, Delaware 19880-0357
--
The UUCP Mailer

-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 13:45:51 GMT
From:      pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: MX-registration vs %-hack (was Re: New Host-Requirement RFCs)

In article <31038@news.Think.COM> barmar@kulla (Barry Margolin) writes:

   1) Users have to remember gateways.  smart@ditmela.oz.au is easier to
   remember than smart%ditmela.oz.au@uunet.uu.net.

   2) % isn't the only such hack, and it's not always clear what happens when
   multiple hacks are used together.  What is the meaning of foo!bar%baz@quux?
   Is it quux -> foo -> baz -> user bar or quux -> baz -> foo -> user bar?

True, true, and this is why domain names are *a good thing*.


   3) Problems occur when network topology changes.  If uunet.uu.net is
   replaced as the Internet->UUCP gateway, all the %host@uunet.uu.net
   addresses are invalidated.

Ahhhhh. This is the crux: %host@uunet.uu.net is a *route*, not an address.
In the absence of centralized administrative control, users will *always*
be required to eventually use routes; the address->route translation cannot
be *always* performed by some kind of distributed database, without centralized
administrative control of *both* the naming and transport.

I am one of those that think that centralized administrative control is not
only impossible, it is also not very desirable. People that do not see beyond
the Internet think otherwise on both accounts.

   This means that users must learn a new gateway,
   and mailing lists all over the place have to be updated.  The domain system
   simply requires updating the database, and users never notice.

Ahhhhh. Another difference of point of view. You are assuming
there is a benevolent entity that automagically updates in real
time (or close enough) the naming and routing distributed
databases. This does not happen in the real world, *even* on the
Internet (where it is close enough though). Lazy or untrained
system administrators, mistakes, etc...

   5) You're dependent on an arcane, nonstandard feature being implemented on
   a host over which you have no control.  Uunet may decide at any time to
   stop supporting %, and you'll run into problems.

   Besides encouraging hosts to switch away from %, I think they are also
   encouraging new systems NOT to implement it in the first place.

Yes, but what is the alternative for source routing? The multiple
"@" hack is not an answer... Note that you cannot say "don't do
it", unless you have centralized control over naming and
transport.

Again and again I am skeptical of the feasibility of doing this;
it is already difficult (and I occasionally think it is
impossible) to switch away from relative naming, because it is
difficult enough to have centralized control over the namespace;
to have centralized control over transport is probably impossible
or even undesirable.

Again and again I think (nostalgic) that if everybody had adopted
the Usenet/uucp bang notation for BOTH naming and routing
everybody would be happier now (well, I would have liked to have
more then 7 chars for host names, to make it easier to have
unique names, or to support dot notation for domains).

   More importantly, it sends a signal to implementors not to try related
   kludges. For instance, I've heard of systems that try to parse non-local
   local parts, in an attempt to optimize routes.  They see foo%bar@baz,
   realize that they know a host named "bar", so send the message directly to
   bar rather than routing through baz; this loses if baz doesn't interpret %
   as they think it does, or if baz has a different notion of the host bar.

Amen! May the heathen be stricken by data rot!
--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk

-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 14:35:03 GMT
From:      rick@uunet.UU.NET (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

In article <1136@odin.SGI.COM>, wicinski@zamna.sgi.com writes:
> give you a domain.  Sure, you could pay uunet 35 bucks for almost the
> same thing, but their forms are just the NIC forms redone, and they
> stay make you look for the nameservers yourself.

No. The $35 is to pay for the hassle involved with reading and correcting the
forms (30% arrive with errors in them) and for RUNNING THE NAMESERVERS.

Frankly the $35 one time fee doesn't cover the time and effort involved.

What we do make you do is find your own FORWARDER (not too hard)
or get the PERMISSION of a site directly connected to uunet to allow
your mail to be forwarded through them (not an unreasonable position).

uunet provides over 400 nameservers of the type you describe.

It IS easy.

---rick

-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 15:21:00 GMT
From:      CAMPBELL-Z@OSU-20.IRCC.OHIO-STATE.EDU (ZEB)
To:        comp.protocols.tcp-ip
Subject:   ncsa telnet for mac

I am trying to locate ncsa telnet for mac machines.  Is this available
at Baker Systems??? if so where and from whom??

                    Larry Campbell
                Technical Lab Manager
                 Dept of Psychology
                 121 B Lazenby Hall
                       2-5810

campbell-z@osu-20.ircc.ohio-state.edu
-------

-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 16:17:53 GMT
From:      key@UTKUX1.UTK.EDU
To:        comp.protocols.tcp-ip
Subject:   Anyone got SLIP on SparcStation 1's working?

Greetings,
    Has anyone successfully used the slipware available from
neat.ai.toronto.edu to communicate between SparcStation 1's?
I'm running SunOS 4.0.3c (they changed the kernel for the Sparc)
and two Telebit T2500's at 19200.  I had SLIP working between a sun 3/60
and a sun 3/260 running 4.0.3 and the same modems with just a minor
routing bug in the tip-with-slip program.  With the sparc's, I get zs0 ring
buffer overflows causing loss of characters including frame characters,
which tended to get SLIP pretty confused.

I'm pretty sure the buffer overflow a flow control problem (but the folk 
I've talked to about SLIP all stressed turning off flow control - I presume 
for data transparency).  I've heard that the zs controller is not really
meant for high data speed and has difficulty with input > 4800 baud.
Was my success in using SLIP with the zs ports on the Sun-3's dumb
luck and folks are using the ALM's, etc for their SLIP work?  Has anyone
played with the RTS/CTS flow control?  I didn't have any luck getting
that to work, but didn't have much time to invest.

Another problem I have is that when running FTP I can get logged
in and change directories, but any attempt to open a data path
connection (say a 'get' or an 'ls') gets "ftp: bind: can't assign
requested address".  While I know what this message represents, I can't
imagine what SLIP could have done to keep the data channel from being
allocatable.  

If anyone has info on SLIP on sparc's or war stories about SLIP
on 4.0.3 and the zs interfaces and/or Telebits, it would be much 
appreciated.  E-mail info and I'll summarize for those who request
copies of the info.


Thanks in advance,
Ken Key    (key@utkux1.utk.edu)
Univ. of Tennessee Computing Center

-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 16:41:05 GMT
From:      randall@UVAARPA.VIRGINIA.EDU (Randall Atkinson)
To:        comp.protocols.tcp-ip
Subject:   (none)

To: fasteddy@sdcdcl.span.nasa.gov, tcp-ip@nic.ddn.mil
Subject: Re: BITNET clarifications...
In-Reply-To: <8910261347.AA09691@gemini.arc.nasa.gov>
Followup-to: comp.protocols.misc
Distribution: inet
Organization: University of Virginia, Charlottesville

The problem of someone somewhere else filling up a node's
spool partition is to my mind serious, as is the ability of users
on a given node to "send" files to themselves and thus get 
disk storage space that isn't part of their account's quota
(both are known problems at BITNET sites). 

I consider "denial of access" to resources to be a security 
concern and yes there are mechanisms in most networking systems
that in greater and lesser ways can do this.  On some systems,
one can fill spool partitions by sending a high volume of mail;
it would also tend to fill up the network channel.

A number of people seemed to feel that I have an "anti-BITNET"
stance which simply isn't true.  I do have a high level of sensitivity
to security (some mail has suggested "excessive" :-).  My own
experience is that many sites simply aren't concerned with it.
It wouldn't be my own decision, but it's their business how they
choose to run their systems (like the %-hack which I dislike a great
deal, but it _is_ in the local part of the address).

This no longer really concerns TCP/IP, so I've redirected
followups to comp.protocols.misc on the USENET side...

The Australian notion of a batch-oriented "getfile" application
sounds interesting and could probably be implemented without
too much trouble on the Internet for anonymous ftp if someone
were so inclined...


Ran

Disclaimer:  As noted originally, I'm an ordinary user here on 
  uvaarpa and have nothing to do with the systems mgmt here.  I
  am involved with internetworking efforts on the systems at work 
  though.

-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 16:46:32 GMT
From:      karl@cheops.cis.ohio-state.edu (Karl Kleinpaste)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

raf@cu.nih.gov writes:
   But CompuServe is essentially a single host

No, it most emphatically is not.  There are numerous subdomains of
compuserve.com.  E.g.,
	csi.compuserve.com	CompuServe, Incorporated (employees)
	doi.compuserve.com	US Department of the Interior
	ncr.compuserve.com	NCR is a CompuServe business services customer
and if there weren't blocks in place on both sides of the gateway,
these would work:
	fax.compuserve.com	email => FAX
	mci.compuserve.com	(oh, just imagine what MCI would have
				 thought of that...:-)
CompuServe has hundreds (thousands?) of business services customers,
plus connections to (what I understand is) quite a variety of external
gateways.  They are all addressable.

Internally, an address somebody@csi.compuserve.com translates to
something twisted like ">csi:somebody."  There are 3rd-level
subdomains of doi.compuserve.com as well (e.g., fws.doi.compuserve.com,
mms.doi.compuserve.com); I don't even know how those addresses map
internally.

   When you have a network of many non-Internet
   hosts operated by independent organizations the problem becomes much
   more difficult.

I operate nameserver and mailer arrangements in varying levels of
peculiarity for something like 20 organizations, not including
anything at Ohio State proper.  That's the sort of thing I do in my
spare time, for fun.  Anyone with a serious, job-dedicated need to do
such things could manage an order of magnitude more than that with
little change in complexity.

   One can either adopt domain naming on the non-Internet
   network (as the UUCP network did, I believe) or build some sort of
   translation between the two name spaces into the gateway.  Neither one
   is necessarily very easy to do.

If it isn't trivial to do, then the organization's internal mailer
arrangement is in a serious state of disrepair, and deserves to be
overhauled anyway.  CompuServe's internal arrangement appears to me to
be internally consistent, so the mapping is truly trivial.  There was
no internal overhaul in their case.  In fact, the original,
proof-of-concept alpha test gateway didn't affect any software on the
CompuServe side at all.  CompuServe literally didn't know what I'd
built until I told them (by writing mail to relevant people through
the gateway, of course :-).

   In the latter case, the biggest
   problem is getting all the organiztions registered and collecting the
   information to do the translation.

Each organization can be responsible for providing such a collection
of registry information.  If the organization can't provide that sort
of information, I really must question their ability to manage email
of any kind.  Even FIDONet manages that (fidonet.org, IFNA
[International FIDONet Association]).

   And when you are done, users still
   have to be aware of two forms of addresses.

CompuServe users are aware of only one generic style of addressing:
">GatewayName:WhateverThatGatewayUnderstands".  Thus, they address FAX
stuff as >fax:phone#, and MCIMail users as >mci:someusername, and
Internet sites as >internet:user@host.domain.  Very generic, in their
view.  Similarly, I prefer only one addressing standard, domain style,
and that's all I have to deal with for CompuServe.

   If I'm on XYZ net (which
   does not use domains) and I want to tell my friend on the Internet how
   to mail to me, I will still have know the name of my host on the
   Internet.

That is exactly why the concept of the DNS works so well.  Tell me, on
what network does CompuServe exist, that they get email of any kind?
You don't know - you don't have to know, and that's the whole point of
domains.  They remove the transport-centric forms of mail addressing
and leave that to lower levels of software which care where the bytes
get sent.  Users don't (shouldn't) care.  The idea of telling someone
"I'm on XYZ net" is passe'.  (BTW, if you're guessing, no, CompuServe
is not UUCP-based, either.  Should I have created "B-Protocol Net" and
then tried to tell everyone, "CompuServe is addressable as
user.name@compuserve.bprot," after the fashion currently required by
non-DNS-cognizant BITNET sites?  Only inertia keeps .BITNET alive.)

For that matter, on what network is, e.g., MorningStar.COM or HDL.ORG
or UDayton.EDU, entities for which I also do nameservice and mailer
support?  Same response: You don't know because you shouldn't care.
The mail "just gets there."  If your network doesn't use domains, it
should, and it is very clear to me that this is not because it is "the
Internet standard," but rather because it works, from anywhere.  All
you need is a way to query the DNS registries.  UUCP does this via
comp.mail.maps info, the Internet via nameservers.

   P.S. - If it's all so easy, how come the From address in the message
   that I am replying to had an ! in the local part?

My mailers and news software generate @-format DNS, RFC-compliant
addresses in every case except for UUCP mail gatewaying, and even
then, it's still usually @-format.  I posted my note as a Usenet news
article, guaranteed to have been in @-format as
karl@cheops.cis.ohio-state.edu.  If you've got a ! in the From:
address, it's because somebody's gateway mailer botched the job.  An
error in implementation does not invalidate the standards which were
supposed to have been implemented.

--Karl

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 17:09:32 GMT
From:      ccruss@ucdavis.ucdavis.edu (Russ Hobby)
To:        comp.protocols.tcp-ip
Subject:   Re: Router interoperability

Well here is the word from the Point-to-Point Protocol (PPP)
workgroup.  We will have a final draft at the end of IETF next week.
The major router vendors (as well as workstation and terminal server
vendors) have been participating in the workgroup all along. Most of
the router vendors say that they will have PPP in their next release.

PPP has been designed to handle multiple protocols, not just IP, so
DECNET and other protocols will be transported in a standard method
over the link. PPP has many other features such as link establishment,
error detection, link testing, authentication, encryption and IP
address negotiation and is extendible for adding new protocols and
features and as such there is still work to be done on the protocol. 
For example only a simple user/password authentication is currently
defined. A more secure method would be desirable. Also, although the
method of encryption can be negotiated, no methods have been define
at this time.

In answer to Guy's question, it will be equilvalent to pluging the two
routers into an ethernet.  PPP does not solve all the router
interoperability problems though.  It does provide a standard method of
getting the packets across the wire, but it doesn't solve the routing
problem. Currently RIP can be used, but it has a lot of limitations. It
seems that OSPF will be the next improvement and it appears the
Internet community has agreed that it will be the next step. But even
OSPF will not solve all the long term routing problems.  That is still
a subject for research.

There have been to independent implementations of PPP. One by
UC Davis for PCs based on the KA9Q code and the other by CMU for
4.3BSD.  These implementations were done to test the protocol and to
find any weakness.  As we know one implementation may be perfectly
compatible with itself but not with others, so that's why we did two
independent ones.  Both of these systems were demonstrated
interoperating at INTEROP. The implementations will soon be publicly
available and we encourage porting to other systems.

Russ
                                Russell Hobby               
                         Data Communications Manager 
     U. C. Davis                 
     Computing Services      INTERNET: rdhobby@ucdavis.edu  
     Davis Ca 95616          BITNET:   RDHOBBY@UCDAVIS  
     (916) 752-0236          UUCP:     ...!ucbvax!ucdavis!rdhobby 

-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 17:11:27 GMT
From:      cdash@boulder.Colorado.EDU (Charles Shub)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: Stanford enetfilter

In article <561@alias.UUCP> mark@alias.UUCP (Mark Andrews) writes:
>Recently, I have seen references to an ethernet filter for BSD systems
>written at Stanford:
>
>	On 4.3 BSD systems, these functions are implemented using
>	the Stanford enetfilter device driver in the user-contributed
>	software.
>
>Is this filter available anywhere. I don't have easy access to the internet, so
>if it is not too big, I would appreciate it if someone could mail it to me.

we attempted to add this, and had some problems because there were some 
changes in 4.3 that weren't made to the filter code. As i recall, there was
a problem with MCLGET having been redefined. We put together a fix that
works most of the time. has anybody REALLY made the fix. we are runing Mt.
Xinu 4.3+NFS and doing a strings on vmunix reveals
		4.3 BSD UNIX #0: Wed Aug 31 14:48:24 MDT 1988

charlie shub  cdash@boulder.Colorado.EDU  -or-  ..!{ncar|nbires}!boulder!cdash
  or even     cdash@colospgs (BITNET)     -or-  (719) 593-3492

charlie shub  cdash@boulder.Colorado.EDU  -or-  ..!{ncar|nbires}!boulder!cdash
  or even     cdash@colospgs (BITNET)     -or-  (719) 593-3492

-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 17:18:21 GMT
From:      mark@alias.UUCP (Mark Andrews)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   Ethernet filter

This is a reposted article.

Recently, I have seen references to an ethernet filter for BSD systems
written at Stanford:

	On 4.3 BSD systems, these functions are implemented using
	the Stanford enetfilter device driver in the user-contributed
	software.

Is this filter available anywhere. I don't have easy access to the internet, so
if it is not too big, I would appreciate it if someone could mail it to me
or let me know where to find it.

	Thanks,

		Mark

------------------------------------------------------------------------------
	Mark Andrews
	Systems Programmer,
	Alias Research,
	Toronto, Canada
Phone:	(416)-362-9181
UUCP:	mark%alias@csri.utoronto.ca

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 20:40:24 GMT
From:      colin@tenset.UUCP (Colin Manning)
To:        comp.protocols.tcp-ip
Subject:   rsh/rexec/rlogin protocol specs

I'm looking for the specifications of the rsh/rlogin/rexec protocols.

Does anyone know where I may get these ?

I dont have FTP access.

Thanks in advance, 

- Colin

-- 
-----------------------------------------------------------------------
| colin@tenset.uucp or        | Post: Tenset Technologies Limited,    |
|  ..!ukc!acorn!tenset!colin  |       Norfolk House,                  |
| Phone: +44 223 328886       |       301 Histon Road,                |
| Fax:   +44 223 460929       |       Cambridge CB4 3NF, UK.          |
-----------------------------------------------------------------------

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 21:29:39 GMT
From:      cliff@violet.berkeley.edu (Cliff Frost)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

In article <KARL.89Oct27124632@cheops.cis.ohio-state.edu> karl@cheops.cis.ohio-state.edu (Karl Kleinpaste) writes:
>...
>If it isn't trivial to do, then the organization's internal mailer
>arrangement is in a serious state of disrepair, and deserves to be
>overhauled anyway.

That's accurate enough (modulo the negative tone).  In other words: "If the
problem faced by a mail-relay is trivial, then it is trivial to solve."

The fact remains that universal MX records don't relieve all mail-relays
of the need to do source routing.  I'm sure the Host Requirements folks
understood the problem, but whichever way they could go is imperfect so
looks like they stayed with Architectural Purity.

	Cliff Frost

-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      27 Oct 89 22:29:34 GMT
From:      RAF@CU.NIH.GOV ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  BITNET -- Internet capabilities

> >I wish the Internet had BITNET-style sender-initiated file transfer
> >that did not require the sender to know the receiver's password.  It's
> >very convenient.  Sending files as email is not very user friendly.
>
> The ability of some arbitrary user elsewhere on a network I'm connected
> to to put files in my account without (at least) password protection
> is a security hole.  I'm glad my systems aren't directly connected to BITNET.
>
> ftp and sending files as mail do work, though I concede a better user
> interface could be devised if someone had the time (I don't).

You misunderstand the way that BITNET file transfer works.  While it's
up to the implementor, the general rule is that incoming files are
stored on spool or in some other temporary area.  The receiving user is
notified that a file is waiting for him.  He then is able to decide to
accept or reject the file.  If he accepts it, he generally is able to
rename it before it is stored in his own area.  Thus there is no
security loophole.

The whole business is analogous to mail.  The difference is in the user
interface at each end.  A file to be sent is not composed on the spot
and a file to be received is not displayed on the user's screen (except
upon request).  Files can be text or binary data.

The fact that people often UUENCODE files and send them as mail shows
that the desire for this type of file transfer is out there.
I've heard it said that the space required to store temporary copies of
tranfered files would be prohibitive.  BITNET sites generally do not
find that to be so.  Anyway, the space is being used anyway when the
files are being sent as mail.

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 89 02:22:08 GMT
From:      RAF@CU.NIH.GOV ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  New Host-Requirement RFCs

> > P.S. - If it's all so easy, how come the From address in the message
> > that I am replying to had an ! in the local part?
>
> Why do you care whats in the LOCAL part? It's none of your business.

The author of the message I refered to was making the point that everyone
on other networks, such as BITNET, should register a domain and use MX
records, so as to eliminate the need to use % in the local part.  Yet
that person had a ! in his local part, which is just as much of a hack
as %.  Sauce for the goose...

-----------[000411][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 89 02:29:30 GMT
From:      karl@cheops.cis.ohio-state.edu (Karl Kleinpaste)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

cliff@violet.berkeley.edu writes:
   (modulo the negative tone)

I am sorry if I came across harshly.  It was unintentional.

   The fact remains that universal MX records don't relieve all mail-relays
   of the need to do source routing.

I keep seeing people discuss these cases that are supposed to be
intractable in the DNS.  I've been hammering (repeatedly, sigh) on my
best personal example where it worked flawlessly.  Perhaps I'm seeing
things from the wrong end.  Can someone provide me with a real world
case where the % hack is _needed_?  (A pointer into the appropriate
spot in the HR RFCs will do, if applicable.)

--Karl

-----------[000412][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 89 03:19:02 GMT
From:      brnstnd@stealth.acf.nyu.edu (Dan Bernstein)
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet

So that nobody is misled by Mr. Placeway's comments, *I* will point out
that *we* are a small group, consisting of a few data communications
experts, several programmers, and me.

It should be patently obvious why we will go to some lengths to preserve
anonymity. One member would even lose professional status if he were known
to have contributed ideas to our projects. As I am the organizer and (so
far) prime mover of this group, and as I'm relatively flame-resistant, 
I am the natural choice for spokesperson; but for safety, the rest don't
even know each other's names.

As for Mr. Placeway's article:
> As a service to the SOA of Ohio-State.edu (among others), I feel
> obliged to point out that the "we" in this series of statements is the
> _Royal_ "We", rather than one indicating any offical part of the Ohio
> State University.

I don't understand how Mr. Placeway could have missed our disclaimer at
the top of each announcement: ``This project is not an official project
of The Ohio State University.'' Most people read the second sentence of
an article before responding to it.

> The people in charge there really do understand why this is, in
> general, a Bad Thing.

Perhaps so; the only ``merit'' comment that OSU IRCC has made is that
they feel that the user list could be a valuable service. But whatever
your alma mater thinks: how about the hundreds of users (plus however
many more at various anonymous ftp sites) who've picked up the user
list? How about the several articles of support in c.p.tcp-ip and in
c.p.tcp-ip.domains giving reasons that it is a Good Thing?

And, Mr. Placeway, how would you respond to the letter I received from
CERT (you have heard of CERT, I hope) asking for a copy of our hosts
table?

> In other words:
> 	g/We/s//I/g
> 	g/Our/s//My/g

I suppose, Mr. Placeway, that just because the only name on the Internet
Crucible is Geoff Goodfellow's, you assume that it was solely written by
him in his spare time. (Maybe it was---but I'm not going to run off and
post an uninformed article making such an accusation.)

---Dan Bernstein

-----------[000413][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 89 03:59:31 GMT
From:      rayan@cs.toronto.edu (Rayan Zachariassen)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

>Can someone provide me with a real world case where the % hack is _needed_?

I don't think so, mostly due to your definition of 'needed'.

A%B@C can always be expressed as A@B.C or A.B@C or similar (although it isn't
in general possible to translate in the other direction due to strange rfc822
tokens).  I doubt people would challenge the technical feasibility of doing
that.  The problem is when *YOU* don't control the mailer on C but you still
have to get to a host B that you know C knows because it is a local name,
nickname, secret host, in the backwaters of the campus, or whatever.  It isn't
reasonable to demand that every mail system is prim and proper and will
accept DNS names for all hosts it knows about, or translate a DNS name to
whatever magic needed on the remote host based on the hostname (as opposed
to the syntax used to address that host).  One has to deal with reality.  Alas.

rayan

-----------[000414][next][prev][last][first]----------------------------------------------------
Date:      Sat Oct 28 13:10:05 1989
From:      Randall Atkinson <randall@uvaarpa.virginia.edu>
To:        tcp-ip@nic.ddn.mil
To: fasteddy@sdcdcl.span.nasa.gov, tcp-ip@nic.ddn.mil
Subject: Re: BITNET clarifications...
In-Reply-To: <8910261347.AA09691@gemini.arc.nasa.gov>
Followup-to: comp.protocols.misc
Distribution: inet
Organization: University of Virginia, Charlottesville

The problem of someone somewhere else filling up a node's
spool partition is to my mind serious, as is the ability of users
on a given node to "send" files to themselves and thus get 
disk storage space that isn't part of their account's quota
(both are known problems at BITNET sites). 

I consider "denial of access" to resources to be a security 
concern and yes there are mechanisms in most networking systems
that in greater and lesser ways can do this.  On some systems,
one can fill spool partitions by sending a high volume of mail;
it would also tend to fill up the network channel.

A number of people seemed to feel that I have an "anti-BITNET"
stance which simply isn't true.  I do have a high level of sensitivity
to security (some mail has suggested "excessive" :-).  My own
experience is that many sites simply aren't concerned with it.
It wouldn't be my own decision, but it's their business how they
choose to run their systems (like the %-hack which I dislike a great
deal, but it _is_ in the local part of the address).

This no longer really concerns TCP/IP, so I've redirected
followups to comp.protocols.misc on the USENET side...

The Australian notion of a batch-oriented "getfile" application
sounds interesting and could probably be implemented without
too much trouble on the Internet for anonymous ftp if someone
were so inclined...


Ran

Disclaimer:  As noted originally, I'm an ordinary user here on 
  uvaarpa and have nothing to do with the systems mgmt here.  I
  am involved with internetworking efforts on the systems at work 
  though.

-----------[000415][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 89 09:51:30 GMT
From:      smart@ditmela.oz (Robert Smart)
To:        comp.protocols.tcp-ip
Subject:   Re:  BITNET -- Internet capabilities

In Australia there is a network, ACSnet, running Australian software
which also supports sender initiated file transfer in exactly the same
style as BITNET. It also has a batch-style equivalent of anonymous
ftp, called getfile. These capabilities seem extremely valuable. Many
people expect that ACSnet will continue to run over TCP/IP when
Australia has a real Australia-wide IP network, just to provide these
capabilities. Yet these capabilities could easily be implemented on
top of TCP/IP. I wish someone would do it.

Bob Smart

-----------[000416][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 89 09:52:01 GMT
From:      lear@NET.BIO.NET (Eliot Lear)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

Rayan Zachariassen writes that it isn't reasonable to expect sites to
demand that every mailer support DNS properly.  Yes it is.  How long
has DNS been out in the world?  It isn't reasonable to have to break a
model because system administrators won't upgrade their software, and
it is even less reasonable to introduce a new method to support the
old broken ones.  That is to say, why should we expect sites to
support the % hack, when we cannot expect other sites to support MXes?
The % hack is far from universal.

However, what you do with your local part is your business.
-- 
Eliot Lear
[lear@net.bio.net]

-----------[000417][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 89 10:22:26 GMT
From:      kre@cs.mu.oz.au (Robert Elz)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.domains
Subject:   Mail Source Routing (was Re: New Host-Requirement RFCs)

This discussion started on the TCP-IP list, I have added it
to Namedroppers, because this is clearly moving more into that
area.  Please reply to namedropers.  Usenet followups are directed
there.

In article <KARL.89Oct27222930@cheops.cis.ohio-state.edu>,
karl@cheops.cis.ohio-state.edu (Karl Kleinpaste) writes:
> Can someone provide me with a real world
> case where the % hack is _needed_?

Well, it turns out, I believe, that MX records are simply not
good enough for some real world situations.  Here's an example
using purely the internet (so no arcane protocols, etc) and
where everyone implements MX capable mailers, and uses the DNS.

Consider

	A ------- G ------- B

where A and B are internet clouds (large numbers of hosts,
over a large geographical area, with all the standard link
types, down hosts, ...)

G is a (single) gateway between the two clouds, and the lines
represent (single) links from the A cloud to the gateway,
and from the gateway to the B cloud.  (You can consider G
to be an isolated host/router, or a cloud containing both of
those on a LAN, or anything like that).

Now assume that those links (A-G and G-B) are unreliable,
for purposes of this example, assume that they're operational on
average 50% of the time (each, and for now, independantly).
Also assume that these links are relatively expensive to use.

Now try and define some MX records that will reasonably optimally
allow this overall system to exchange mail.

Clearly, as the overall link A--B is only operational 25% of the
time, its going to be much better for hosts in A to send mail
via G if the direct link isn't working .. that implies that hosts
in B have an MX pointing at themselves (or whatever in B), and
a second MX (lower preference) aimed at G, so if an A host
can't reach the B host, it will try to drop the mail on G
for later forwarding.

So far so good.  But now consider what happens when a host in B is
down, and another B host wants to send it mail .. the backup MX
will cause the mail to get sent across the expensive, unreliable,
link to G, just so it can come back later (perhaps by the time the
destination host has recovered, the G-B link is down, so it may be
a lot later).  This isn't good.

We can make the hop to G from inside B for mail destined to B less
likely by creating one (or more) other secondary MX targets in
B (for all hosts there) with preferences between that of the most
favoured target, and G's.  Now mail internal to B is unlikely to
end up at G, how unlikely depends on the number of extra MX's we
install.  However, now when an A host wants to send mail to a B
host, and the G-B link is down, the A host is going to have to
try LOTS of different possible destinations before finally trying
G, which means a lot of junk traffic over the A-G link.

Now, even if we accept that as not unreasonable, consider the
administrative overhead of all this .. every host in B has to set up
its nameserver so it has a number of alternate MX's in B, and
G as well.  Every one of them.

What's more, of course, all this is symmetric, so hosts in A
have to do all the same.  This is never going to work, especially
when you consider that new clouds like this, with new G's between
them can appear at any time, and the identity of a G can change
with little notice.

The more likely scenario is that hosts in A and B will just
set up their MX's in the normal fashion, ignoring G, and
users will learn that if they send mail to user%B@G (from an A
host) its likely to arrive rather faster than just using user@B.
(Substitute rfc822 route-addrs here if you prefer, source routing
is the issue, not syntax).

This is pretty close to reality ... the Australia - US link
is much like this, though its not symmetric.  munnari.OZ.AU is
effectively G, A is the US (North America, whatever) and B is
Australia.  The A-G link isn't bad, but G-B can be terrible
at the minute (2400 slip, IP over X.25 using CMU (VMS) TCP/IP
as the gateway, ...).  Mail from A into B at the minute is
faked, as the nameservers for B as seen from A and B
are totally different, ie: in A, all of B is just a wildcard
MX aimed at G, whereas in B, the true status is revealed.
This is obnoxious, but works, except for a few hosts in A
who choose to see the reality of B, and they do have problems
getting mail through - requiring backup MX's in B aimed at G
for many hosts in B where that would be absurd internally
inside B.

If anyone can suggest any (reasonable) magic solution to
this problem, I would love to hear it.  Note: changing the
nature of the A-G and G-B links is not reasonable, unless
you're willing to put up the $'s to do it.  Continuing to
support dual views of the nameservers is not the answer
either, that will cease soon, then everyone will start having
trouble getting mail to (some sites) in Aust, at least until
the internal Australian links are upgraded, or until users
learn the appropriate source route, and use it.

kre

-----------[000418][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 89 18:03:55 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

In article <Oct.28.02.52.01.1989.5606@NET.BIO.NET>, lear@NET.BIO.NET (Eliot Lear) writes:
>  ...              That is to say, why should we expect sites to
> support the % hack, when we cannot expect other sites to support MXes?
> ...
> Eliot Lear
> [lear@net.bio.net]

As I understand and use the stupid %-hack, it need not be supported by any
other site.  Rather, it is parsed here to allow mail from remote sites
suffering, for whatever reasons, trouble with MX wild cards.  A quick look
at the queue here shows a lot of mail to
@blah.de.blah,@sdaf...asdf:stuf%more@some.dom.ain   For many reasons, I'm
sure that such addresses were not invented here.  That is, a lot of people
are telling other people to use the %-kludge to reach them.

Some have proposed rewriting ! to % in mail passing thru a site.  That seems
Wrong.  


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000419][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 89 18:20:34 GMT
From:      rayan@cs.toronto.edu (Rayan Zachariassen)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

lear@NET.BIO.NET (Eliot Lear) writes:

>Rayan Zachariassen writes that it isn't reasonable to expect sites to
>demand that every mailer support DNS properly.  Yes it is.  ...
>... That is to say, why should we expect sites to
>support the % hack, when we cannot expect other sites to support MXes?

Eliot,  that's not what I said.  Perhaps I should rephrase:

I don't think it is reasonable to expect every site to map all the hosts
reachable from that site into the DNS.  Therefore there must be some way
of specifying the hosts that are not mapped in this way.  I don't care
which method is used but there must be some (perhaps specific to the site),
unless the intention is to have no communication.

There is a long way from "Your mailer must support the DNS" to "Your mailer
must ONLY support the DNS (from our point of view)".

This doesn't belong in tcp-ip, or anywhere else I can think of.  I'll create
a mailing list for this kind of stuff if people still want to discuss it.

-----------[000420][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 89 20:12:11 GMT
From:      chris@CS.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  BITNET -- Internet capabilities

>From: jqj@rt-jqj.Stanford.EDU (JQ Johnson)
>
>This ... is usually implemented as writing the files to a remote spool
>area where disk space is charged to the system rather than the target
>user, and the target user may retrieve the files or not within some
>reasonable time. ... The key feature that it has which SMTP-based email
>lacks is a standard (sort of) for sending non-textual data.  X.400 with
>its provision for arbitrary binary attachments may make this BITNET
>feature obsolete.  But Internet-only users should not be so
>narrowminded as to think that ftp is the "one true way" to manage file
>transfer!

	% ftp remotehost.biguniv.edu
	<greeting stuff>
	User: anonymous
	Password: me@here
	<restriction stuff>
	type image
	<image mode OK>
	put local-file incoming/remote-file
	<file goes across>
	quit

Now all we need is to write it up as an RFC (changing the `put
local-file incoming/remote-file' sequence to a new `give' command, so
that the `incoming/' can go away), and write a front end called `give'
or whatever that does the above automatically.  Hosts can expire stuff
in ~ftp/incoming, or whatever they name this spool directory, as often
as desired.

In other words, we need only one change to the FTP protocol (to add a
command that means `I am sending you a file that you should put in your
spool directory, whatever its name may be'), along with some front
ends so that `given' files are handled much like mail: spooled on
the local machine until the transfer can happen.
-- 
`They were supposed to be green.'
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris

-----------[000421][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 89 20:52:49 GMT
From:      srg@quick.COM (Spencer Garrett)
To:        comp.protocols.tcp-ip
Subject:   Re: 4.X implementations of TCP, initial sequence numbers, and windows

In article <2642@lll-lcc.UUCP>, rwolski@lll-lcc.UUCP (Richard Wolski) writes:
> 
> if(win > 0 && SEQ_GT(tp->rcv_nxt+win, tp->rcv_adv))
> 	tp->rcv_adv = tp->rcv_nxt + win;
> 
> What we notice is that another vendor's implementation of TCP chooses an
> initial sending sequence number with the sign bit set (sometimes) and that
> the rcv_adv field in the tcpcb always remains 0.  I think the following thing
> is happening.  SEQ_GT is defined as:
> 
> #define SEQ_GT(a,b)  ((int)((a)-(b)) > 0)
> 
> When expanded in the above code, (a) has the sign bit set, (b) is zero, so the
> test fails and rcv_adv never gets set properly.  This manifests itself
> as unusually large windows where one would not expect them.
> 
> My first question:  Am I reading this right?  I checked the code to set the
> iss on the sending side, and it periodically increments a global variable
> which eventually results in a negative number (when viewed as an int).

This is the key.  Sequence numbers are unsigned values which must be
interpreted modulo 2**32.  Thus, the sequence number following
0xffffffff is 0, and the difference of these two is 1.  On a machine
with 32 bit ints this can be accomplished by subtracting the two
sequence numbers, ignoring overflow, and casting the result to a signed
integer.  If the int's on your machine aren't exactly 32 bits long,
however, this algorithm won't work correctly.

My guess is that your code isn't initializing tp->rcv_adv during
TCP startup.  You should be setting rcv_nxt from the initial sequence
number you get from the peer host in the SYN packet (plus 1 for the
SYN), and you should initialize rcv_adv to rcv_nxt plus your initial
offered window.  The code you've quoted above only sets rcv_adv
when it thinks it's extending the window.  If rcv_adv is zero and
rcv_nxt has its "sign" bit set, but isn't close to the top of the
range, then the window looks huge, so your code never thinks it
should be extended.  If the sign bit were clear, however, then
the window would appear negative, and your code would happily reset
it the first time through.

-----------[000422][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 89 21:05:45 GMT
From:      barmar@kulla (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: MX-registration vs %-hack (was Re: New Host-Requirement RFCs)

In article <PCG.89Oct27134552@rupert.cs.aber.ac.uk] pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) writes:
]In article <31038@news.Think.COM] barmar@kulla (Barry Margolin) writes:
]   This means that users must learn a new gateway,
]   and mailing lists all over the place have to be updated.  The domain system
]   simply requires updating the database, and users never notice.
]
]Ahhhhh. Another difference of point of view. You are assuming
]there is a benevolent entity that automagically updates in real
]time (or close enough) the naming and routing distributed
]databases. This does not happen in the real world, *even* on the
]Internet (where it is close enough though). Lazy or untrained
]system administrators, mistakes, etc...

Oh, and who is the benevolent entity that fixes all the explicit routes in
mailing lists, not to mention the ones in people's heads?

My assumption is that the MX information is stored in fewer places, so
fewer benevolent entities need be involved.  It's true that if a major
forwarder, such as uunet, goes away the necessary updates are extensive in
both cases, but I think they're orders of magnitudes more extensive when
explicit routes are involved.  When a fringe forwarder goes away it only
affects a small portion of the domain database, but the affected hosts may
be referenced in files on many other hosts.

Barry Margolin, Thinking Machines Corp.

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

-----------[000423][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 89 21:24:11 GMT
From:      barmar@kulla (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re:  BITNET -- Internet capabilities

BITNET-style file transfer is easily accomplished using FTP.  Many FTP
servers support anonymous FTP, which generally restricts the user to a
subset of the file system (on Unix it's generally a particular subtree, on
TOPS-20 it's world-accessible directories).  Sender-initiated file transfer
is done by using FTP to put the file into a directory to which anonymous
FTP has write access, then sending mail to the recipient telling him the
file's name.

Some BITNET hosts may provide better access control over the spool area
than the above, because the protocol includes the recipient's name and it
can distinguish writable spool areas from readable spool areas.  But for
many purposes the above mechanism is adequate.

Barry Margolin, Thinking Machines Corp.

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

-----------[000424][next][prev][last][first]----------------------------------------------------
Date:      28 Oct 89 22:54:50 GMT
From:      dcrocker@DECWRL.DEC.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Mail Source Routing (was Re: New Host-Requirement RFCs)

I have been waiting for someone to observe that static entries in a
data base do not work for routing information..

Thank you.

The MX mechanism is fine for real 'off-net' mail relaying.  It does
NOT work as a means of communicating complex and/or dynamic and/or
alternate routes.

Your scenario exemplifies this limitation.

The %-hack doesn't fix the problem.

It does, however, let knowledgeable users source-route around some of
these types of problems.

That is, if you are a wizard, you can make up for a basic deficiency
in the mail architecture.

Note that IP-level routing can, albeit slowly, discover alternate routes.

d/

-----------[000425][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 1989 05:21-EST
From:      CERF@A.ISI.EDU
To:        nisca.ircc.ohio-state.edu!hpuxa.ircc.ohio-state.edu!bernstei@TUT.CIS.OHIO-STATE.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet
Dan,

tell me more about sites which do not have reliable DNS access -
I'd like to pursue fixing the access problem. 

Vint
-----------[000426][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 1989 05:29-EST
From:      CERF@A.ISI.EDU
To:        rick@UUNET.UU.NET
Cc:        mstar!mstar.morningstar.com!bob@TUT.CIS.OHIO-STATE.EDU, tcp-ip@NIC.DDN.MIL
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet
Rick,

No that's an interesting suggestion (getting DCA to stop supporting
hosts.txt table). I imagine a number of mailers would stop functioning
adequately (if one can say they function adequately even now, if
they depend on the hosts.txt table). Perhaps we should try to take
a poll to find out who would object to such a course of action?

Vint
-----------[000427][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 89 00:58:59 GMT
From:      amanda@intercon.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

In article <89Oct27.235825edt.2687@neat.cs.toronto.edu>, rayan@cs.toronto.edu
(Rayan Zachariassen) writes:
> It isn't
> reasonable to demand that every mail system is prim and proper and will
> accept DNS names for all hosts it knows about, or translate a DNS name to
> whatever magic needed on the remote host based on the hostname (as opposed
> to the syntax used to address that host).  One has to deal with reality.  Alas.

Ah.  It may not be reasonable to *expect* that they will, currently, but
I'd argue that it is quite reasonable to *demand* it.

If a host or gateway exchanges mail with the Internet, then
	it must deal with mail addressing (both incoming and outgoing) like
	an Internet host (currently, by using DNS with MX records if
	necessary),
else
	mail will not get through it properly and people will be annoyed.

The translation that you refer to is part of what being a mail gateway is
all about.  If you want to use source routing, that means that you know
more about delivering mail than your mail gateway.  This shows that your
mail gateway is Really And Truly Broken, not that you need to use %s.

The more people stop supporting the %-hack, the more broken mail gateways
will become their owners problems, and not the rest of the world's.  This
will be a Good Thing, as far as I am concerned.

--
Amanda Walker <amanda@intercon.com>
--
"If your application does not run correctly, do not blame the
operating system." -- Geoffrey James, _The_Zen_of_Programming

-----------[000428][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 89 03:40:24 GMT
From:      smart@ditmela.oz (Robert Smart)
To:        comp.protocols.tcp-ip
Subject:   Re: (none)

In article <8910290319.AA16276@ucbvax.Berkeley.EDU> randall@uvaarpa.virginia.edu writes:
>
> The problem of someone somewhere else filling up a node's
> spool partition is to my mind serious, as is the ability of users
> on a given node to "send" files to themselves and thus get 
> disk storage space that isn't part of their account's quota
> (both are known problems at BITNET sites). 
>
This is all fairly fanciful. In the Australian system the mail message
that you get when someone has sent you files says "you have been sent
the following files, if you don't retrieve them quickly they'll be
automatically deleted". And the system manager can delete them sooner if he
likes: the user will realise what has happened if he tries to retrieve
the files and they are gone, and he knows who sent them so he can
request a resend. Not a good place for the user to store his own files
though.
>
> The Australian notion of a batch-oriented "getfile" application
> sounds interesting and could probably be implemented without
> too much trouble on the Internet for anonymous ftp if someone
> were so inclined...

Bit hard to see how you do it without having the batch sendfile mechanism
to go with it.

Somebody suggested a writeable area reachable by anonymous ftp as the
internet-style solution: you stick the files there and send the
recipient mail. This is a real security problem. Between when you put
the file there and when the recipient receives it, someone else could
overwrite it with another file. Since binary files, and programs in
particular, are a significant application of this sort of facility, this
seems very dangerous.

However it has the seeds of a good idea which wouldn't require any new
TCP/IP services. The first observation is that an ftp daemon doesn't
have to service a real file system -- it can, particularly for
anonymous ftp, appear to service a file system which is actually
imaginary: a virtual file system. I suggest that after anonymous ftp
to a machine there will be a subdirectory of the top level with name
"users". If you CWD to users then you will see a lot of subdirectories,
one for each user of the machine. If you CWD to one of these you will
find a directory which is empty (always empty!) which you can PUT files
into. If you PUT files there then it will actually go into a spool area,
and the recipient (the directory name) is sent mail requesting that
he retrieve the file. The mail will say who sent the file using the
password response to the login, plus giving the machine name derived
by backtranslation from the calling address. The mail message should
indicate that the sender's name is not securely determined. Note
that if another person sends you a file with the same name you would
have two files that you can retrieve: you can change the name of one
or put them in different directories, there is no problem caused by
this.

The client side of this process can easily be done by a program
instead of by an actual person. This gives the opportunity for both
sendfile and getfile actions to result in file transfers taking place
at times of low computer and network load: like the middle of the
night. For example you want to retrieve some files from an
anonymous ftp site. You ftp there, when you see the file you want,
instead of saying "GET file" you say "DELAY file" (or somesuch). The
ftp daemon then remembers your request and that night it will connect
to your machine's anonymous ftp, CWD into your directory and put
the file there for you to retrieve in the morning. This assumes that
you gave your username as password correctly.

Bob Smart <uunet!munnari!ditmela.oz!smart> or <smart%ditmela.oz.au@uunet.uu.net>


P.S. When should I give my address as <smart@ditmela.oz.au> instead of the
"%" hack. I have decided that a reasonable time to switch would be when
there is MX-mail software for all major TCP/IP implementations. Anybody
like to comment on how close we are to that situation?

-----------[000429][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 89 03:47:12 GMT
From:      fliu@uvicctr.UVic.ca.UUCP (Fang Liu)
To:        comp.protocols.tcp-ip
Subject:   Please forward me the "thick vs. thin" mails.

Sometime ago, there was an interesting discussion on "thick versus thin"
in this news group. One of my friends is also interested in this topic.
Unfortunately, I didn't save those mails. Could anyone kindly forward
the emails to me if he/she happens to keep them? Thanks.

-- 
Frances Liu 
UUCP:	...!{ubc-vision,uw-beaver}!uvicctr!fliu
APRAnet: fliu@uvicctr.nrl-css.arpa            CDNnet: fliu@uvunix.uvic.cdn
Internet: fliu%uvunix.uvic.ca@relay.ubc.ca
BITNET:	fliu@uvunix.bitnet

-----------[000430][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29 Oct 89 04:01:04 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

In article <1514@intercon.com> amanda@intercon.com (Amanda Walker) writes:
>... If you want to use source routing, that means that you know
>more about delivering mail than your mail gateway.  This shows that your
>mail gateway is Really And Truly Broken, not that you need to use %s.

No, it merely means that you know more than your gateway.  This is not
an unusual state of affairs outside the cozy little best-case Internet
world.  In the cold, ugly outside world, information about things like
topology changes and new hosts can take quite a while to propagate and
is often incomplete.  In the real world of inter-networking, the gateways
*do not* dependably have the most complete and current information.

>The more people stop supporting the %-hack, the more broken mail gateways
>will become their owners problems, and not the rest of the world's.  This
>will be a Good Thing, as far as I am concerned.

(Modulo the above considerations...)  It is a Good Thing if your objective
is to get the gateways fixed.  It very definitely is not if you are one
of the long-suffering users who has no power over the local gateway and
just wants to get his mail through!  In practice, people tend to have
this strange idea that a mail system should give mail delivery priority
over ideological purity.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000431][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29 Oct 89 14:10:19 PST
From:      Dave Crocker <dcrocker@decwrl.dec.com>
To:        cs.utexas.edu!mailrus!jarvis.csri.toronto.edu!neat.cs.toronto.edu!rayan@tut.cis.ohio-state.edu (Rayan Zachariassen)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Mail Source Routing (was Re: New Host-Requirement RFCs)
Rayan,

IP is single-hop??

Could have sworn that IP datagrams can and do go through an indeterminate
number of IP routers between me and thee.  It only APPEARS to be single-hop,
because of the use of global addressing.

The same as domain names and MX records try to accomplish.

Dave
-----------[000432][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 89 07:41:33 GMT
From:      wicinski@zamna.sgi.com
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

>rick@uunet.UU.NET (Rick Adams)  says:

Did he listen to what i said - NO.  I stated:
	getting registered is NOT easy.
	The forms are confusing 
	The instrustions are opaque
	Everything is geared for people who are directly connected.

}>No. The $35 is to pay for the hassle involved with reading and correcting the
}>forms (30% arrive with errors in them) and for RUNNING THE NAMESERVERS.
}>
}>Frankly the $35 one time fee doesn't cover the time and effort involved.

What a MINUTE - Don't you think something might be WRONG if 30% of them
come back with ERRORS? perhaps what i said could be true - ie, the
instructions were not written for the people who are filling them out.
When i see an error rate of 30 percent i have to say "WHOA,
something is wrong with the paradigm."  Is everyone committing the same
error - perhaps then something should be done to clarify the process.
And maybe if you do that, the error rate will drop and you can you time
more relevant tasks.

The problem boils down to this: When you are directly connected to the
Internet, registering is easy. The forms are simple, quick, and direct
(i know, I've filled them out this way). When you are not directly
connected to the Internet the forms are really a hassle. Most of it
becomes non relevant. The problem is the NIC hasn't quite caught on to
the fact that more and more domains are non-connecting. 

Another problem with forwarders and going around begging for one is how
it can/will turn into a subtle form of censorinship, turning domain
server masters into net nazis for the sake of making sure there systmes
are "pure" (and if you don't believe me, i can pull TWO cases out of my
mail archives where i received notes from systems nerds stating the content
of the flow of mail through their system was "inappropriate behavior for
their machines to handle", and in both cases it was caused by pathalias
totally botching my direct *source routes*... and peoplewonder why i
crypt all my mail...).

tim

-----------[000433][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 89 10:21:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet

Dan,

tell me more about sites which do not have reliable DNS access -
I'd like to pursue fixing the access problem. 

Vint

-----------[000434][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 89 10:29:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet

Rick,

No that's an interesting suggestion (getting DCA to stop supporting
hosts.txt table). I imagine a number of mailers would stop functioning
adequately (if one can say they function adequately even now, if
they depend on the hosts.txt table). Perhaps we should try to take
a poll to find out who would object to such a course of action?

Vint

-----------[000435][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 89 13:13:07 GMT
From:      amanda@intercon.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

In article <1989Oct29.040104.17081@utzoo.uucp>, henry@utzoo.uucp (Henry
Spencer) writes:
> >The more people stop supporting the %-hack, the more broken mail gateways
> >will become their owners problems, and not the rest of the world's.  This
> >will be a Good Thing, as far as I am concerned.
> 
> (Modulo the above considerations...)  It is a Good Thing if your objective
> is to get the gateways fixed.  It very definitely is not if you are one
> of the long-suffering users who has no power over the local gateway and
> just wants to get his mail through!  In practice, people tend to have
> this strange idea that a mail system should give mail delivery priority
> over ideological purity.

Well, so do I, but the two are not entirely separate.  My objective in this
case is indeed to get the gateways fixed, since that will improve mail
delivery for everyone involved.  As I said at the beginning of my article,
it may not be reasonable to expect all mail flowing on the Internet to involve
simple domain-style addresses; the %-hack is in my sendmail.cf, even though
I don't think it's ever been used here, for that very reason.  However, I
still maintain that it should not be considered an acceptable way to specify
a mail destination on any kind of permanent basis, as some people have been
arguing.

I send mail regularly to people via %-!-@ paths, because it's the only
way to get mail to them, but in every single case, I consider the mail
gateway to be broken.  I feel that I shouldn't have to source route my mail
any more than I should have to source route my telnet sessions...

--
Amanda Walker <amanda@intercon.com>
--
"If your application does not run correctly, do not blame the
operating system." -- Geoffrey James, _The_Zen_of_Programming

-----------[000436][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 89 16:59:26 GMT
From:      Dave_Katz@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   ISO specs online?

A draft version of 8473 was published as an RFC, but *DON'T* use that
version.  Significant technical changes took place before the IS version,
notably fixing the order of Record Route.  I've heard of people 
implementing CLNP from the DIS spec and shudder.
 
Both 8473 and 9542 are full IS now, which means if you want to get
them (legally) you'll have to pay for them.  ISO and ANSI sell them,
as do a number of commercial outfits who don't need me to advertise
them.
 
By the way, 8473 is not really CLNS, it's CLNP (the protocol that
provides CLNS).  CLNS is defined in 8348 (AD1 I think).

-----------[000437][next][prev][last][first]----------------------------------------------------
Date:      Sun, 29 Oct 89  22:40:23 EST
From:      "Roger Fajman" <RAF@CU.NIH.GOV>
To:        tcp-ip@SRI-NIC.ARPA.NIC.DDN.MIL
Subject:   Re:  New Host-Requirement RFCs
> No, it most emphatically is not.  There are numerous subdomains of
> compuserve.com.  E.g.,

OK, but it's still all controlled by one organization.

>    When you have a network of many non-Internet
>    hosts operated by independent organizations the problem becomes much
>    more difficult.
>
> I operate nameserver and mailer arrangements in varying levels of
> peculiarity for something like 20 organizations, not including
> anything at Ohio State proper.  That's the sort of thing I do in my
> spare time, for fun.  Anyone with a serious, job-dedicated need to do
> such things could manage an order of magnitude more than that with
> little change in complexity.

We are talking two orders of magnitute greater for BITNET and associated
networks.  :-)

>    One can either adopt domain naming on the non-Internet
>    network (as the UUCP network did, I believe) or build some sort of
>    translation between the two name spaces into the gateway.  Neither one
>    is necessarily very easy to do.
>
> If it isn't trivial to do, then the organization's internal mailer
> arrangement is in a serious state of disrepair, and deserves to be
> overhauled anyway.  CompuServe's internal arrangement appears to me to
> be internally consistent, so the mapping is truly trivial.  There was
> no internal overhaul in their case.  In fact, the original,
> proof-of-concept alpha test gateway didn't affect any software on the
> CompuServe side at all.  CompuServe literally didn't know what I'd
> built until I told them (by writing mail to relevant people through
> the gateway, of course :-).

You keep saying organization in the singular.  For BITNET and
associated networks it's a very large number of organizations.  Not all
of them have the strong commitment to electronic mail that you do or
CompuServe does.  And many do not have the resources to support
development work.  That's simply a fact of life.

>    In the latter case, the biggest
>    problem is getting all the organiztions registered and collecting the
>    information to do the translation.
>
> Each organization can be responsible for providing such a collection
> of registry information.  If the organization can't provide that sort
> of information, I really must question their ability to manage email
> of any kind.  Even FIDONet manages that (fidonet.org, IFNA
> [International FIDONet Association]).

FIDONet collects that information as part of operating FIDONet, not
just to operate a gateway.  And the NIC let FIDONet get away with
registering as a single domain.  If they would let BITNET do that, then
it would, indeed, be easy to handle.  But my understanding is that the
NIC insists that members of BITNET register individually.  Perhaps
you've never tried to get thousands of people to all do something at
the same time.

>    And when you are done, users still
>    have to be aware of two forms of addresses.
>
> CompuServe users are aware of only one generic style of addressing:
> ">GatewayName:WhateverThatGatewayUnderstands".  Thus, they address FAX
> stuff as >fax:phone#, and MCIMail users as >mci:someusername, and
> Internet sites as >internet:user@host.domain.  Very generic, in their
> view.  Similarly, I prefer only one addressing standard, domain style,
> and that's all I have to deal with for CompuServe.

The CompuServe user telling his friend on the Internet what his address
is still has to be aware that addressing conventions on the Internet
are different than on CompuServe.  So he can't tell his Internet friend
what his address is in the same way that he would tell another
CompuServe subscriber.  This is inescapable as long as multiple
networks with different addressing conventions exist.

What use of the DNS has achieved is hiding the name of the gateway
host(s) from the Internet user.  This is worthwhile, but one has to
balance the gain against the pain in each case.

>    If I'm on XYZ net (which
>    does not use domains) and I want to tell my friend on the Internet how
>    to mail to me, I will still have know the name of my host on the
>    Internet.
>
> That is exactly why the concept of the DNS works so well.  Tell me, on
> what network does CompuServe exist, that they get email of any kind?
> You don't know - you don't have to know, and that's the whole point of
> domains.  They remove the transport-centric forms of mail addressing
> and leave that to lower levels of software which care where the bytes
> get sent.  Users don't (shouldn't) care.  The idea of telling someone
> "I'm on XYZ net" is passe'.  (BTW, if you're guessing, no, CompuServe
> is not UUCP-based, either.  Should I have created "B-Protocol Net" and
> then tried to tell everyone, "CompuServe is addressable as
> user.name@compuserve.bprot," after the fashion currently required by
> non-DNS-cognizant BITNET sites?  Only inertia keeps .BITNET alive.)
>
> For that matter, on what network is, e.g., MorningStar.COM or HDL.ORG
> or UDayton.EDU, entities for which I also do nameservice and mailer
> support?  Same response: You don't know because you shouldn't care.
> The mail "just gets there."  If your network doesn't use domains, it
> should, and it is very clear to me that this is not because it is "the
> Internet standard," but rather because it works, from anywhere.  All
> you need is a way to query the DNS registries.  UUCP does this via
> comp.mail.maps info, the Internet via nameservers.

Don't get me wrong, I like the DNS.  And it looks to me like you went
about implementing the CompuServe gateway in quite a good way.  But
just because a particular method worked in your case does not mean it
will work as easily in every case.

The critical difference here between the CompuServe and FIDONet cases
and the BITNET case is that CompuServe and FIDONet are single domains.
Everything that's needed for delivery can be extracted from the DNS
address.  If BITNET were allowed to register as a single domain, then
there could be a simple two-way mapping between BITNET addresses
(user@node) and Internet addresses (say user@node.BIT.NET or
user@node.BITNET.ORG). Then it would be easy to build a gateway without
using the %-hack.

But the single-domain solution is not open to BITNET.  BITNET does have
its own way to query the domain registry.  It's called the DOMAIN NAMES
file and is updated monthly by BITNIC.  But support for it on the many
different types of systems that are part of BITNET is far from
universal.

-----------[000438][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 89 19:01:24 GMT
From:      rayan@cs.toronto.edu (Rayan Zachariassen)
To:        comp.protocols.tcp-ip
Subject:   Re: Mail Source Routing (was Re: New Host-Requirement RFCs)

Dave writes:

>Note that IP-level routing can, albeit slowly, discover alternate routes.

Note also that IP-level routing is qualitatively different from Mail routing,
in that the latter is single-hop Point-to-Point (on the Internet at least)
which doesn't leave a lot of room for the refinement of the routing decision
that takes place with IP-level routing.

Another key point wrt the Australian problem (which, as Amanda points out
is the same on all IP-islands about to get full connectivity -- we went
through it here) is that there is no nice way to prevent the world at
large from zipping right through the IP gateway and talk directly to
internal hosts if they know about them (e.g. due to coherent
nameservers).  If one has full control of all the mailers on the island
then arranging to send outbound mail through a gateway is not a
(technical) problem.  If one doesn't, the only solution that doesn't require
cooperation is to partition both worlds' mail access (e.g. hack routers at
the link to redirect smtp packets).  Neither of these choices are desirable.

While I'm at it, there's a third undesirable choice: have a high-priority
MX pointing at the gateway, and arrange that the mail server on it rejects
connections from hosts within the island, but accepts them from hosts on
the outside.  There are various ways of accomplishing this, but it means
a LOT of "are you there?" traffic to that gateway and the obvious MX
maintenance problem.  Due to the G-B links in the Australia scenario, this
is obviously not acceptable, but it would work if G-B was well-connected and
packets were cheap.

rayan

(this is still more tcp-ip'ish than maildropper'ish... umm, namedropper'ish :-)

-----------[000439][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 89 21:27:19 GMT
From:      mrose@CHEETAH.NYSER.NET (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC 1006

There are probably 3 or 4 independent implementations around.  Retix (the OSI
vendor) has one.  A well-known company with three-letters in its name
has one.  And a lot of other people use a reference implementation of
RFC1006 found in the ISODE.  You can drop a note to
bug-isode@nisc.nyser.net to get availability information.

/mtr

-----------[000440][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 89 21:34:44 GMT
From:      mrose@CHEETAH.NYSER.NET (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: private mib variables

Drop a note to jkrey@isi.edu.  And, probably you should have asked

	snmp@nisc.nyser.net

for the answer.  To subscribe, drop a note to

	snmp-request@nisc.nyser.net

/mtr

-----------[000441][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 89 22:09:58 GMT
From:      dcrocker@DECWRL.DEC.COM (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re: Mail Source Routing (was Re: New Host-Requirement RFCs)

Rayan,

IP is single-hop??

Could have sworn that IP datagrams can and do go through an indeterminate
number of IP routers between me and thee.  It only APPEARS to be single-hop,
because of the use of global addressing.

The same as domain names and MX records try to accomplish.

Dave

-----------[000442][next][prev][last][first]----------------------------------------------------
Date:      29 Oct 89 22:11:52 GMT
From:      logex@altger.UUCP (logex)
To:        comp.protocols.tcp-ip,comp.sys.hp,comp.sources.wanted
Subject:   Is there TCP/IP for HP-3000 ?

Hi all netlanders:

We are looking for an implementation of TCP/IP protocols
for the HP-3000 computer systems.

Does any of you has already done this or implemented the
internet protocols on the hp3000 systems ?

Is a public domain  version availiable ? where i can get it ?

Any further help ont his is appreciated, thanks in advance.!!.

Ed

logex@altger.uucp
logex@tchh.uucp
logex@chinet.uucp

-----------[000443][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 00:16:22 GMT
From:      bart@videovax.tv.tek.com (Bart Massey)
To:        comp.bugs.4bsd,comp.protocols.tcp-ip,comp.unix.questions
Subject:   Re: Stanford enetfilter

In article <13253@boulder.Colorado.EDU> cdash@boulder.Colorado.EDU (Charles Shub) writes:
> we attempted to add this, and had some problems because there were some 
> changes in 4.3 that weren't made to the filter code. As i recall, there was
> a problem with MCLGET having been redefined....

Actually, if you're concerned about the correctness of that section of the
code, you can always just def it out -- it's "just" an efficiency win, which
tries to use mbuf page clusters instead of plain old mbufs, to avoid
user-space copies.  Here's the code I'm using with 4.3 "Tahoe".  Note that
MCLGET used to always be called with "MCLGET(m,1)", and is now called with
just "MCLGET(m)" -- *yet the semantics of MCLGET() changed in a major way at
the same time the superfluous extra argument was eliminated*, confusing me,
at least, for some time.  IMHO this was a semantic botch -- the new MCLGET()
should have a different name.  Anyway, have fun -- of course this is kernel
code, and neither I nor Tektronix will be responsible if it causes the
erasure of all your disks and tapes... :-)

					Bart Massey
					
					Tektronix, Inc.
					TV Systems Engineering
					M.S. 58-639
					P.O. Box 500
					Beaverton, OR 97077
					(503) 627-5320

					..tektronix!videovax.tv.tek.com!bart


---around line 559 in /sys/net/enet.c---
...
	    if (m == NULL)
		panic( "enwmove: out of mbufs" );
#if 1
/*
 * this is how I'm doing it for 4.3 tahoe
 */
	    /* big enough to use a page */
	    if (iov->iov_len >= MCLBYTES && enPageClusters) {
	        enprintf(ENDBG_TEMP)("enwmove: using page cluster\n");
		MCLGET(m);
		len = m->m_len;
	    } else {
		len = MIN(MLEN, iov->iov_len);
		m->m_len = len;
	    }
	    error = uiomove(mtod(m, caddr_t), len, UIO_WRITE, uio);
#else
/*
 * this is how it was done before 4.3 tahoe
 */
	    if (iov->iov_len >= CLBYTES) {	/* big enough to use a page */
	    	register struct mbuf *p;
		MCLGET(p, 1);
		if (p == 0)
		    goto nopages;
		m->m_off = (int)p - (int)m;
		len = CLBYTES;
	    }
	    else {
nopages:
		len = MIN(MLEN, iov->iov_len);
	    }
	    error = uiomove(mtod(m, caddr_t), len, UIO_WRITE, uio);
	    m->m_len = len;
#endif
	    *mp = m;
	    mp = &(m->m_next);
...

-----------[000444][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 01:33:17 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

In article <1989Oct29.040104.17081@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:

   In article <1514@intercon.com> amanda@intercon.com (Amanda Walker) writes:
   >... If you want to use source routing, that means that you know
   >more about delivering mail than your mail gateway.  This shows that your
   >mail gateway is Really And Truly Broken, not that you need to use %s.

   No, it merely means that you know more than your gateway.  [ and Henry
   goes on to argue for % for pragmatic reasons.]

But Henry, some of the local E-mail users have very few clues on how
to force mail past Broken gateways.  They are all PhDs and are used to
solving their own problems.  If they can't solve the problem
themselves, they figure that it must be unsolvable[1].  Telling people
to use % doesn't work for me because I never get asked.  I suspect
that the same applies to most people who have to support PhDs.  These
PhDs would be better served by working software.

    [1] I am not willing to argue these two sentences.  They are true in
    *my* experience, and that is all I am asserting.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
Live up to the light thou hast, and more will be granted thee.
A recession now appears more than 2 years away -- John D. Mathon, 4 Oct 1989.

-----------[000445][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 04:15:33 GMT
From:      rick@uunet.UU.NET (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs


No. The majority of the errors come from people not following the
instructions.

Consider the simple instruction:

	Fill in questions 1, 2, 3 and leave 4, 5, 6 alone and
	return the entire form to me.

about 15% of the people "change the answers to 4,5 and 6 to
something wrong.

I dont know how much more simple you can make it than "leave #4 alone"

-----------[000446][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 10:24:00 EST
From:      "VAXB::DBURKE" <dburke%vaxb.decnet@nusc-npt.navy.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   NET BRIDGE over 9.6 voice grade line?
Date sent:  30-OCT-1989 10:26:53 

Hi,
	I'm looking for a way to tie two ethernets via a 9.6 leased line? 
Currently, we have async decnet running over a stat mux with 4 terminal ports 
on the same mux.  I'm open to fairly inexpensive solutions (please).

Dave

================================================================================
Dave Burke                                ||               ___________
Aquidneck Data Corporation                ||              //  ||     ||  
170 Enterprise Center                     ||             //   ||      ||  
Middletown, R.I. 02840                    ||            //    ||       ||  
dburke%vaxb.decnet@nusc-npt.navy.mil      ||           //-----||       ||  
(401) 847-7260                            ||          //      ||      ||
(This line left intentionally blank)      ||         //       ||_____||
================================================================================

-----------[000447][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 07:34:36 GMT
From:      josef@peun11.uucp (Moellers)
To:        comp.protocols.tcp-ip
Subject:   How find port number

Hi,

I have a question regarding port numbers:

I have a ("user level", i.e. one not using a well-known port)
server running on one machine and a client on another machine.

? How do I give a port number to the server avoiding clashes with other
  servers (not using well-known ports)?

? How do I relay the port number to the client(s) trying to contact
  my server?
Josef Moellers					| Nixdorf Computer AG
 USA:  uunet!philabs!linus!nixbur!mollers.pad	| Dept. DX-PC
!USA: mcvax!unido!nixpbe!mollers.pad		| Pontanusstrasse
Phone: (+49) 5251 146245			| D-4790 Paderborn

-----------[000448][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 11:43:44 GMT
From:      epsilon@wet.UUCP (Eric P. Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

In article <71081@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes:
>No. The majority of the errors come from people not following the
>instructions.

Maybe we should have the IRS handle domain registration.  :-)

					-=EPS=-

-----------[000449][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 12:09:15 GMT
From:      craig@bbn.com (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   High-Speed Networking Workshop

[For those of you for whom this is a duplicate, apologies.  I'm resending
because I've never received the copy I sent to tcp-ip@nic.ddn.mil]



	           CALL FOR PARTICIPATION

	    Internet Research Steering Group (IRSG)
	Workshop on Architectures for Very-High-Speed Networks

		      January 24-26, 1990
		    Cambridge, Massachusetts


The workshop is a working meeting, designed as a forum in which 
members of the academic, industrial and standards community can
meet to discuss research issues in the design and implementation of
environments to support very high-speed (e.g. gigabit) data communication.
Suggestions on how these ideas may related to the evolution of the
Internet are also of interest.  This is a one-time workshop sponsored
by the Internet Research Steering Group and is being organized by
Dave Clark and Craig Partridge.

The goal of the meeting is foster discussion and the exchange of new
ideas.  Topics to be discussed at the workshop include: Lightwave
Technology, High-Speed Data Networking and the Phone System, Flow
and Congestion Control at Very-High Speeds, Applications and
Application Support Paradigms, and Issues in Attaching Hosts to
Very-High Speed Networks.  Sessions on additional topics will be
set up based on the ideas and interests of the attendees.

The workshop will last two and a half days, and consist of a series
of 90 minute sessions.  Each session will begin with a handful of
short (ten minute) presentations followed by discussion.  On the
first day, invited speakers will introduce each session with
a slightly longer talk (about 30 minutes long) designed to give
a somewhat broader perspective.

There will be no paper presentations.  (We do expect to produce
an informal workshop report).  Authors interested in publishing
papers are encouraged to consider the SIGCOMM '90 Symposium, which
is actively soliciting submissions on high speed networking. 
(Contact the SIGCOMM '90 Program Chair, Phil Karn,
karn@thumper.bellcore.com for more information).

Attendance at the workshop is strictly limited to 50 people.  People
interested in attending the workshop should apply to the program committee.
Applications should be about two paragraphs in length and should outline
the applicant's areas of interest in the field and relevant work
on related topics.  Applications will be judged, in large part, on
new or interesting ideas that the applicant can bring to the workshop so
please be sure to highlight innovative work.  Note that due to the
large number of expected applications, we encourage team projects or
close collaborators to restrict themselves to one attendee, and
suggest that organizations limit themselves to two applicants, with
differing areas of interest.  The deadline for applications is Thursday,
November 16th, 1989.  Notification of the decisions on applications
will be sent out no later than December 1st, 1989.

Local Arrangements:  The workshop will be held in the BBN Conference
Center in Cambridge, Mass.  We expect to arrange discount airfares and
hotel accomodations.  The workshop fee, if any, will be nominal.

E-mail or mail applications to:

    Craig Partridge (craig@bbn.com)
    c/o BBN Systems and Technologies Corporation
    10 Moulton St, MS-6/5B
    Cambridge MA 02138

    (617) 873-2459

The program committee is:

    Dave Clark (MIT), Gary Delp (IBM), Keith Lantz (Olivetti),
    Craig Partridge (BBN), Dave Sincoskie (Bellcore), Don Tolmie (LANL)

-----------[000450][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 13:09:21 GMT
From:      tuula@gvlf6-j.gvl.unisys.com (Tuula Kunzman)
To:        comp.protocols.tcp-ip
Subject:   Re: private mib variables

I want to Thank everyone who responded to my request for help....
Talk about a great response! The net came through once more !!

	    Thanks to all...


	    Tuula

	    tuula@gvlf6.gvl.unisys.com

-----------[000451][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Oct 89 20:50 MST
From:      Paul Charette <EE5990038@rvax.ccit.arizona.edu>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Greetings!

Hello all ...

	I'm a graduate student in electrical engineering at the University of
Arizona, and my thesis research includes some internetwork gateway design 
using TCP/IP on 386-based PC compatible machines under MS-DOS.  What I'm 
looking for now is some source code for TCP and IP (and FTP, and TELNET, etc.)
which will run on these machines, if it's availible.

	Pardon my ignorence, but my exposure to these protocols thusfar has
been largely academic.  Are there public domain software implemetations of
these protocols?  Are they in an FTP-able location?

	Any help would be greatly appreciated.  By the way, I have requested
that I be added to this list, but I have not, as yet, been added - so please 
send replies directly to me.  Thanks in advance!!

Paul Charette
Department of Computer and Electrical Engineering
University of Arizona

"Well, sure it's hot ... but it's a _dry_ heat"

-----------[000452][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 14:31:39 GMT
From:      brennan@merk.UUCP (Rich Brennan)
To:        comp.protocols.tcp-ip
Subject:   What's a gateway?


About five pounds.



Sorry,

Rich.
-- 
...!{uunet,linus!alliant}!merk!root			Rich Brennan

-----------[000453][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 14:51:00 GMT
From:      Gavin@BALROG.DREA.DND.CA (Gavin L. Hemphill)
To:        comp.protocols.tcp-ip
Subject:   WKS Records

WKS records ARE used by some systems.  For example the symbolics uses
them to decide between the different types of interactive connections
(telnet, supdup, etc.) and different types of file connections.  For
example if the Symbolics can't find SMTP in the WKS records it will
refuse to even attemt to deliver mail to the target system.

The Symbolics also uses the HINFO records to figure out if the remote
file system is one of the ones supported by the generic file system for
FTP operations.

I suggest you really want to put the WKS and HINFO records into your
domain database.

	G++
-------

-----------[000454][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 15:17:00 GMT
From:      sean@dranet.dra.com (Sean Donelan)
To:        comp.protocols.tcp-ip
Subject:   MXing the world (was RE: New Host-Requirement RFCs)

In article <71081@uunet.UU.NET>, rick@uunet.UU.NET (Rick Adams) writes:
> 
> I dont know how much more simple you can make it than "leave #4 alone"

Simple don't put #4 on the form.

I think there are several problems with trying to MX-the-world to eliminate
the %-hack and other forms of explicit routing.

1. It is impractical, if not impossible.  One of the readers of this list
has most likely written the definitive routing paper to date (or at least
included it the bibliography of the paper they did write), why routers can't
have universal knowledge of the network.  Trying to minimize when one has
to resort to explicit routing is fine, prohibiting explicit routing is
something else.  Security and other policies will most likely require the
limitation of explicit routing at the cost of lower connectivity.  But that
is the purpose of those security and other policies (to lower connectivity).

2. Politically, and adminstratively the Internet is difficult to deal with
by non-Internet (though possibly gatewayed) networks.  And "acceptable use"
policies make it necessary to route through an "acceptable" route.  The choice
of these two (or more) routes must be determined by the sender based on the
"intent" of the communication.

Currently my company has a half-dozen network addresses, assigned by various
network bodies.  Most are chartered to provide essentially "universal" service,
but the Internet is not.  If, as I believe, the Internet DNS exists to make
life easier for Internet users then registration of non-Internet networks is
merely a matter of convience for the Internet community.  If registration
is a prerequisite for communication between Internet and non-Internet networks
then it becomes a enforcement mechanism. 

3. The "what do you care?" point.  The %-hack is in the local part anyway.
It should only be the concern of the sender and the gateway.  If you're not
a gateway don't worry, if you are a gateway its your job to worry.

-- 
Sean Donelan, Data Research Associates, 1276 N. Warson, St. Louis, MO 63132
Domain: sean@dranet.dra.com, sean%dranet@wupost.wustl.edu
UUCP: ...!wugate!wupost!dranet!sean, Voice: (Work) +1 314-432-1100

   "I don't speak for anyone else, and they don't speak for me."

-----------[000455][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 15:24:00 GMT
From:      dburke%vaxb.decnet@NUSC-NPT.NAVY.MIL ("VAXB::DBURKE")
To:        comp.protocols.tcp-ip
Subject:   NET BRIDGE over 9.6 voice grade line?

Date sent:  30-OCT-1989 10:26:53 

Hi,
	I'm looking for a way to tie two ethernets via a 9.6 leased line? 
Currently, we have async decnet running over a stat mux with 4 terminal ports 
on the same mux.  I'm open to fairly inexpensive solutions (please).

Dave

================================================================================
Dave Burke                                ||               ___________
Aquidneck Data Corporation                ||              //  ||     ||  
170 Enterprise Center                     ||             //   ||      ||  
Middletown, R.I. 02840                    ||            //    ||       ||  
dburke%vaxb.decnet@nusc-npt.navy.mil      ||           //-----||       ||  
(401) 847-7260                            ||          //      ||      ||
(This line left intentionally blank)      ||         //       ||_____||
================================================================================

-----------[000456][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 16:57:06 GMT
From:      merlyn@iwarp.intel.com (Randal Schwartz)
To:        comp.protocols.tcp-ip
Subject:   Re: (none)

In article <7752@ditmela.oz>, smart@ditmela (Robert Smart) writes:
|				    I suggest that after anonymous ftp
| to a machine there will be a subdirectory of the top level with name
| "users". If you CWD to users then you will see a lot of subdirectories,
| one for each user of the machine.

Gaccckkk.  Blindingly direct and useful security hole.  If I can get a
list of usernames on your system, I can attack you sooooooooooo much
easier.

However, modifying the proposal such that a "DIR" fails but "CWD"
succeeds is a little better.  Then I at least have to work a bit at
getting the user names. :-)

Just another security weenie,
-- 
/== Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ====\
| on contract to Intel's iWarp project, Hillsboro, Oregon, USA, Sol III  |
| merlyn@iwarp.intel.com ...!uunet!iwarp.intel.com!merlyn	         |
\== Cute Quote: "Welcome to Oregon... Home of the California Raisins!" ==/

-----------[000457][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 17:10:44 GMT
From:      braden@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs


                                      I'm sure the Host Requirements folks
	understood the problem, but whichever way they could go is imperfect so
	looks like they stayed with Architectural Purity.

		Cliff Frost

Yes.  

  Bob Braden

-----------[000458][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 17:22:00 GMT
From:      Chris.Rusbridge@levels.sait.edu.au (Chris Rusbridge)
To:        comp.protocols.tcp-ip
Subject:   Re:  BITNET -- Internet capabilities (better file transfers)

In article <1230@uvaarpa.virginia.edu>, randall@uvaarpa.virginia.edu (Randall Atkinson) writes:
>>I wish the Internet had BITNET-style sender-initiated file transfer
>>that did not require the sender to know the receiver's password.  It's
>>very convenient.  Sending files as email is not very user friendly.
> 
> The ability of some arbitrary user elsewhere on a network I'm connected
> to to put files in my account without (at least) password protection 
> is a security hole.  I'm glad my systems aren't directly connected to BITNET.
> 
> ftp and sending files as mail do work, though I concede a better user
> interface could be devised if someone had the time (I don't).

The ACSnet sendfile system has a better solution. The file is
addressed with standard email syntax, but arrives in a spool area on
the target machine. The system then automatically sends an email
message to the target user, who has 7 days (or some installation
defined period) to pick up the file before it is trashed. You can
arrange for an acknowledgment of receipt. 

_No_ password traverses the network. The only vulnerability is to fill 
the spool area, which can be done in many other ways.

This system requires the ACSnet software, but might be used as a 
model. Contact piers@basser.cs.su.oz.au for details if anyone is 
interested.

Chris Rusbridge

Academic Computing Service Manager, SA Institute of Technology
ACSnet:		Chris.Rusbridge@levels.sait.oz [.au]
InfoPSI:	Chris.Rusbridge@sait.edu.au	(DTE 505282622004)
Phone: 		+61 8 343 3098  Fax: +61 8 349 6939  
Post: 		The Levels, SA 5095 Australia

-----------[000459][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Oct 89 18:02:16 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: rsh/rexec/rlogin protocol specs

In article <125@tenset.UUCP> colin@tenset.UUCP (Colin Manning) writes:
>I'm looking for the specifications of the rsh/rlogin/rexec protocols.

There are none; you have to read the source code.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000460][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Oct 89 18:10:39 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

In article <NELSON.89Oct29203312@image.clarkson.edu> nelson@clutx.clarkson.edu writes:
>   >... If you want to use source routing, that means that you know
>   >more about delivering mail than your mail gateway.  This shows that your
>   >mail gateway is Really And Truly Broken...
>
>   No, it merely means that you know more than your gateway...
>
>But Henry, some of the local E-mail users have very few clues on how
>to force mail past Broken gateways.  They are all PhDs...
>...would be better served by working software.

The answer to how an ignorant PhD (a species I am familiar with) gets mail
to an unregistered host using strictly-conforming mail software without
asking for help is "he can't".  However, a sophisticated user, or someone
who has the sense to ask advice of a sophisticated user, can... if the
relevant gateway has the decency to admit its limitations and support %.

Everybody would be better served by working software; there is no doubt
about that.  However, the notion that "working software" will automatically
have complete and correct knowledge of every destination to which one might
want to send mail is simply wrong.  For the foreseeable future, there
will always be situations -- typically involving non-Internet sites --
in which the user knows more than the mailer does, and should be able
to exploit this information.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000461][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 18:37:04 GMT
From:      bob@archer.MorningStar.COM (Bob Sutterfield)
To:        comp.protocols.tcp-ip
Subject:   Pilot Project: Hosts Table To Be Available Over Internet


   Date: 29 Oct 1989 05:29-EST
   From: CERF@A.ISI.EDU

   Perhaps we should try to take a poll to find out who would object
   to such a course of action [getting DCA to stop supporting
   hosts.txt table]?

Your list of whiners^H^H^H^H^H^H^Hobjectors could probably start with
the collection of host-table subscribers that Mr Bernstein and his
anonymous work group have collected.

I find it curious (perhaps even somehow perversely commendable) that
this project has progressed in the face of such opposition that
members must remain anonymous in order to keep their professional
status (jobs?).  On the one hand, there's something noble about a
persecuted minority persevering in hardship, but then sometimes there
are good reasons for the way things are designed...

-----------[000462][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 19:51:05 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   How do you string a thinnet?

Date: 27 Oct 89 12:56:14 GMT
From: eplrx7!mcneill@louie.udel.edu  (Keith McNeill)
Subject: Re: How do you string a thinnet?
To: tcp-ip@nic.ddn.mil

Bernie Hoffstadt <cutter@cutsys.UUCP> asked:
Now the $64k question: Is there a good reference for this kind of info.
----------------

I replied:
Gee, you found one I don't have a good answer to.  [...]
----------------

Keith McNeill <eplrx7!mcneill@louie.udel.edu> replied:
I've found that "Unix System Administation Handbook" by Evi Nemeth
(ISBN #0-13-933441-6) a really good reference.  It's mostly based on
BSD unix.  There is a large chapter on networking.
----------------

My response:
But the question was on Ethernet CABLING!  Does this UNIX book really
talk enough about cabling to answer all these questions?  I would be
really surprised to find a book on "System Administration" that talked
about cable impedances, topology, and other cabling techniques.  A
good technical reference on the general area of networks is John E.
McNamara's "Local Area Networks" book (ISBN #0-932376-79-7), and
although it probably covers cabling and other low-level details more
than the book you mention, it doesn't cover enough details for what
Bernie asked that's why I didn't mention it there.

	    __
  /|  /|  /|  \		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. :-)

-----------[000463][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 20:04:20 GMT
From:      John_-_Nagle@cup.portal.com
To:        comp.protocols.tcp-ip
Subject:   Re: 4.X implementations of TCP, initial sequence numbers, and w


      This was a problem in the initial release of 4.3BSD's TCP, which
wouldn't interoperate with systems using sequence numbers with the
high bit set.  The problem was caused by code which subtracted
one sequence number from another, and then compared the result to 0.
But without casts, the difference of two unsigned numbers in C is
always nonnegative, so a <0 test was always false.
 
      Perhaps the implementation giving trouble is based on original
4.3 without fixes.  This seems unlikely (the bug was fixed in 1985)
but maybe someone has really old code.  

					John Nagle  


			

-----------[000464][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 20:13:12 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Automatic notification about new RFC's


Hi.

Ask to be added to the RFC notice distribution list by sending a note to

			RFC-REQUEST@NIC.DDN.MIL

--jon.

----- Begin Included Message -----
Date: 25 Oct 89 15:34:46 GMT
From: eru!luth!sunic!mcsun!unido!laura!bilbo!mk@bloom-beacon.mit.edu  (Michael Kuschke)
Subject: Automatic notification about new RFC's
To: tcp-ip@NIC.DDN.MIL

Hello,

is there a way to get an automatic notification when there's a new RFC
oder IDEA avaible ???

	Thanks,

	  -Michael

  Michael Kuschke				  uucp: mk@unido.uucp
  Computer Science Department - IRB		  BITNET: MK@DDOINF6.BITNET
  University of Dortmund			  FAX:    +49 231 751532
  D-4600 Dortmund 50,PO-Box 500500, W.-Germany	  voice:  +49 231 755 2422
---- End Included Message -----

-----------[000465][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 20:41:28 GMT
From:      rick@UUNET.UU.NET (Rick Adams)
To:        comp.protocols.tcp-ip
Subject:   Re: Pilot Project: Hosts Table To Be Available Over Internet

No, You're totally missing the point.

Site that still run software that require the hosts table are
running broken mailers.


Any site that does not use the domain system and MX records to
deliver mail is broken. This includes virtually all of MILNET.

I'm tired of telling people why people on MILNET cant reply
to their mail.

Your host table let them continue the farce that there is nothign wrong
with their mailer.

-----------[000466][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 22:26:46 GMT
From:      smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
To:        comp.protocols.tcp-ip
Subject:   Re: (none)

The FTP protocol does not need to be enhanced.  However, Berkeley's
implementation needs to be fixed up a bit.

The basic functionality is provided by the STOU command.  That means
``store unique''; the FTP server picks a name, and tells you about it.
There is, in principle, no reason why an operating system can't have
an ``append-only'' directory; using it, FTP would not let you remove
a file, and the use of STOU would guarantee uniqueness.  You avoid
people overwriting files in it by not letting them list the directory;
that way, they'll have no knowledge of the filenames present.
Remember that these can be arbitrarily weird; there's no reason
why the ftp server can't run random dictionary words through makekey
or some such.

Sending to a user, then, could be as simple as:

	ftp dest-host
	cd incoming-directory
	stou >xxx
	quit
	mail user@dest-host <xxx

Note, incidentally, that Berkeley has implemented STOU incorrectly, at
least as of the versions of ftpd I have here (a post-worm version, a
new one from, I think, Rick Adams, plus SunOS 4.0.3) require that the
STOU command have an operand.  This contradicts RFC 959.  There is a
second error, more understandable; the host requirements RFC corrects
an error in 959 about how the unique file name should be announced.
The RFC says on the 250 message; that is corrected to either the
126 message or the 150 message.  (Of course, Berkeley is using 226,
but I suppose we can forgive that.)

Still, despite these deficiencies, you can approximate the proper
server on UNIX systems.  Create a mode 733 directory under ~ftp.  Folks
who have broken FTP commands (i.e., ones that generate operands on the
STOU command) can issue the local subcommand ``sunique'' to condition
their clients to send STOU instead of STOR, and send files to their
hearts' content.  Clever administrators will fix the reply message for
the 150 message to have a conforming file name, and will accept valid
STOU commands as well as broken ones.  The latter will force ftpd to
generate real unique file names, too.

-----------[000467][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 23:24:09 GMT
From:      dricejb@drilex.UUCP (Craig Jackson drilex1)
To:        comp.protocols.tcp-ip
Subject:   Sender-initiated file transfer and FTP

Several messages recently on this list discussed the features available
on BITNET which are not commonly available from the TCP/IP protocol
suite.  I have long wondered why the TCP/IP community has not developed
some of these things.  There's no one message which I'd like to answer,
but I'd like to point out a few things which I haven't heard discussed.

Sender-initiated file transfer:

With the RSCS protocols used on BITNET, the only form of file transfer
is sender-initiated.  A file is sent to the receiving system and held
in a special area.  The recipient is notified, and he/she can choose
to accept or reject it.  This mechanism has been described reasonably
well by other posters.

The TCP/IP suite does not have any commonly-used protocol which maps
exactly to this RSCS capability.  However, as it has been pointed out,
both SMTP and FTP can be employed to offer similar service.

The points that I have not heard are:

1. RSCS, at least under VM/CMS, offers a very easy-to-use interface
to this service.  One simply says:

        SEND MYPROG C TO LEXVM1

Forgetting the other limitations of CMS for the moment, it is convenient
that this is the only command needed to send the file.

Using FTP, one would first send the file to the anonymous FTP area of
the receiving system, and then send the recipient mail informing
him/her of it.  However, I do not know of a widely available interface
to these functions which is as easy to use as the SENDFILE command of CMS.

2.  It has been pointed out that this service can cause malicious-denial-
of-service security problems, by filling up the spool area on the
receiving system.  RSCS handles this by first queuing the file on the
sending system, and then sending it to the receiving system when the
receiving system accepts.  Both the sending spool area and the
receiving spool area are specially-known to the system, and commands
are available for monitoring the space available, dumping it to tape,
etc.

The FTP alternative does not queue the file on the sending system, but
presumably the anonymous FTP area on the receiving system could be
organized on a separate file system (in the case of Unix) to limit
the damage that could be caused this way.

3.  The RSCS system, in conjunction with VM, offers a measure of security
to the transmission process.  Once delivered to the recipient, only
the recipient can retrieve the file from the spool area.  The FTP
alternative does not offer this level of security, to the best
of my knowledge.

4.  All of these features of RSCS map much better on to SMTP than FTP.
SMTP does offer sender-initiated transfers of information, which are
commonly queued at both ends of the transfer, allowing the recipient
to pick up the information at his/her leisure.  I believe that the
possibility of using mail for this service has lessened the need
to create other solutions for TCP/IP users.  However, using mail,
particularly SMTP, still has unnecessary limititations for this use:

   a. SMTP is defined as only passing 7-bit data.  This means that
   files to be transferred must be encoded using uuencode, btoa, etc,
   thereby increasing the amount of bytes sent to transmit a given
   amount of data.

   b. Mail systems that interface to SMTP typically are designed to
   handle short messages well.  There typically is a limit on the
   overall size of messages.  This means that messages are commonly
   broken up, only to be reassembled manually at the receiving end.

   c. RFC-822 specifies that mail shall have a number of headers.
   To my knowledge, there is no particular standard in use which
   specifies how these headers will be used to encode the information
   desired in a file-transfer situation.  Also, although it is not too
   difficult to write code under Unix to rip off the headers and reassemble
   multi-part files, such code is not commonly distributed with systems.

   d. If and when the TCP/IP community begins to use Type-Of-Service (TOS)
   information, it would be appropriate to give mail a reasonably
   high TOS, yet it would be more appropriate to give file transfer a
   lower TOS.  If one is using mail for both purposes, it might become
   necessary to complicate the mail interface to distinguish the uses.

X.400 would solve problem (a), allowing binary portions of messages,
and may solve (c).  However, (b) and (d) would remain problems.

5. The RSCS/Bitnet environment is not the only environment which
has found it useful to develop this service.  The 'uuto' and 'uupick'
commands, available in System III and System V, implement a similar
facility over uucp.

This has become rather long, because I wanted to anticipate many
arguments.  I will sign off now, and cover the other RSCS/Bitnet
feature (interactive message transmission) in a later message.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}

-----------[000468][next][prev][last][first]----------------------------------------------------
Date:      Mon, 30 Oct 89 23:24:09 GMT
From:      tcp-ip-relay%NIC.DDN.MIL@CORNELLC.cit.cornell.edu
To:        Brian Holmes <BHOLMES@WAYNEST1.BITNET>
Subject:   Sender-initiated file transfer and FTP
The IBM implemetation is supplied with a modified SENDFILE EXEC
which allows you to SF MYPROG C TO BRIAN AT CMS.CC.WAYNE.EDU
This will currently only transfer TEXT files over TCP/IP.
Basicallly it just adds a RFC 822 mail header to the file.

                        Brian Holmes
                        CSC Operating Systems & Communications

SNAIL    : Wayne State University, 5925 Woodward, Detroit MI 48202 U.S.A.
BITNET   : BHOLMES@WAYNEST1
INTERNET : Brian_Holmes@UM.CC.UMICH.EDU
UUCP     : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES
----------------------------Original message----------------------------
>1. RSCS, at least under VM/CMS, offers a very easy-to-use interface
>to this service.  One simply says:
>
>        SEND MYPROG C TO LEXVM1
>
>Forgetting the other limitations of CMS for the moment, it is convenient
>that this is the only command needed to send the file.
>
>Using FTP, one would first send the file to the anonymous FTP area of
>the receiving system, and then send the recipient mail informing
>him/her of it.  However, I do not know of a widely available interface
>to these functions which is as easy to use as the SENDFILE command of CMS.
>--
>Craig Jackson
>dricejb@drilex.dri.mgh.com
>{bbn,ll-xn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
-----------[000469][next][prev][last][first]----------------------------------------------------
Date:      30 Oct 89 23:45:33 GMT
From:      amanda@mermaid.intercon.com (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re: MXing the world (was RE: New Host-Requirement RFCs)

In article <299@dranet.dra.com>, sean@dranet.dra.com (Sean Donelan) writes:
> 3. The "what do you care?" point.  The %-hack is in the local part anyway.
> It should only be the concern of the sender and the gateway.  If you're not
> a gateway don't worry, if you are a gateway its your job to worry.

This is fine when there is only one gateway involved.  What happens when
I need to go through a number of gateways, each of which has its own magic
local part?  One of the big problems with mixing addresses and routes (which
is what using % does) is that it can give you some real ambiguity headaches.

Consider the "address" random!mumble%foo!bar%zot@foobar.domain from a UUCP
site whose mailer understands both RFC 822 addresses and UUCP routes (as many
do these days).  How do you send mail to this person?  Answer: you pray,
and your mail probably bounces somewhere, not because any individual pair
of hosts don't talk to each other, but because you can't tell them where
you want the mail to go unambiguously.  This is something that the DNS and
MX records are very good at addressing, as Karl has pointed out with his
CompuServe example.

Anyone who thinks my example is contrivedly complex is either new to inter-
network mail or doesn't try to send mail to certain organizations that shall
remain nameless for the moment (which use DECnet and VMS mail :-)).

Also, any time a gateway cobbles up a source route in the local part, you
run the (very real) risk of ending up with one-way mail.  A good friend of
mine is currently on a site that can send me mail, and to which I can send
mail.  However, in both directions the return address gets mangled beyond
usability, thanks to helpful bangs and %s in the local part.  As it happens,
using simple domain addresses works great (thanks to the DNS and pathalias),
but the gateway doesn't know this :-(...

I've also gotten plenty of mail replying to articles I've posted in which
the return addresses are undecipherable, thanks to gateways using source
routing.

--
Amanda Walker <amanda@intercon.com>

-----------[000470][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 00:18:42 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   TN3270 for Ultrix

Good Afternoon Folks!
		I remember from time to time seeing(and sending for that matter)requests for info on porting TN3270 to SYS V or whatever, but I can't recall
anyone ever talking about doing an Ultrix port. If anyone has any insight on
this could you drop me a line? I long for the day when all TCP/IP includes
a TN3270 package, even the elusive TERMINAL SERVER!!!! (:*>
		Thanks in advance for any thoughts, leads or opinions on this.
		Chris VandenBerg
		ACC (chris@salt.acc.com) 

-----------[000471][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 1989 06:24 EST
From:      Dave Bachmann <dave@citi.umich.edu>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Ethernet cabling book
A book just came out called "Keeping the Link" that covers all sorts of issues
on Ethernet.  Very detailed.

Dave
-----------[000472][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 01:24:43 GMT
From:      parker@zaphod.mpr.ca (Ross Parker)
To:        comp.protocols.tcp-ip
Subject:   Changing subnet masks

Up here in BC we have a network known as BCNet which connects our three
universities and a number of research institutions. The current network
is set up with a backbone on network 128.189, and satellite networks
using network number 134.87. The satellite networks have all been assigned
chunks of the third byte to be used at their whim... i.e. here at MPR, we
are free to use any number between 134.87.131.xxx and 134.87.140.xxx (where
'xxx' is of course between 1 and 254). The subnet mask is currently set to
0xffffff00. As some of our satellite networks have few hosts, we want to
change the subnet masks to, say, 0xffffff70, leaving 5 bits, or 32 possible
host addresses per subnet.

The 'satellite' networks are hung off of the main network using either
Proteon P-4200 routers, or Sun 3s acting as routers. These routing
boxes all know which satellite networks contain which chunks of the
'134.87' address space.

The $64,000 question is: do we need to change all subnet masks at the
same time (which would be a *real* drag...), or can multiple subnet
masks exist on the same network at the same time?

Any comments, help, suggestions, money :-) would be greatly appreciated.



Ross Parker      				| Why do they put me down?
Microtel Pacific Research Ltd.			| Make out that I'm a clown?
Burnaby, B.C.,	     				| I drink scotch whisky all
Canada, eh?	     uunet!ubc-cs!mpre!parker	|	 day long
(604)293-5495	     parker@mpre.mpr.ca		| Yeah I'm gonna save my money
Disclaimer:					| (gonna put it all away...)
My fingers are doing all the work...		| 'Cause I'm a Scotsman

-----------[000473][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 03:29:59 GMT
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Changing subnet masks

In article <1855@eric.mpr.ca> parker@zaphod.mpr.ca (Ross Parker) writes:
>The subnet mask is currently set to
>0xffffff00. As some of our satellite networks have few hosts, we want to
>change the subnet masks to, say, 0xffffff70, leaving 5 bits, or 32 possible
>host addresses per subnet.
>
>The $64,000 question is: do we need to change all subnet masks at the
>same time (which would be a *real* drag...), or can multiple subnet
>masks exist on the same network at the same time?

Welllll ... I can see ways of avoiding a massive cutover, although you
then face the possibility that some islands of resistance will remain,
causing untold grief for years to come.

Also, using 0xFFFFFF70 as a subnet mask is bound to cause trouble.
You probably meant 0xFFFFFFE0.  Keep those bit-fields contiguous if at
all possible!

Anyway, the key is to start by arranging your addresses so that the
individual (non-router) hosts don't really care what the masks should
be.  That is, make sure that all the host addresses on a subnet use only
the low-order 5 bits for host number.  Then, at any later time you can tell
the hosts to use the 0xFFFFFFE0 mask and they will still route their packets
in the right direction.  (But be careful about premature changes, since
the broadcast addressing could get mixed up!)

The other point is to avoid assigning any subnet numbers with non-zero
bits in the field under the mask 0x000000E0, until you are done changing
the masks everywhere in your network.  Finally, you should at least
change all the routers to use the new subnet mask as simultaneously
as you can manage. That means that there won't be any ambiguity about how
to route between subnets.  After that, you can reeducate the individual
hosts more or less at your convenience.

Someone will probably tell me if I've said something wrong.

-Jeff

P.S. If you want to use different subnet masks on different parts of
your network for more than just a transition period, then you've
entered the twilight zone of variable-width subnetting ...

-----------[000474][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 03:50:00 GMT
From:      EE5990038@RVAX.CCIT.ARIZONA.EDU (Paul Charette)
To:        comp.protocols.tcp-ip
Subject:   Greetings!


Hello all ...

	I'm a graduate student in electrical engineering at the University of
Arizona, and my thesis research includes some internetwork gateway design 
using TCP/IP on 386-based PC compatible machines under MS-DOS.  What I'm 
looking for now is some source code for TCP and IP (and FTP, and TELNET, etc.)
which will run on these machines, if it's availible.

	Pardon my ignorence, but my exposure to these protocols thusfar has
been largely academic.  Are there public domain software implemetations of
these protocols?  Are they in an FTP-able location?

	Any help would be greatly appreciated.  By the way, I have requested
that I be added to this list, but I have not, as yet, been added - so please 
send replies directly to me.  Thanks in advance!!

Paul Charette
Department of Computer and Electrical Engineering
University of Arizona

"Well, sure it's hot ... but it's a _dry_ heat"

-----------[000475][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 04:25:20 GMT
From:      metro@asi.UUCP (Metro T. Sauper)
To:        comp.protocols.tcp-ip,comp.sys.hp,comp.sources.wanted
Subject:   Re: Is there TCP/IP for HP-3000 ?

From article <1971@altger.UUCP>, by logex@altger.UUCP (logex):
> Hi all netlanders:
> 
> We are looking for an implementation of TCP/IP protocols
> for the HP-3000 computer systems.
> 

Wollongong has an implementation.  HP uses TCP/IP for its NS/3000 
networking.  You have to have NS/3000 installed on your machine
to use the Wollongong add-on.  What Wollongong adds are the user
services TELNET, FTP, SMTP.

It goes for about $8000. on an HP3000/58.

We use it.  It works.  I am not overly impressed.  What can I say.

Metro.
-- 
Metro T. Sauper, Jr.                              Assessment Systems, Inc.
Director, Remote Systems Development              718 Arch Street
(215) 592-8900             ..!bpa!asi!metro       Philadelphia, PA 19106

-----------[000476][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Oct 89 15:50:49 EST
From:      Brad Clements <bkc@omnigate.clarkson.edu>
To:        tcp-ip@nic.ddn.mil
Cc:        pcip@udel.edu
Subject:   Wanted: Beta testers for Xircom Pocket Ethernet Adapter Packet Driver
I have developed a packet driver for the Xircom Pocket Ethernet adaptor.
If you have one of these units, and would be willing to test the beta version
of this driver, please write to me.


| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clutx.bitnet 
| Network Engineer       Clarkson University              (315)268-2292
-----------[000477][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 11:24:00 GMT
From:      dave@CITI.UMICH.EDU (Dave Bachmann)
To:        comp.protocols.tcp-ip
Subject:   Ethernet cabling book

A book just came out called "Keeping the Link" that covers all sorts of issues
on Ethernet.  Very detailed.

Dave

-----------[000478][next][prev][last][first]----------------------------------------------------
Date:      Tue, 31 Oct 89  19:30:33 EST
From:      "Roger Fajman" <RAF@CU.NIH.GOV>
To:        chris@cs.UMD.EDU
Cc:        jqj@rt-jqj.Stanford.EDU, randall@virginia.EDU, tcp-ip@SRI-NIC.ARPA.NIC.DDN.MIL
Subject:   Re:  BITNET -- Internet capabilities
>        % ftp remotehost.biguniv.edu
>        <greeting stuff>
>        User: anonymous
>        Password: me@here
>        <restriction stuff>
>        type image
>        <image mode OK>
>        put local-file incoming/remote-file
>        <file goes across>
>        quit
>
> Now all we need is to write it up as an RFC (changing the `put
> local-file incoming/remote-file' sequence to a new `give' command, so
> that the `incoming/' can go away), and write a front end called `give'
> or whatever that does the above automatically.  Hosts can expire stuff
> in ~ftp/incoming, or whatever they name this spool directory, as often
> as desired.
>
> In other words, we need only one change to the FTP protocol (to add a
> command that means `I am sending you a file that you should put in your
> spool directory, whatever its name may be'), along with some front
> ends so that `given' files are handled much like mail: spooled on
> the local machine until the transfer can happen.
> --
> `They were supposed to be green.'
> In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
> Domain:        chris@cs.umd.edu        Path:   uunet!mimsy!chris

Where do I say who the file is for?  I probably don't want to make my
file available to everyone on the receiving system.

Also, use of a special directory name like "incoming" seems to make the
whole thing depend on Unix.  Different operating systems have different
file naming conventions.  I suppose that your "give" command takes care
of that.

One other thing to keep in mind is that it would be very nice to have a
file transfer protocol that would allow for gateways to other networks
such as BITNET and UUCP.  Use of MX records tends to obsure the
distinction between networks.  Why should the user have to remember
that he can send files to this address but not that address?

Roger Fajman
raf@cu.nih.gov

-----------[000479][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 17:41:37 GMT
From:      bzs@world.std.com (Barry Shein)
To:        news.groups,comp.unix.wizards,alt.hypertext,comp.mail.multi-media,comp.protocols.tcp-ip
Subject:   ANNOUNCEMENT: THE OPEN BOOK INITIATIVE



			     ANNOUNCEMENT

		       THE OPEN BOOK INITIATIVE



The Open Book Initiative is being formed to make available freely
redistributable collections of information. There exists huge
collections of books, conference proceedings, reference material,
catalogues, etc. which can be freely shared. Some of it is in
machine-readable form, much of it isn't.

The purpose of the Open Book Initiative is to create a publicly
accessible repository for this information, a net-worker's library.

Information in the Open Book Repository will be available for free
redistribution. On-line access, magnetic media and other methods of
distribution will involve reasonable charges for the services
provided, not the information.

WHAT WE WISH TO ARCHIVE

	All on-line materials (other than software collections)
	such as books, journals, catalogues, conference proceedings,
	magazines, manuals, maps, images, technical documentation,
	reference works, etc. The only software we are interested in
	is software specific to the viewing, manipulation, searching
	and maintenance of information in the repository.

	Materials must be free of copyrights limiting redistribution
	by us or any individual or organization who receives them. A
	copyright ensuring their continued freedom will be assigned
	to all materials distributed.

	We also need pointers to collections of materials which may
	be available. For example, there are government collections
	of interesting data which are available at reasonable costs
	and do not limit further redistribution of copies obtained. 

WHAT WE NEED FROM YOU

	Beyond machine-readable material there are huge collections
	of printed material which could be redistributed if put
	on-line. We need people willing to organize informal projects
	to scan, type or otherwise get this material on-line for
	inclusion in the Open Book Repository.

	We need to get in touch with Library and Information Scientists
	interested in helping us create formats and structures for organizing
	the repository.

	We need international participation to help ensure our efforts
	are useful to people everywhere.

	We need people willing to participate in a Technical Advisory
	Board to help us guide our efforts.

	We need involvement from academia, industry and governments to
	help us enrich this effort without bounds and make available
	a first-rate, freely available information utility.

	We need involvement from publishers who have materials which
	can be included in the Open Book Repository. Many books and
	reference works become unprofitable to publish by ordinary
	paper means. It's time to make these materials available!

	We need involvement from the technical community to choose
	and implement multi-media software standards such as hypertext,
	mark-up languages, index and catalogue software, text retrieval,
	network access methods and more. Standards are critical to our
	efforts.

WHAT WE ARE OFFERING

	WORLD.STD.COM is a public access UNIX system which will
	serve as the initial repository. It is a Sun4/280 system
	and will be expanded as needed.

	Anyone can dial into the system and set up an account if
	they wish direct access (617-739-WRLD.) Accounts are
	charged and proceeds will be used to build the Open Book
	Repository.

	UUCP and other links will be available for the redistribution
	of collections. We will also make collections available on
	magnetic media for reasonable copying charges.

HOW TO GET INVOLVED

	If you think you can help or want more information send
	electronic mail to:

			  obi@world.std.com

	Or call us at Software Tool & Die, 617-739-0202.
	Or drop by our office and chat if you're in the
	area: 1330 Beacon Street, Brookline, MA 02146.

POSTSCRIPT

	This started as an informal discussion group which called
	themselves "The KiloMonkeys Project" (``Strong Typing For
	Weak Minds'') who wanted to figure out how to get useful
	materials on-line and generally available. I have decided
	to make Software Tool & Die a home for this activity and
	formalize the project under the new name "The Open Book
	Initiative."
-- 
        -Barry Shein

Software Tool & Die, Purveyors to the Trade         | bzs@world.std.com
1330 Beacon St, Brookline, MA 02146, (617) 739-0202 | {xylogics,uunet}world!bzs

-----------[000480][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 17:47:11 GMT
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   rsh/rexec/rlogin protocol specs

>From: henry@utzoo.UUCP  (Henry Spencer)
>There are none; you have to read the source code.

Actually, check out the man pages for the servers (rshd, rlogind).
They used to have protocol descriptions, in 4.2. I don't know if they
still do, not having a 4.3 manual set around just now.

It's a start if you don't have source, though there's probably not
much reason not to have source for these programs these days...
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
"And I'd rather have my county die for me" - Grace Slick/Jefferson Airplane

-----------[000481][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 18:22:59 GMT
From:      RAF@CU.NIH.GOV ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   BITNET-Internet discussion

> This no longer really concerns TCP/IP, so I've redirected
> followups to comp.protocols.misc on the USENET side...

Good way to stop the discussion, as some of us aren't on USENET.  If
people want to propose making BITNET more like the Internet, such a
discussion could be held on FUTURE-L@BITNIC (from the Internet,
FUTURE-L%BITNIC.BITNET@CUNYVM.CUNY.EDU). There's also a list devoted
specifically to the topic of domains on BITNET.  It's called
DOMAIN-L@BITNIC.

But if anyone wants to talk about incorporating the best things about
BITNET into the Internet, then the TCP-IP list seems to me to be as
good a place as any to do it.  If there's a list whose topic is the
future of the Internet, please tell me about it.

-----------[000482][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 18:52:03 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   usernames as security hole

In article <5118@omepd.UUCP> merlyn@iwarp.intel.com (Randal Schwartz) writes:
>Gaccckkk.  Blindingly direct and useful security hole.  If I can get a
>list of usernames on your system, I can attack you sooooooooooo much
>easier.

Correction:  blindingly direct and useful security hole that is usually
present regardless.  Except on seriously secretive systems, it is rarely
difficult to compile a (partial) list of user names by other means.  The
correct question is not "is this a security hole?" but "does this open
a security hole any wider than it is already?".
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000483][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 18:54:55 GMT
From:      parker@zaphod.Berkeley.EDU (Ross Parker)
To:        comp.protocols.tcp-ip
Subject:   Re: Changing subnet masks


 
>Also, using 0xFFFFFF70 as a subnet mask is bound to cause trouble.
>You probably meant 0xFFFFFFE0.  Keep those bit-fields contiguous if at
>all possible!

Yup... Like the disclaimer says... the fingers do all the work. My
brain is often disengaged.

Thanks for the reply... I think what you suggest *may* even be workable,
though I'd guess there's upwards of a thousand hosts that would have to
conform...


Ross Parker      				| Why do they put me down?
Microtel Pacific Research Ltd.			| Make out that I'm a clown?
Burnaby, B.C.,	     				| I drink scotch whisky all
Canada, eh?	     uunet!ubc-cs!mpre!parker	|	 day long
(604)293-5495	     parker@mpre.mpr.ca		| Yeah I'm gonna save my money
Disclaimer:					| (gonna put it all away...)
My fingers are doing all the work...		| 'Cause I'm a Scotsman

-----------[000484][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 19:20:09 GMT
From:      aramis.rutgers.edu!paul.rutgers.edu!triumph.rutgers.edu!arora@rutgers.edu  (Ashok Kumar)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Request for public domain SLIP

Hi Everyone,
	Does anyone have a public domain version of SLIP (Serial Line
Interface Protocol)? The code should run on a 386 based UNIX
look-alike machine.
	 Information about other pertinent protocols/software will
also be appreciated.
	Please email the code/info. to: arora@paul.rutgers.edu

Thank you very much.
-ashok

PS: I don't usually read comp.protocols.tcp-ip. This request is for
a friend of mine who does not have access to the net.
-- 
(arora@paul.rutgers.edu)
---------------------------------------------
"What is the way (of Zen)?"
And the Zen Master replied,
"A cloud in the sky and water in the jug."
-----------[000485][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 19:29:29 GMT
From:      kannan@oscsunb.osc.edu (Kannan Varadhan)
To:        comp.protocols.tcp-ip,comp.sys.hp
Subject:   Need statistics on HP3000's



Hi,

	I need to gather performance figures and statistics for
	any model of HP3000's across their ethernet and/or serial line
	interface.

	I'd like to have the throughput, maximum data rate, capacities
	or any other figures that have been collected for various
	classes of protocols like FTP, TCP and/or IP.

	If you have any such information, and would like to share it,
	please let me know.  

	Please mail the information.  If there is sufficient interest,
	I'll repost appropriate info or summaries.

Thanks muchly,

KANNAN

-=-
email:  kannan@osc.edu 	or	{...}!osu-cis!osc.edu!kannan
voice:  {Res.} (614) 297-8720 | {Off.} (614) 292-8234 or 4-9099 on campus
snail:  Kannan Varadhan 306, W. Lane Ave., # 15, Columbus, OH 43201

-----------[000486][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 20:21:55 GMT
From:      pcg@emerald.cs.aber.ac.uk (Piercarlo Grandi)
To:        comp.protocols.tcp-ip
Subject:   Re: New Host-Requirement RFCs

In article <1136@odin.SGI.COM> wicinski@zamna.sgi.com writes:
   MAYBE it might become easier to join, and then we can do away with the
   damn % hack.

If there is centralized (administrative) control, things are easy; but
it will *never* be the case that everybody is registered with the Internet.
The world is not just the USA, and there are bizarre company wide, national,
etc... networks that have nothing to do with the Internet. You cannot simply
say "everybody get registered".

It may happen with X.400; after all, telephone numbers are pretty well
standardized across the world, given that the PTTs do have some sort
of centralized (administrative) control. On the other hand, company wide
*telephone* networks make for interesting problems for outsiders. And
gateways/switchboards don't always work well.

I'd rather everybody be registered with the DNS, with the Internet etc...;
but we *must* be able to do source routing, because the sender may have
information that is not in any registry, or because local sysadmins do
not perform as they should. Sorry folks, that's reality.

Even some purists reluctantly agree about source routing at the *IP* level,
as a last resort measure...
--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk

-----------[000487][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 20:24:00 GMT
From:      FILLMORE@EMRCAN.BITNET
To:        comp.protocols.tcp-ip
Subject:   Macintosh ethernet-tcp/ip tools?

I was wondering if anyone has any ethernet - tcp/ip monitoring tools
which run on a Macintosh.  Something like etherfind or traffic on SunOS
is what I had in mind.  I would appreciate having source code as well.
I can process binhex'd Stuffit files.
Much thanks in advance.
________________________
Bob Fillmore, Systems Software & Communications   BITNET:  FILLMORE@EMRCAN
  Computer Services Centre,                       Voice:   (613) 992-2832
  Energy, Mines, & Resources Canada               BIX:     bfillmore
  588 Booth St., Ottawa, Ontario, Canada  K1A 0E4

-----------[000488][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 20:33:57 GMT
From:      VANCE@TGV.COM (L. Stuart Vance)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet cabling book

>Subject: Ethernet cabling book
>
>A book just came out called "Keeping the Link" that covers all sorts of issues
>on Ethernet.  Very detailed.

BEFORE buying this book, see a book review of it in the July 1989 issue
of ConneXions (volume 3, number 7, page 18).  Typical excerpts from the
review include:

	The book contains serious errors of fact with respect to
	Ethernet/802.3 standards.

and,

		Cheapernet and Thinnet, which run on the
		thinner 75 ohm cabling, support a maximum
		200 meter segment length... (page 39)

	There has never been a 75 ohm 10 megabit baseband Ethernet
	specification and the maximum segment length for 10BASE2 thin
	Ethernet is 185 meters.

"Keeping the Link" also makes outlandish claims like:

  o the limitation of 1024 nodes on an Ethernet is due to its 10 bit
    address space
  o "DECnet is a TCP/IP implementation from Digital Equipment Corporation."

The second item should come as a shock/surprise to many.

Just goes to show that "detailed" and "accurately detailed" can be vastly
different.

-----Stuart
-------

-----------[000489][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 20:50:49 GMT
From:      bkc@OMNIGATE.CLARKSON.EDU (Brad Clements)
To:        comp.protocols.tcp-ip
Subject:   Wanted: Beta testers for Xircom Pocket Ethernet Adapter Packet Driver

I have developed a packet driver for the Xircom Pocket Ethernet adaptor.
If you have one of these units, and would be willing to test the beta version
of this driver, please write to me.


| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clutx.bitnet 
| Network Engineer       Clarkson University              (315)268-2292

-----------[000490][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 23:13:02 GMT
From:      bygg@sunic.sunet.se (Johnny Eriksson)
To:        comp.protocols.tcp-ip
Subject:   Re: Ethernet cabling book

In article <8910311903.AA03243@ucbvax.Berkeley.EDU> dave@CITI.UMICH.EDU
  (Dave Bachmann) writes:
> A book just came out called "Keeping the Link" that covers all sorts of
> issues on Ethernet.  Very detailed.

Sounds interesting.  You don't by any chance have any more information
about it, such as ISBN number or name of author?

-----------[000491][next][prev][last][first]----------------------------------------------------
Date:      31 Oct 89 23:56:00 GMT
From:      ljm@TWG.COM (Leo J McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   IP and/or CLNP over Novell IPX networks


As some of you know, I have previously made available a paper on
encapsulating IP datagrams within IPX packets.  This was never
submitted as an RFC because of the known limitations of the protocol
described (it did not work through Novell IPX bridges [routers] and
it could not be used to encapsulate CLNP packets over IPX networks).
Nevertheless, a number of people have requested copies of that paper.

These limitations have now been overcome and implementations of this
new specification are being tested.  However, one design issue remains
open and subject to debate which should be resolved before I submit this
specification as an RFC.  To allow delivery of an IP packet from IPX
node1 to IPX node2, the destination IPX network number, the destination
IPX node number as well as the physical address of a possible first-hop
IPX bridge in the path from node1 to node2 must be known.

To add the physical address of this possible intervening IPX bridge to
the ARP cache one of two mechanisms can be used:

    1) The ARP request and reply hardware address fields contain only
the destination network and node numbers.  The IPX specific driver must
then add the IPX bridge physical address entry into the cache.  Thus, either
the driver must have write access to the ARP cache or it must maintain its
own ancillary cache.

    2) The ARP request and reply hardware address fields contain the IPX
bridge physical address in addition to the destination network and node
numbers.  However, this value is unknown to the sender of an ARP request.
Thus, it must be inserted into incoming ARP requests by the receive code
of the IPX specific driver before those requests are passed up the
protocol stack to ARP.

Both mechanisms work equally well given the architecture of Wollongong's
DOS products and each have their own measure of ugliness.  However, other
networking architectures may have more difficulty with one mechanism or
the other.  I invite anyone with comments to reply via email.

enjoy,
leo j mclaughlin iii
The Wollongong Group
ljm@twg.com

END OF DOCUMENT