The 'Security Digest' Archives (TM)

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

ARCHIVE: TCP-IP Distribution List - Archives (1990)
DOCUMENT: TCP-IP Distribution List for January 1990 (378 messages, 221089 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1990/01.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 Jan 90 02:04:52 GMT
From:      sl@van-bc.UUCP (Stuart Lynne)
To:        comp.protocols.tcp-ip
Subject:   Re: beta version of compressed SLIP available

In article <8912312141.AA15088@helios.ee.lbl.gov> van@HELIOS.EE.LBL.GOV (Van Jacobson) writes:
>  compressed.slip.rfc.ps.Z -- is a compressed PostScript file
>		containing a draft of the RFC describing the
>		compression algorithm design and implementation.

Would there be any chance to get a non postscript version of this rfc
posted? I hate to flog a dead horse here, but there's lot's of us that don't
have postscript printers down the hall. 



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

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Jan 90 17:26:00 GMT
From:      snorkelwacker!spdcc!esegue!johnl@tut.cis.ohio-state.edu  (John R. Levine)
To:        tcp-ip@nic.ddn.mil
Subject:   Is there slip for 386/ix?
Has anyone come up with a version of slip for 386/ix host-based TCP/IP?
The best would be something which lets a remote machine log in like a user,
then start a slip session, sort of like uucp, but anything will do.

I know how simple slip is, the problem would be getting the async and tcp
drivers to talk to each other.

Thanks,
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
"Now, we are all jelly doughnuts."
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Jan 90 08:54:54 -0800
From:      chris@salt.acc.com (Chris VandenBerg)
To:        tcp-ip@nic.ddn.mil
Merry Christmas to everyone,
				 I'm in the process of working on a distributed
print application using WIN/TCP to distribute some print capabilities out
to 3COM/Bridge terminal servers. I'm having a bit of trouble with the VMS side
of things and was hoping someone io the world has done something similar. here'sthe proposed scene:
	A user logged onto the VAX through a 3COM term server connects to the
the Wollongong TELNET server, then connecting to some application running
under VMS. There is a "network" printer on a slave port on the 3COM that is
used by the VAX. This is connected via use of TWG's 3COM print symbiont that
looks like a logical VMS printer(I guess). The problem is how can I get the
system to recognize when the Terminal user hits a "print screen" key and 
redirect the output to the network printer? I would think that some DCL could
be written to tell the terminal driver that a special key had been hit,
throw the screen buffer into a file, and then send it to the print symbiont,
but has anyone actually DONE something like this? (Re-inventing the wheel
has never been one of my goals in life (:*) ).
		I would greatly appreciate any comments/guidance that anyone
would care to share.
		THanks in advance,
   __    _____   _____     Chris VandenBerg (chris@salt.acc.com)
  //\\  / ____\ / ____\    Advanced Computer Communications
 //__\\ ||_____ ||_____    720 Santa Barbara St. 
// \___\\_____/ \_____/    Santa Barbara, CA 93101
                           (805) 963-9431
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Jan 90 08:21:58 MST
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        efb%suned1.Nswses.Navy.MIL@trout.nosc.mil
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  LOST on net 192.31.106, HELP
>On Dec 31, 13:49, C. You wrote:
>>
>>Please check the routing on 26.17.0.46.  I can ping it from another milnet
>>host but not from a host off the milnet.
>
>It HAS never been administered with respect to RIP or EGP. 

26.17.0.46(VAXB.NSWSES.NAVY.MIL) is advertised by the core as a gateway
for your network.  If it does not know how to route beyond MILNET than
hosts on your net will not be able to go beyond MILNET.  Here is our
EGP entry for your network:

	Destination:       192.31.106.0
        Autonomous System: 164
        Gateway:           26.17.0.46
        Interface:         imp0
        Age:               60
        Protocol:          EGP
        Metric:            0
        Exterior Metric:   2
        Flags:             <UP|GATEWAY>
        State:             <EXTERIOR>
        From Protocol:     <EGP> 
        
That Gateway needs to have similar information about the Internet so that
it can route your packets.  Otherwise, you will continue to be:

	"LOST on net 192.31.106"
	
Can you find another way to the Internet?  NSFnet?  A correctly managed
MILnet gateway?

Just trying to help,

Phil

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Tue, 02 Jan 90 09:53:16 -0500
From:      bdr@ifs.umich.edu
To:        jamesp%wacsvax%uniwa@munnari.oz.au
Cc:        tcp-ip@nic.ddn.mil, bdr@ifs.umich.edu
Subject:   Re: Building a reliable datagram protocol on top of UDP
I am also very interested in this question.
Could you forward the response to me ?

Thanks,

Bob Riddle
IFS Project
University of Michigan
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Jan 90 08:42:00 EST
From:      Richard (R.V.) Williams <VERL@BNR.CA>
To:        <tcp-ip@nic.ddn.mil>
Subject:   Mailing list question.
 I  have  been  running  into references to your mailing list
 when I have questions. The problems is I not sure how to be-
 come part of your mailing list. We have been a  TCP-IP  net-
 work  with in our corporation for a couple of years now, but
 have just recently started connecting to " the outside world
 ".  We have internet access, but have yet to connect to uucp
 nodes outside our corporation.  Any  advice  would  be  very
 helpful.

 Thank you for your time.



                               Regards,

                               Rich Williams
                               Member of Scientific Staff
                               Bell Northern Research
                               1150 E. Arapaho Rd.
                               Richardson, TX  75081
                               U.S.A.
                               verl@bnr.ca
                               011(214) 997-1078
-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 90 03:44:08 GMT
From:      drilex!dricejb@bbn.com  (Craig Jackson drilex1)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Networks considered harmful
There's one other point about this Email vs FAX discussion which I haven't
seen mentioned:

    You don't have to have a FAX machine on your desk to send or receive a FAX.

FAX machines are easily leveraged: our company has no more than one FAX
machine for every 40 staff members.  This works because a "FAX address"
typically consists of not only a telephone number, but also a human-readable
name on the cover sheet.

Another point which makes this possible is that you don't have to be at the
FAX machine to compose a FAX.  In fact, you don't need any fancier technology
than pencil and paper to compose a FAX.

These are important points for this discussion: I know that FAX has slowed
the use of Email in our division, for reasons including these.  (As well
as the other various reasons which have been mentioned.)  I say slowed
because Email is still in use, and possibly is increasing.  In this
environment, Email is used for works-in-progress ("Groupware") and
store-and-forward file transfer.  It's also used for conventional
conversation, but rarely among non-techies.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      Tue, 2 Jan 90 14:58:13 PST
From:      braden@venera.isi.edu
To:        drilex!dricejb@bbn.com, tcp-ip@nic.ddn.mil
Subject:   Re: partial transfer recovery in RFC and OSI protocols

	I suppose that the way this would be dealt with is for the receiver to
	store an auxiliary file, with indications of "when I began record m,
	n bytes had been sent".  This file would be periodically updated (every
	few hundred records) and pushed to the disk.  Some care would need to be
	taken to ensure that the received file and the marker file would be
	consistent after a crash.

The restart mechanism built into FTP is essentially a nice version of what
you suggest.

Bob Braden


-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Tue, 02 Jan 90 12:35:32 EST
From:      Doug Nelson <NELSON%MSU.BITNET@CORNELLC.cit.cornell.edu>
To:        "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>
Subject:   Stolen systems registry
I received the following message from one of our departmental systems
administrators:

>At 11:30 ayem on Christmas day, a complete HP 9000/340 system was taken
>from 119 EB. The ethernet address is ...
>
>P.S. Do you know if there is a national registry for stolen ethernet
>addresses?  Do you think this would be worth doing?

While I do have some monitoring software that could be used to track
stolen systems locally, it is only useful if the system is reattached
to our own network.  Has anyone tried to set up a cooperative venture
between multiple sites?  Is there someone who has such a list, or would
be willing to maintain one?

Doug Nelson
Manager of Network Software
Michigan State University
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 90 14:18:04 GMT
From:      zaphod.mps.ohio-state.edu!wuarchive!texbell!sugar!ficc!peter@tut.cis.ohio-state.edu  (Peter da Silva)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Networks considered harmful
In article <7161@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson drilex1) writes:
> There's one other point about this Email vs FAX discussion which I haven't
> seen mentioned:

> You don't have to have a FAX machine on your desk to send or receive a FAX.

You don't have to have a modem on your desk to send or receive Email.

You probably have a terminal on your desk (or near it) anyway. If you don't,
then there's an advantage FAX has over Email. But lots of people do. Remember
all those ads for FAX boards... "We don't see much of Joe any more".

This discussion has little to do with TCP/IP any more. Followups directed
to comp.mail.misc.
-- 
`-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
 'U`  Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org>.
"It was just dumb luck that Unix managed to break through the Stupidity Barrier
and become popular in spite of its inherent elegance." -- gavin@krypton.sgi.com
-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 90 14:53:16 GMT
From:      bdr@IFS.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Building a reliable datagram protocol on top of UDP

I am also very interested in this question.
Could you forward the response to me ?

Thanks,

Bob Riddle
IFS Project
University of Michigan

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 90 17:35:32 GMT
From:      NELSON@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Stolen systems registry

I received the following message from one of our departmental systems
administrators:

>At 11:30 ayem on Christmas day, a complete HP 9000/340 system was taken
>from 119 EB. The ethernet address is ...
>
>P.S. Do you know if there is a national registry for stolen ethernet
>addresses?  Do you think this would be worth doing?

While I do have some monitoring software that could be used to track
stolen systems locally, it is only useful if the system is reattached
to our own network.  Has anyone tried to set up a cooperative venture
between multiple sites?  Is there someone who has such a list, or would
be willing to maintain one?

Doug Nelson
Manager of Network Software
Michigan State University

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 90 18:27:32 GMT
From:      mcsun!ukc!acorn!tenset!colin@uunet.uu.net  (Colin Manning)
To:        tcp-ip@nic.ddn.mil
Subject:   Karn and Jacobsen TCP papers wanted
Would anyone be prepared to e-mail me either of the following
two papers:

  Karn, P. and C. Partridge, "Estimating Round-Trip Times
  in Reliable Transport Protocols", Proc. SIGCOMM '87, Stowe, VT,
  August 1987.

  Jacobson, V., "Congestion Avoidance and Control".

They are referred to in RFC 1122 but do not appear to be RFC's, so
where does one get them from ?

Many 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.          |
-----------------------------------------------------------------------
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      2 Jan 90 23:16:50 GMT
From:      windom!morris@handies.ucar.edu  (Don Morris)
To:        tcp-ip@nic.ddn.mil
Subject:   Big Packet IP
We would like to run some communications experiments using large IP packets
( >= 16k bytes) between two Suns connected on a Hyperchannel as a
prelude to general TCP/IP use on a Hyperchannel.

Does anyone have experience doing this or know of any reference to
this being tried? We are not as much concerned about hacking the
code to make this work as we are about monitoring the performance
and tuning the packet sizes. Thanks for any input.

-- Don --
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Wed, 03 Jan 90 08:17:30 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        colin <@uunet.uu.net:colin@tenset.uucp>
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: Karn and Jacobson TCP papers  wanted

Colin:

I'll e-mail you a copy of the Karn and Partridge paper.

However, in general, if you want to get SIGCOMM proceedings, they
can be ordered from the Association for Computing Machinery,
ACM Order Dept., PO Box 64145, Baltimore MD, 21264.

I believe SIGCOMM '87 is still in print (Order # 533870) for $30
SIGCOMM '88 is certainly in print (Order # 533880) for $26

Note that Proceedings of SIGCOMM are also mailed to all members of
ACM SIGCOMM -- so if you want future proceedings, you can sign up
for SIGCOMM (you don't have to be an ACM member to join).  Postscript
copies of the SIGCOMM application can be found on nnsc.nsf.net
in CCR/application.ps

Craig
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Jan 90 08:14:11 PST
From:      braden@venera.isi.edu
To:        decwet.dec.com!wickham@decwrl.dec.com, tcp-ip@nic.ddn.mil
Subject:   Re:  collecting and passing IP options to TCP applications

	I haven't seen this discussed much, but I'm interested on opinions as
	to how IP options should be retained for delivery to a TCP session
	user. The host requirements doc sez that implementations should make
	options available to user applications. 
	
Charlie,

I think the HR RFC says that the IP layer must pass options to the
transport layer, and that UDP in particular must pass options on the
the application.  TCP is not required or requested to pass IP or TCP
options to the application.

Bob Braden


-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 90 01:32:49 GMT
From:      decwet.dec.com!wickham@decwrl.dec.com  (Charlie Wickham, DECWest Engr. 02-Jan-1990 1705)
To:        tcp-ip@nic.ddn.mil
Subject:   collecting and passing IP options to TCP applications
I haven't seen this discussed much, but I'm interested on opinions as
to how IP options should be retained for delivery to a TCP session
user. The host requirements doc sez that implementations should make
options available to user applications. In a datagram world, one could
see where the presentation of options would be pretty
straight-forward: options are presented when the datagram is read.

For connection-oriented sessions, a couple of scenarios come to mind:
1) individual options accumulate until read and 2) option "blocks" are
retained and queued.

With accumulation, an option's value is overwritten when a datagram
arrives with that option. Note that the value maybe the same, in which
case, nothing has changed. When the options are "read" by the
application, the option area is cleared and incoming options start
accumulating again.  This solution provides the least amount of
accuracy since all options are "glommed" together and distinct option
values are not maintained. On the other hand, it provides a simple
mechanism of collecting and conveying the option info.

Retaining the original option blocks provides more accurate
information (no option data is lost), but it would seem to require
some sort of syncronization with the data stream to be really useful
(is that true?). Also, if the data stream is read and there is no
desire to read the options, how should that be handled?

Finally, are there any implementations that present IP options to TCP
users?

thanx,
charlie

wickham@decwet.dec.com
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 90 10:30:34 GMT
From:      mcsun!cernvax!chx400!cgch!news@uunet.uu.net  (Hans W. Barz)
To:        tcp-ip@nic.ddn.mil
Subject:   LAT-to-Telnet Gateway
I'm looking for a product, which translate LAT to Telnet. Please do not
propose just milking-machines approaches, since this is not transparent to the
users.

Hans W. Barz, R.1032.3.34, CIBA-GEIGY, 4002 Basel, Switzerland
mail: whwb@cgch.uucp
phone: +41/61/6974520
fax: +41/61/6973288
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Jan 90 17:15:53 EST
From:      get@detroit.Central.Sun.COM (Gary Turnquist  Sun Consulting - Detroit )
To:        tcp-ip@nic.ddn.mil
Cc:        get%detroit@Sun.COM
Subject:   tcp-ip user group information
To whom it may concern:

I'm interested in how to get on and off your EMail user group.
Could you pass this information on to me?
Thanks
Gary Turnquist
Sun Microsystems
Southfield Michigan

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 90 13:17:30 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Karn and Jacobson TCP papers  wanted


Colin:

I'll e-mail you a copy of the Karn and Partridge paper.

However, in general, if you want to get SIGCOMM proceedings, they
can be ordered from the Association for Computing Machinery,
ACM Order Dept., PO Box 64145, Baltimore MD, 21264.

I believe SIGCOMM '87 is still in print (Order # 533870) for $30
SIGCOMM '88 is certainly in print (Order # 533880) for $26

Note that Proceedings of SIGCOMM are also mailed to all members of
ACM SIGCOMM -- so if you want future proceedings, you can sign up
for SIGCOMM (you don't have to be an ACM member to join).  Postscript
copies of the SIGCOMM application can be found on nnsc.nsf.net
in CCR/application.ps

Craig

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      Wed, 03 Jan 90 23:50:06 PST
From:      crucible@fernwood.mpk.ca.us
To:        Distribution:;
Subject:   The INTERNET CRUCIBLE v2.1
INTERNET CRUCIBLE                                                 SMTP EDITION
January, 1990                                               Volume 2 : Issue 1

   In this issue:
	- Letters in response to Volume 1, Issue 2
	- Overselling The Network
	- Reprint availability

   THE CRUCIBLE is a moderated forum for the discussion of Internet issues.
   Contributions received by the moderator are stripped of all identifying
   headers and signatures and forwarded to a panel of reviewers.  Materials
   approved for publication will appear in THE CRUCIBLE without attribution.
   This policy encourages consideration of ideas solely on their intrinsic
   merit, free from the influences of authorship, funding sources and
   organizational affiliations.

   The INTERNET CRUCIBLE is an eleemosynary publication of Geoff Goodfellow.

Mail contributions to:                          crucible@fernwood.mpk.ca.us

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

	   LETTERS IN RESPONSE TO THE CRUCIBLE VOLUME 1, ISSUE 2
	       The Changing Nature of Managing the Internet:
			 A Paradox in Governance

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

Sir:

I applaud the recommendations of this proposal.  How do they get implemented?

Yours etc.,

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

Sir:

	Although our site is not an Internet site, my contact with the
Internet while in college sparked a continuing interest its activities. In
The Crucible, (Vol. 1, Iss. 2), your contributors raises an issue concerning
the role of the IAB:

   	For the sake of argument, suppose one or more members of the IAB
   were employees of a commercial concern.  Further, suppose that these
   commercial concerns were directly tied to Internet technology.  For
   example, one of of these concerns might be a vendor of Internet technology,
   or another might be a supplier to such vendors.

	Was this not a concern with the original mandate of the IAB when
DARPA founded the project? Obviously, network technology has become a
considerably more competitive market than when the Internet was originally
created, but since it is gov't funded, isn't there a bidding process for
introducing new technology into the Internet? It seems to me that this is a
fairly self-evident concern.

	I think The Crucible is very interesting, although I do find the
lack of attribution disquieting. I think that if people are afraid of
openly criticizing the Internet management 1) they should revise their
opinion of the organizations that they are involved with or 2) as you
suggest, make the Internet management more accountable.

Yours etc.,

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

Sir:

	I would like to agree with your policy of keeping contributions to
The Crucible anonymous.  Many people are very willing to make honest
observations about problems with the Internet in private, but are afraid
that either their funding or their credibility in the Internet community
will be harmed if they speak publically.  I may not agree with all of these
observations, but I agree with the value of having a place where they can
be made.

Yours etc.,

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

Sir:

	While I feel that an open discussion of Internet is just fine, I
disagree strongly with several of the basic assumptions and statements in
The Crucible.

  1) "Each contribution is refereed by a range of networking experts from
      academia, research, and industry.  As with refereed professional
      journals, the referees are responsible for ensuring that a contribution
      is credible..."

	This is patently false and potentially quite damaging statement.
For many years, we in the academic community have worked to convince our
colleagues (e.g., physists, chemists, and biologists) that Computer
Scientists establish and use high standards for academic tenure and
promotion.  In the academic world, the terms "peer review" and "refereed
publication" are sharply distinguished from "open" or "moderated"
discussions.  As a member of a departmental promotion/tenure committee,
editor of one academic journal, and the editor-in-chief of another, I am
painfully aware of the academic refereeing process and how it differs from
what a pedestrian might think of as "refereeing".  Scientists participate
in peer review voluntarily because they believe it will help keep their
publications accurate and objective.  Part of the refereeing process
involves eliminating any unsubstantiated, subjective opinions.  Thus, in a
refereed publication, one can say, "professor X proved Y" by giving a
citation to the published work, but one cannot say "I think professor X was
on vacation daydreaming and wasn't thinking clearly when he wrote paper Z"
because that conclusion is not warranted by the documented facts.  This
distinction may seem like a minor quibble to readers who are interested in
expressing unsubstantiated opinions (or readers who are trying to speculate
at the discussion that went on behind the closed doors of IAB meetings),
but among my academic colleagues, it is an important point.  Feel free to
publish unsubstantiated opinions or speculation, but please retract the
statements comparing The Crucible to a refereed journal and help us keep a
clear distinction between opinionated discussions and refereed journals.

  (2) "Publication without attribution is a time-honored means for advancing
       positions solely on the basis of their content.  Unlike professional
       journals that exist both to serve the community and contribute to the
       authors' reputations, THE CRUCIBLE exists solely to serve the
       community.  THE CRUCIBLE moderator, a member of the network community
       since 1973, feels that the Internet is best served by fostering a
       forum in which ideas stand solely on their intrinsic merit, not on
       the standings of the authors advancing the ideas...

       THE CRUCIBLE, by publishing without attribution, prevents prejudice
       towards contributions on the basis of authors' standings or their
       affiliations, and encourages contributors to speak freely, without
       organizational entanglements or jeopardizing funding sources.  THE
       CRUCIBLE relies on a wide cross-section of referees to filter
       contributions that are not of a meritorious nature.

	I agree that anonymous submissions of technical ideas are wonderful
and helps prevent predjuice.  However, it only works for technical ideas
that are the subject of objective discussion, not for slanderous
allegations about individuals or groups.  For example, if three groups
propose a replacement for the IP addressing scheme, anonymous consideration
of the ideas may eliminate predjuice.  However if a random person says "the
IAB thought thus and so about topic X" that's absolutely different than
Vint Cerf, chair of the IAB, saying what the IAB thought.  More to the
point, imagine someone writing, "I will work hard to see that Q does not
gain support."  If the author is chairman of the FRICC, the statement is a
policy statement; but if the author is a first-year grad student, it's
meaningless.  In an anonymous submission situation, you as moderator must
decide whether the publication will contain technical statements, policy
statements, or random opinions.  You take responsibility for assuring your
readership that articles giving undocumented statements come from people
who are somehow giving correct and authoritative facts (or you should ask
authors to write "I have the impression..." in front of such statements
instead of publishing them as plain fact.  In this regard, you have let us
down.  At INTEROP 89(tm) you said that no one has given you one specific
instance of inaccuracy, so let me illustrate what I mean: you published an
article that blindly referred to CSNET as an example of a technology in
which the subscriber pays for the service.  While it is true that there is
some usage-sensitive charging, CSNET survives ONLY because it was started
with an NSF seed fund and received other NSF grants along the way; it is
NOT a good example of the pay-for-use paradigm succeeding.  Maybe if the
author had been a member of the CSNET executive committee he/she would have
known that, but as editor, you must either filter such statements or be
sure the authors are knowledgable.  Similarly, articles were painfully
unaware of existing plans to upgrade NSFnet (not a secret as far as I know,
but you probably have to ask to find out), and of the existing work to
coordinate management of NSF regional nets.

	If you want The Crucible to gain respect, more editorial discretion
will be needed (or rethink your policy and use anonymous submissions only
for objective technical material).

Yours etc.,

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

Sir:

In THE CRUCIBLE V1.2 a contribution stated:

   Or do I have it wrong, and the worthy scholar of your piece doesn't care
   whether we use world class networking in our allegedly world class national
   research enterprise but just wants cheap reliable email?  If so, we already
   have it in the form of BITNET which reaches millions of individuals
   worldwide for pennies a message and is 100% supported by member/user fees.

	Would that it were so. Unfortunately BITNET is not 100%
self-supported.  Today BITNET runs much of its traffic over the regional
and national IP networks. As such, it too is now relying upon governmental
funding.  I have seen quotes of as much as 20% of the NSFNet traffic being
actually NJE buffers encapsulated in TCP/IP datagrams (in support of
BITNET). We feel subject to our own success, and traffic outgrew carrying
capacity, with our membership being unwilling to explicitly fund the
additional capacity needed to carry our own traffic. Sigh.

Yours etc.,

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

Sir:

	I find the political issues involved with technology to be as
fascinating as the technical problems, and this is one reason I enjoy The
Crucible.

	While reading the 2nd issue, it seems pretty clear that the
author(s) had an axe to grind (perhaps rightly so).  This of course
highlights the anonymous policy of The Crucible, and makes one wonder about
the author's own motivation.  Also, I am curious as to how many different
people contribute material, and who writes which pieces.

	I would like to suggest that authors be identified with pseudonyms
(ala the Federalist Papers), and maybe a two-line bio telling us what role
they play in the Internet community.  This would help readers keep straight
the various views.

	I realize this is a slight departure from the policy of "advancing
positions solely on the basis of their content", but without any clue as to
the author's background or basis for his ideas, I would tend to slightly
suspect some of the more extreme critisms they make.

Yours etc.,

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

	It is THE CRUCIBLE's policy to correct errors.  Readers are urged
to call mistakes to our attention by mailing to crucible@fernwood.mpk.ca.us

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

			  Overselling The Network

	Few users of the Internet would argue that there are no benefits to
networking.  Electronic mail, file transfer, and access to remote resources
are all services that we enjoy using every day.  A bit of culture shock is
bound to ensue when the marketeers get involved to sell "The Network" to
The Public.  This is the result of the well-intentioned, but often
unintentionally humorous and shocking, video production of "The National
Network" by MCI and IBM.

	To introduce the concept of a network, the video begins and ends
with a conversation between a scholar from the Renaissance and a women from
the near-future garbed in a StarTrek-esque uniform.  The opening scene is
used to set-up a linkage between Einstein's theory of relativity and
"communications moving at the speed of light".  Fortunately, the scene and
its shmaltzy dialogue lasts only a couple of minutes before the video gets
on to make its sales pitch.

	The sales pitch is that A National Research Network would be A Good
Thing to have, and that we need "...a network that is 1000 times more
powerful" than our current networking capability.  No arguments there.  
In fact, this is an important message to impress upon The Public and The
Government: intensive, well-supported research is critical to the
development of the next generation of networks.  There are however, two
serious flaws in the video's presentation: inadequate examples of
networking, and arguably irresponsible claims about the reliability and
dependability of research networks.

	Throughout the video, various examples of computer-based
applications are presented, such as the use of super-computer access for
bio-modeling, telescience, and so on.  Although the examples are powerful,
they suffer from two defects.  First, there is no time frame associated
with the examples--the viewer gets the impression that just about
everything described is already implemented.  Second, there is no
distinction made between distributed and non-distributed applications--
virtually all of the examples, except for telescience, involve technologies
that rely on computer programs, not on computer networks.  

	These are serious defects, because money could be well spent on
developing computer applications without funding the network, per se.  That
is, many of the examples given in the video show the value of computer
applications, not the value of distributed applications (telescience, of
course, being the exception).  In view of such an approach, one might
easily interpret the video as suggesting that little work is needed on the
networking aspect--an unexpected, but logical response.

	A misleading and arguably irresponsible impression about the value,
reliability and dependability of The Research Network is given by the video's
example of the use of The Network in providing emergency medical care.

    The video cuts to a helicopter landing at a hospital, and we hear the
    voice-over:

	"One of the most immediate benefits of a National Research Network
	 will be to speed better health care to all regions of the
	 country.  Most people do not live near a major medical
	 center--for them, The Network could be a life saver."

    then the scene changes to an examining room.  We see a young doctor
    examining a sickly youth.  The camera pans to the concerned mother who 
    is on the verge of tears as the doctor discusses her child's case.

	What is wrong with this scene?  Probably it is using the term
"Research Network" and "life saver" in the same thought!  Given, among
other things, the hit-and-miss nature of routing in the Internet (and
the inability of the engineering and research community yet to fix it),
it is a tremendous leap of faith to imagine that Our National "Research"
Network will have the stability necessary for life-critical situations.
The following scenario is more likely:

	Doctor: "Nurse, I need the patient's blood analysis to determine
		 the medication dosage which may save the patient's life."
	Nurse:  "I'm sorry Doctor, RIP has just begun counting to infinity,
		 we've lost connectivity to the backbone, and 
		 network operations doesn't answer the phone."
	Doctor: "Get my lawyer on the line, I want to make sure my
		 malpractice insurance covers this..."

	If the medical hard-sell wasn't enough, you need to continue
viewing only about 10 more minutes before the spectre of national security
is invoked:

	"We have a major dependence in this nation on the creation and
	 the transmission of ideas.  The future of this nation is at stake."

	From here, it is easy to imagine how the speaker transitions to
having The Federal Government paying for all of this.  While it is clearly
in The National Interest to fund research for next-generation networking,
there is a very big danger with the tack taken by this video: overselling
The Network.

	Recent history is the best teacher here; consider how the original
NSFNET was oversold to the U.S. Science community.  The original goals of
NSFNET were straight-forward and honest: super-computer access for
physicists.  Unfortunately, the technology then available was not quite up
to speed for the size and topology specified for the project.

	What began as "NSFNET Phase I" was under-capitalized, under-manned,
and technically questionable.  After the sale to The Science Community was
consummated, it was up to The Networking Community to make it happen.
NSFNET Phase I would have failed, except for the heroic efforts of one
good-natured, but extremely overworked networking guru.  The routers were
flakey, connectivity was sketchy, and connections were creaky, but it was
enough to make another sale--"NSFNET Phase II," which brought a massive
infusion of capital and an industry coalition to make the technology appear
to be cost-effective.  Fortunately for all of us, the NSFNET Phase II
delivers much better service than the Phase I project.  Unfortunately for
our networking guru, all The Science Community ever saw was that "tinkerer"
who was constantly breaking "their network."  The guru got bawled out at
the National Academy of Sciences for his efforts.

	The Real Danger: as academicians, physicists have little real power
(no insult intended).  But, The Public, The Medical Profession, The Legal
Profession, and The Politicians, do in fact Have Power.  If The Networking
Community screws up this new "National Research Network"--if it is poorly
designed or executed, like the NSFNET Phase I cacophony--then the
networking research and engineering community will be held responsible.
The punishment won't be getting bawled out by a group of scholars, it will
be an international media-event of the first order.

	By making a video for consumption by The Public, The Medical
Profession, The Legal Profession, and The Politicians, and by making
connections between The `Research' Network and life-critical care, we have
begun the game of repeating history.  We are once again allowing ourselves
to oversell The Network.  MCI and IBM are to be congratulated for producing
a video to promote the concept of a National Network, but tear-jerking,
drum-beating scenes inappropriately linking time critical health care for
the masses with a research network due the cause a disservice.  "The
Network," if presented with realistic distributed applications can pretty
much sell itself!

REFERENCE:  "National Network" --
    A production of MCI and IBM (MCI Video Production Center, McLean, VA)
    Color, VHS, 20 minutes.  This video is available at any of the 
    organizations running the regional networks of the NSFNET.

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

Email reprints of THE CRUCIBLE are available from crucible@fernwood.mpk.ca.us:

v1.1:	"A Critical Analysis of the Internet Management Situation:
	 The Internet Lacks Governance", examines Internet technical and
	 accountability failures. (August 1989)

v1.2:	"The Changing Nature of Managing the Internet:
	 A Paradox in Governance", examines the paradoxes and failures
	 inherent in the Internet management structure. (September 1989)

-------
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      Wed, 03 Jan 90 14:59 CET
From:      "pansiot"                                   <D32107%FRCCSC21.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Cc:        JJ Pansiot                           <pansiot@ISIS.OSIRIS.FR>
Subject:   TCP/IP for iRMX 86

I am looking for TCP/IP running on
  Intel 380 (Multibus) under iRMX 86  (and over Ethernet)
preferably running concurently with Intel's OPEN-NET.
Any public domain or commercial software?

    Jean-Jacques Pansiot
    Departement d'Informatique
    Universite Louis Pasteur, Strasbourg, FRANCE
    E-mail: D32107@FRCCSC21.bitnet
-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 90 16:43:13 GMT
From:      polygen!bill@CS.BU.EDU  (Bill Poitras)
To:        tcp-ip@nic.ddn.mil
Subject:   Installation for a 3C505 ethernet card
Could someone please send me how to install a 3C505 card?  I have no docs
for this card with tons of jumpers.  All I need is what each jumper/switch block
does, a general scheme for figuring what different values are possible for each
block.  Ie "jumper block #x is for base memory, and the lowest address is 
0xC000, and each possible jumper increments by 0x80"  I know how to configure
PC boards, I just need a few specifics.  I have called 3Com, and everybody is 
at a conference or something for a week.  Since I won't be working during the
week anymore (I am going to school), my schedule is going to get pretty hairy.

Anyway, replies by e-mail would be best, but if you have Xeroxable material,
Snail-mail would be acceptable too, or even a Fax. 

FAX # (617)890-8694

+-----------------+---------------------------+-----------------------------+
| Bill Poitras    | Polygen Corporation       | {princeton mit-eddie        |
|     (bill)      | Waltham, MA USA           |  bu sunne}!polygen!bill     |
|                 |                           | bill@polygen.com            |
+-----------------+---------------------------+-----------------------------+
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 90 17:53:47 GMT
From:      ginger.acc.com!salt.acc.com!lars@ucbvax.Berkeley.EDU  (Lars J Poulsen)
To:        tcp-ip@nic.ddn.mil
Subject:   Screen dumps from VMS terminals
In article <9001021654.AA04352@salt.acc.com>
   chris@SALT.ACC.COM (Chris VandenBerg) writes:
>I'm in the process of working on a distributed
>print application using WIN/TCP to distribute some print capabilities out
>to 3COM/Bridge terminal servers. I'm having a bit of trouble with the VMS side
>of things and was hoping someone io the world has done something similar.
>here's the proposed scene:
>	A user logged onto the VAX through a 3COM term server connects to the
>the Wollongong TELNET server, then connecting to some application running
>under VMS. There is a "network" printer on a slave port on the 3COM that is
>used by the VAX. This is connected via use of TWG's 3COM print symbiont that
>looks like a logical VMS printer(I guess). The problem is how can I get the
>system to recognize when the Terminal user hits a "print screen" key and 
>redirect the output to the network printer? I would think that some DCL could
>be written to tell the terminal driver that a special key had been hit,
>throw the screen buffer into a file, and then send it to the print symbiont,
>but has anyone actually DONE something like this? (Re-inventing the wheel
>has never been one of my goals in life (:*) ).

Chris,

      What you are trying to do is probably not practically feasible
(it is months and months of system programming). It is not a networking
problem, but a VMS problem, because the desired capability is not
available to local VMS users either.

      The only multiuser system I have seen that allowed terminal users
to send screen dumps to the system spool was the WANG VS system. It was
a wonderful feature, and we used it a lot when writing proposals: We
would work up the screen layouts in an interactive form definition
utility, and then print them out. The printed screen dumps had a frame
with counting marks for lines and columns. The WANG VS system used
proprietary intelligent terminals similar to those used in the WANG WP
and OIS system: In today's terms we would call it a diskless PC, but the
only programs ever run on it were 3270-emulation-like screen formatters
provided with the operating system. In that system, the feature was
implemented by the terminal and the "session manager" together. When the
user hit the "interrupt" function key, the session manager would ask the
terminal to upload the current screen image (so it could be restored on
a "continue" command). The dump function then worked off that screen
dump. Any system with 3270-like terminals could easily do this, but I
don't know of any others that do. Neither TSO nor VM have such features
in their session managers.

      To do this in any operating system that uses character-at-a-time
ASCII terminals and prides itself on device independence is not
feasible. In both UNIX and VMS, the operating system has no idea of what
is on the screen. There is no standard way to upload a screen dump to
the host, so the driver would have to monitor the data flow and maintain
a duplicate of the screen by interpreting escape sequences. Given the
variety of terminals in the world, that is impossible.

      It might be more feasible to do this for a single terminal type,
but the command sets of terminals like the VT100 are fairly large and
complex (each of the about 15 model variations of VT100 has different
twists to the command set; most lookalikes are not VT100's at all, but
VT102 !!!), and you can imagine how upset people would be if the screen
dump was not really like the terminal.

      Implementing the screen capture feature, can be done in several
different ways:

(1) In the terminal. Many terminals actually have a port on the ack for
    attaching a printer. VT101 had a printer port and a "print screen" key.
    I suspect that you don't really like this version.
(2) In the terminal server. IBM-3270 cluster controllers have a printer
    port that supports a "print screen" key on the terminal. In your
    case, that would probably be the best solution. Such a feature could
    be coupled with a session manager and preserve your screen as you
    switched between multiple sessions (possibly to different hosts).
(3) In the VMS terminal driver, with some help from a user-written
    system service attached to DCL. This would be VERY hard to do, would
    not necessarily work with all terminal ports (DECnet "SET HOST" uses
    a separate non-standard terminal driver), it would depend on
    unpublished internal hooks in the terminal driver, (requiring a lot
    of reading of the microfiche) and would have to be re-done with each
    new version of VMS. Some people have this kind of thing to build
    "big-brother-looks-over-your-shoulder" access for MIS user support,
    but it is ugly, expensive, and crash-prone.
(4) In a gateway program on the VMS VAX: Your login session runs this
    program which then opens a new connection back to the same host,
    (using either the RTA (set host), RTB (cterm) or TELNET protocols
    or a PTY driver) you log in again, and the program can now monitor
    the data flow and provide log files and screen dumps on request.
    This could be implemented without access to system sources; it could
    be done entirely in user mode. Come to think of it, I think such
    features may actually exist in commercially available PHOTO-like
    utilities with names like SPY etc.

I have added comp.sys.vms to the distribution in the hope that someone
has seen this kind of thing somewhere.

/ Lars Poulsen	- Disclaimer: The disclaimer below does not apply today.
--
/ Lars Poulsen <lars@salt.acc.com>   (800) 222-7308  or (805) 963-9431 ext 358
  ACC Customer Service              Affiliation stated for identification only
                My employer probably would not agree if he knew what I said !!
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      Wed, 3 Jan 90 23:19:10 EST
From:      Dave_Katz@um.cc.umich.edu
To:        tcp-ip@NIC.DDN.MIL, jst@cca.ucsf.edu
Subject:   How is TCP/IP carried on T1's?
>Someone I know claims that most TCP/IP packets transmitted on T1 lines are
>imbedded in X.25 protocol packets.  Is this true, or what is actually
>used?   Or it TCP/IP alone with maybe an alternate checksum (CRC) sufficient?
 
It depends on which manufacturer makes the routers.  A number of proprietary
schemes are in use today;  I know of at least one vendor that uses pieces
of X.25.
 
Running IP directly over the data link is insufficient if you ever intend
to run multiple protocol families over the same link, since you need a
method of demultiplexing the different protocols.  For example, some
routers use a proprietary header containing the ethertype of the protocol.
 
The Point-to-Point protocol addresses these issues and is available
as an Internet Draft;  vendors will be quick to implement it once it
becomes an Internet standard, after which routers from different vendors
will actually interwork on point-to-point links.
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 90 20:51:36 GMT
From:      polygen!bill@CS.BU.EDU  (Bill Poitras)
To:        tcp-ip@nic.ddn.mil
Subject:   Prompts in KA9Q
How can you get KA9Q to display the 'ftp>' or 'telnet>' prompt when you are
using these facilities?  If there is a version that does this, what is its
version number and where can I get it?  Thanks in advance.


+-----------------+---------------------------+-----------------------------+
| Bill Poitras    | Polygen Corporation       | {princeton mit-eddie        |
|     (bill)      | Waltham, MA USA           |  bu sunne}!polygen!bill     |
|                 |                           | bill@polygen.com            |
+-----------------+---------------------------+-----------------------------+
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      3 Jan 90 22:25:07 GMT
From:      cca.ucsf.edu!jst@cgl.ucsf.edu  (Joe Stong)
To:        tcp-ip@nic.ddn.mil
Subject:   How is TCP/IP carried on T1's?
Someone I know claims that most TCP/IP packets transmitted on T1 lines are
imbedded in X.25 protocol packets.  Is this true, or what is actually
used?   Or it TCP/IP alone with maybe an alternate checksum (CRC) sufficient?

      Joe Stong     jst@cca.ucsf.edu
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 90 00:17:08 GMT
From:      shlump.nac.dec.com!michaud@decwrl.dec.com  (Jeff Michaud)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LAT-to-Telnet Gateway
> I'm looking for a product, which translate LAT to Telnet. Please do not
> propose just milking-machines approaches, since this is not
transparent to the
> users.

	Well if you have any ULTRIX V3.0 or later systems around take a look
	at /usr/etc/lattelnet.  It's documented in the "Ethernet Communications
	Servers" manual (chapter 5 for V3.0 documentation).

/--------------------------------------------------------------\
|Jeff Michaud    michaud@decwrl.dec.com  michaud@decvax.dec.com|
|DECnet-ULTRIX   #include <standard/disclaimer.h>              |
\--------------------------------------------------------------/
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 90 00:26:04 GMT
From:      snorkelwacker!spdcc!dyer@tut.cis.ohio-state.edu  (Steve Dyer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How is TCP/IP carried on T1's?
In article <2695@ucsfcca.ucsf.edu> jst@cca.ucsf.edu (Joe Stong) writes:
>Someone I know claims that most TCP/IP packets transmitted on T1 lines are
>imbedded in X.25 protocol packets.  Is this true, or what is actually
>used?   Or it TCP/IP alone with maybe an alternate checksum (CRC) sufficient?

T1 is just a bit pipe.  You usually have some sort of synchronous
hardware/firmware on each end which also provides some form of point-to-
point protocol.  This could be byte-oriented DDCMP, as with DEC DMR-11
sync interfaces, or the bit-oriented LAPB/HDLC, sometimes referred to
as X.25 level II, or even a minimal encapsulation with checksum, as with
the DEC DMR-11 in "maintenance mode".  What's important is that the two
ends agree.  Proprietary routers have already made their choices.
I guess in the future, some form of the upcoming Point-to-Point Protocol
could be used.

I don't have any data on the reliability of data streams over T1 lines,
which might drive a selection of protocol.  We routinely ran in maintenance
mode with DMR-11's between Harvard and MIT in the early days of the JVNCnet.
The hardware discarded packets with bad link-level checksums, but otherwise
did not perform any retransmissions.  The sentiment was that it was undesirable
to have lossiness be transformed into delay in the calculation of TCP
round trip time and retransmission timeouts.


-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      Thu, 4 Jan 90 09:03:15 EST
From:      mep@aqua.whoi.edu (Michael E. Pare)
To:        mcsun!cernvax!chx400!cgch!news@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re:  LAT-to-Telnet Gateway
Two companies I know of make LAT-Telnet "gateway" modules for their
terminal servers.  I'm not sure of the details on how they do it so
I'm not sure of how user transparent they are.  But it won't hurt to 
find out.

	Datability Software Systems, Inc.
	322 Eighth Avenue
	New York, NY 10001
	(212) 807-7800
	Ron Howard, Pres. (is on the network:  ron.howard@doc.dss.com)

	Infotron  				Infotron Systems Europe
	509 Madison Avenue          		Excelsiorlaan, 51
	New York, NY 10022  			1930 Zaventem, Belgium
	(212) 223-6430				(32) (2) 725-0770

Hope this helps.
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 90 05:31:18 GMT
From:      henry.jpl.nasa.gov!elroy.jpl.nasa.gov!suned1!efb@ames.arc.nasa.gov  (Everett F. Batey II)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  LOST on net 192.31.106, HELP
In article <8912312049.AA10859@sneezy.lanl.gov> cpw%sneezy@LANL.GOV (C. Philip Wood) writes:
>Please check the routing on 26.17.0.46.

The marina-del-rey-mb.ddn.mil gateway apparently has bee out of service for
several weeks .. under repair .. WE LEARNED a NEW GOTCHA to watch for.

Thanks to Phil Wood of LANL and Ron Broersma of NOSC.

-- 
   efb@suned1.UUCP efbatey@suned1.nswses.Navy.MIL efb@elroy.JPL.Nasa.Gov 
           Gold Coast Sun Local User Group | Vta-SB-SLO DECUS
      Statements, Opinions ... MINE ... NOT those of my US Employer  
-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 90 08:03:10 GMT
From:      fox!portal!cup.portal.com!thinman@apple.com  (Lance C Norskog)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Is there slip for 386/ix?
Streamlined Networks' TCP/IP product for Interactive 386/ix includes
SL/IP support.  The SL/IP driver pair grabs on to an existing serial
line, so you can configure an account to pop into SL/IP mode
when you log in.  The driver has been tested with the base serial
ports and several third-party multi-port cards.

If you send your postal address, I'll send you our literature.

Lance Norskog
Sales Engineer
Streamlined Networks
thinman@cup.portal.com
1-415-659-1450
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 90 11:16:35 GMT
From:      zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!krol@tut.cis.ohio-state.edu  (Ed Krol)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: How is TCP/IP carried on T1's?
jst@cca.ucsf.edu (Joe Stong) writes:

>Someone I know claims that most TCP/IP packets transmitted on T1 lines are
>imbedded in X.25 protocol packets.  Is this true, or what is actually
>used?   Or it TCP/IP alone with maybe an alternate checksum (CRC) sufficient?

>      Joe Stong     jst@cca.ucsf.edu

Not having counted packets much lately, but I would bet that most
IP packets on T1 lines are imbedded in HDLC packets.
Since that is what a lot of commercial routers use on their serial lines.
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 90 14:05:48 GMT
From:      mcsun!cernvax!chx400!cgch!news@uunet.uu.net  (Armin Schweizer)
To:        tcp-ip@nic.ddn.mil
Subject:   SNMP product overview (RFC)


during our SNMP (and CMOT) discussion in this newsgroup last year,
we were informed, that a RFC will be published in december 1989
containing an overview on the SNMP products suppliers. Has this
special RFC been published? which is his number? where and how
is it available?

thank you
armin


       Armin R. Schweizer, CIBA-GEIGY AG, R1045.P.06, WRZ
                  4002 Basel / Switzerland
	          phone: -41-61-697'79'46
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 90 15:10:08 GMT
From:      zaphod.mps.ohio-state.edu!uwm.edu!lakesys!deanr@tut.cis.ohio-state.edu  (Dean Roth)
To:        tcp-ip@nic.ddn.mil
Subject:   VMS & TCP/IP

My company has been asked to port its communications
software to VMS.  The software consists of client and
server software, uses BSD socket interface and was
designed for UNIX and MS-DOS. The software does not perform
any disk or terminal I/O - that is left to the application developer. 
Since I have next to no VMS experience,
I need your advice.  (Please email directly to me.)


I have DEC's "Network and Communications Buyer's Guide".
The guide lists three TCP/IP products for VMS: 

	Fusion TCP/IP
	WIN/TCP
	TCP/IP


Questions:
---------
In general, what is your experience with these products
for writing interprocess communications software?  I do not care about
file transfer (ftp), email or virtual terminal support.

What about installation and support? 

Only WIN/TCP is indicated to be compatible with BSD 4.3 UNIX.
I'm not sure what that means.  Perhaps it means it has
the same C function (socket) interface?

How easily can I port the UNIX software?
Is it (almost) a matter of recompiling?

The server software creates a new process to
handle each connection.  Is this a "problem"
under VMS?  (One party told me it is too
inefficient. Another party said, "No problem".)


Thank you for your help.

Dean
deanr@lakesys.lakesys.com
-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 90 16:33:36 GMT
From:      cs.utexas.edu!samsung!aplcen!haven!grebyn!schultz@tut.cis.ohio-state.edu  (Ronald)
To:        tcp-ip@nic.ddn.mil
Subject:   Network Planning Tool

I am looking for any products that assist in the planning and
integration of computer networks.  We are looking for, in
particular, an environment that provides for the presenting,
review, selection, and evaluation of different kinds of networks
based on a set of supplied requirements.

For example, if the requirement is to interconnect 10 PCs and
provide file transfer and E-Mail, the environment should propose
a number of conceptual frameworks that I could explore.  These
may be:

   o     Peer to Peer
   o     Client-Server
   o     SubLan
   o     Others as deemed appropriate

I should then be allowed to explore each presented framework to
see what basic services each supplies, and how they represent
different things such as mail, files, a connection, ...  The
environment should also provide a means of intersecting different
frameworks to identify differences between frameworks.

The specifying of additional requirements should result in the
narrowing of conceptual frameworks presented.  

As frameworks are explored, additional information should be made
available to assist me in selecting an appropriate configuration. 
Also, assistance shoud be provided if I have to migrate from one
framework (say TCP-IP) to OSI.  

Does anyone know of any such product/environment ?  Is anyone
working in this area ?  Also, what common denominator does one
use in evaluating different networks ?  For example, SNA, TCP-
IP, and OSI all have a different definition of the object 'file'. 
How can one reconcile these differences ?

I will post any received information back to the net.  Thanx in
advance.

Ron Schultz
schultz@grebyn.com
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 90 17:37:59 GMT
From:      ginger.acc.com!salt.acc.com!lars@ucbvax.Berkeley.EDU  (Lars J Poulsen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: VMS & TCP/IP
In article <1512@lakesys.lakesys.com>
   deanr@lakesys.lakesys.com (Dean Roth) writes:
>My company has been asked to port its communications
>software to VMS.  The software consists of client and
>server software, uses BSD socket interface and was
>designed for UNIX and MS-DOS. The software does not perform
>any disk or terminal I/O - that is left to the application developer.

Eh ? If this is not application software, what is it ?
With a socket library, the application programs are usually clients and
servers. If your software does not do that, what exactly does it do ?
You see, it may be performing a function that is already provided in the
TCP/IP packages that you would be interfacing to.

>Since I have next to no VMS experience,
>I need your advice.  (Please email directly to me.)

The issues might be generic enough to warrant sharing, so I am posting.

>I have DEC's "Network and Communications Buyer's Guide".
>The guide lists three TCP/IP products for VMS: 
>	Fusion TCP/IP
		By Network Research Corporation in Oxnard, CA
>	WIN/TCP
		By the Wollongong Group, Palo Alto, CA
>	TCP/IP
		???? Are you talking about the soon-to-condense
		vaporware VMS/Ultrix connection by DEC ????
Not mentioned:
	CMU's Public Domain TCP/IP
	MultiNet by TGV/SRI
	OpenLink by Network Solutions

Since I work for a company that supplies network interface hardware for
use with all of these, I should not comment on which of these are better
than which, just ask just to shop around, and compare prices and
features. Some of them are bare-bones, others are very complete. Some
are obvious ports of Unix systems, using dash-options, others are
completely VMS-ified with VMSINSTAL distribution kits, DCL commands and
built-in help files. Some of them have everything in a humongous,
loadable device driver for the clonable INET pseudodevice, others have
protocol layers in separate ACP processes.

>Questions:
>---------
>In general, what is your experience with these products
>for writing interprocess communications software?  I do not care about
>file transfer (ftp), email or virtual terminal support.

I think you mean you want to open a VMS "channel" to a TCP connection.
All of them can do that (with the possible exception of VMS/Ultrix
connection which has been described as NFS only). The documentation on
how to do it, is usually very, very poor, but once you figure it out
it's trivial, and very very robust (just like BSD unix).

>What about installation and support? 

A mixed bag. Ask pointed questions of the vendors, and ask for
references. Then call those sites.

>Only WIN/TCP is indicated to be compatible with BSD 4.3 UNIX.
>I'm not sure what that means.  Perhaps it means it has
>the same C function (socket) interface?

WIN/TCP and MultiNet are direct ports of the entire communications
portion of 4.3BSD into a loadable VMS driver. The link devices are NOT
configured to VMS, instead a UNIX driver is included in the network
kernel. A run-time library is supplied, which completely emulates 4.3BSD
functionality: You use normal SOCKET, ACCEPT, BIND, SEND and RECEIVE
calls, and they work like you'd expect. (Underneath, of course, these are
translated into SYS$QIO calls).

>How easily can I port the UNIX software?
>Is it (almost) a matter of recompiling?

Yes. The biggest problem is usually that VMS want an exit status of 1
for success, while Unix programs return 0 for success and ERRNO for
error.

>The server software creates a new process to
>handle each connection.  Is this a "problem"
>under VMS?  (One party told me it is too
>inefficient. Another party said, "No problem".)

In UNIX, process creation is dirt cheap, and newly created processes are
clones of the parent, inheriting all open file descriptors etc.
In VMS, process creation is expensive, and a newly created process
contains a virgin program load from a file, with newly opened input and
output files. In UNIX terms: You CANNOT do a FORK, but only a FORK/EXEC
combo. No amount of runtime libraries can cover up this basic design
difference completely.

In several of the above packages are included generalized network
servers similar to the INETD package of 4BSD. The normal way to write a
server is to write it a normal program that reads from SYS$INPUT and
writes to SYS$OUTPUT. When an incoming connection spawns a server
program, it comes up with input and output connected to the TCP
connection. So there is no special programming required to do servers.

But as I said, each package is different, and you need to ask the right
questions. If you don't know VMS, you are not qualified to make the
selection.
--
/ Lars Poulsen <lars@salt.acc.com>   (800) 222-7308  or (805) 963-9431 ext 358
  ACC Customer Service              Affiliation stated for identification only
                My employer probably would not agree if he knew what I said !!
-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 90 19:20:37 GMT
From:      pollux!ccruss@ucdavis.ucdavis.edu  (Russ Hobby)
To:        tcp-ip@nic.ddn.mil
Subject:   Network Applications
Hi gang,

Some of the discussion on why FAX is popular and Email is not, has been
similar to some thoughts that I have had on network applications in
general. What is it that will make networks usable by the masses? Good
connectivity and easy to use applications that can talk across the
network to everyone else's applications.

FAX has the connectivity through the telephone system. The Internet is
growing but it doesn't go everywhere the phones do!  So when will will
common carriers put network connections everywhere?  When there are
useful, easy to use applications that people want to use on the network
and are willing to pay for.

So lets look at the applications. Below are some of my thoughts on some
applications. I am looking for comments on these and others that you have
any ideas about. Think about not just what we need in the educational and
research environment, but also what everyone would like in their home and
business. 

Thanks,

Russ Hobby                              INTERNET: rdhobby@ucdavis.edu  
IETF Area Director - Applications       BITNET:   RDHOBBY@UCDAVIS  
                                        UUCP:  ...!ucbvax!ucdavis!rdhobby 

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

            Network Applications in Need of Standards

      The Internet  has grown to the point where a vast number of
      people have  access and  they are now asking "What do we do
      with it?".  Most TCP/IP implementations include three basic
      applications: remote  login (Telnet),   file transfer (FTP)
      and electronic  mail (SMTP).  These applications need to be
      looked at  to see if they meet todays need, but people want
      more!

      The  main   reason  for   TCP/IP's  success  has  been  its
      interoperability.   Now that  new  applications  are  being
      looked at (and in some cases developed), we need to provide
      standards  for   these  applications  to  insure  continued
      interoperability.   In the  telephone world,  the user does
      not care what is happening with the switching and circuits,
      he just wants to be able to talk to the person at the other
      end.  This also needs to be true with network applications.

      We already  see proprietary  network systems,  particularly
      with microcomputers, that can not talk to each other.  What
      we need  is agreed  upon standards at the network level for
      the applications,  and the  vendors  can  then  sell  their
      product because  their's is  the "best"  implementation and
      user interface.   Also, regardless of one's options on OSI,
      it will  happen at  some point  and TCP/IP  needs  to  work
      closely with the OSI groups to make sure that there will be
      interoperability at the application level.

      Here are  a few of the applications, old and new, that have
      produced some interest and questions.

Electronic Mail
    There  is   no  doubt  that  current  email  could  use  some
    improvements.  How can we include image information in email?
    What about  electronic signatures?  Is what we really need an
    electronic document  standard that  will include these issues
    and more?   How  is X.400  going to fit into or work with the
    TCP/IP world?

Network Printers
    Define a  standard method  of sending  printer  output  to  a
    printer connected to the network. Some items to consider are:
    1) Authentication/security/accounting
    2) Begin/end control of print job
    3)  Printing  modes  and  options  (postscript,  plain  text,
    page/line size, ....)
    4) Scheduling priorities

Network Backups
    Define a  standard method  of doing  disk backups  to a  mass
    storage system on the network.  This is becoming particularly
    important with  the increase  of PCs and workstations that do
    not have mass storage directly attached.

Distributed Network Bulletin Board System
    Define a Bulletin Board System such that various parts of the
    information base  can reside  on  different  computers.  This
    allows each  provider of  their information  to  provide  the
    maintenance and  computing resources  for that  part  of  the
    information base.  Also as the information base grows, rather
    than having  get a  bigger computer to handle the growth, you
    add more computers.
    
    One idea  currently being  looked at  UC Davis  is to use the
    USENET concept  and NNTP,  but use  the Domain Name System to
    specify which computer provides NNTP service for a particular
    newsgroup.

Distributed Network Calendar/Scheduling System
    Define a  system  such  that  one  computer  can  maintain  a
    calendar for  a group  of people/rooms/items,  but  can  also
    communicated with  calendars  on  other  computers  over  the
    network for scheduling.

Network FAX
    Define a  standard method  of sending  FAX information over a
    network.   If we  can get  email to include images, this need
    may decrease, but people what to do FAX now!

Network Interactive Conversations
    Define a  standard method  for interactive conversations over
    the network.   There are several programs that allow users to
    talk to  each other, but no standards for it.  UNIX "talk" is
    probably the closest to a defacto standard.

Network Database
    Define a standard method of interacting with databases over a
    network.

Directory Services
    What is  the best  way to  provide this  service? Whois? DNS?
    X.500?  We need an official way of doing it over TCP/IP.

More?
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 90 19:43:48 GMT
From:      ginger.acc.com!salt.acc.com!lars@ucbvax.Berkeley.EDU  (Lars J Poulsen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: VMS & TCP/IP
In article <1990Jan4.173759.5244@ginger.acc.com> I wrote:
>Not mentioned:
>	CMU's Public Domain TCP/IP

I was wrong !! In the words of Dale Moore from CMU:
> The CMU-TEK software is not Public Domain.  It is licensed software.
> The license is flexible, generous and inexpensive, but not Public Domain.

I am (really) grateful for the correction, which I hasten to pass on.

--
/ Lars Poulsen <lars@salt.acc.com>   (800) 222-7308  or (805) 963-9431 ext 358
  ACC Customer Service              Affiliation stated for identification only
                My employer probably would not agree if he knew what I said !!
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 90 20:08:16 GMT
From:      umabco!lwilson@cvl.umd.edu  (Lowell G. Wilson)
To:        tcp-ip@nic.ddn.mil
Subject:   E-Mail to MCIMail and CompuServe

Hello again.  Just a quick question about some of the commercial mail
gateways.  We're getting ready to set up a Listserver that will be
sending some mail to a few people with accounts on CompuServe and MCI
Mail.  In the future we may end up having to talk to a few people on
other commercial nets as well.  We have the Listserver software on our
mainframe and we have SMTP running there so getting to the Internet will
not be a problem.  With the Donnalyn Frey/Rick Adams e-mail book I have
the information I need to get mail to people on these two nets, so
that's not a problem either.  All I'm really wondering is if anyone has
had any trouble with these gateways and, if so, how'd you get around
them.  I figure a little advance notice can't hurt.  Thanks for any tips
anyone cares to offer...

-- 
Lowell Wilson : Sinecure III        University of Maryland at Baltimore    
                                    Information Resources Mgt Division     
                                    UUCP: ...cvl!umabco!lwilson            
                                    Internet: umabco!lwilson@cvl.umd.edu
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Thu, 04 Jan 90 20:14:51 +0000
From:      Julian Onions <j.onions%computer-science.nottingham.ac.uk@NSFnet-Relay.AC.UK>
To:        tcp-ip@nic.ddn.mil
Subject:   Host requirements and SMTP

I have just been upgrading an SMTP server/client to attempt to conform
to the HOST REQUIREMENTS RFC. Most of the stuff is fairly sensible and
lays down good practice. I have some comments on this generally though
and wondered if anyone else has attempted to conform to this
specification as yet?

Anyway, maybe someone can answer these questions or shed some light...


Section 5.2.3
This seems nonsensical, saying essentially you MUST implement
VRFY and SHOULD implement the EXPN commands, but both of these MAY be
disabled.
So to conform I can simply implement both these by replying with 
   252 Cannot VRFY User
and
   550 Access Denied to you
Just changing these from 
   500 Unknown of unimplemented command
seems pretty worthless
What benefit do you gain from making VRFY a MUST when its quite
acceptable to always answer "can't"?

Section 5.2.5
A question/comment - is HELO really required? I know of one implementation
that doesn't send HELO messages (MH) and the HR makes it clear that
you should mostly ignore the HELO stuff anyway.
The discussion about resolution of the HELO parameter is not that
essential anyway, to my mind what is more important is that you can
discover where the SMTP connection is coming from. I.e. if you can't
resolve the IP address back to a domain name then you probably should
not accept the mail because
	a) you don't know who is sending you the message really, so
	your chances of getting it back are limited if things blow up.
	b) You don't know who is really sending the message - from a
	security point of view. IP addresses can be forged but this is
	better than nothing - certainly better than implicitly
	believing the HELO.
Therefore I would argue all the authentication should have been done
before it gets to the HELO stage. A future HR should perhaps note that
you should attempt to discover where the message is coming from.

Section 5.2.8
Various things should be pushed into the Received line it notes, but I
don't see how this can be done. Firstly the from field should contain
both a source host and a domain literal of the IP address. Good - but
how, the grammer gives exactly one FROM per received line in rfc-822
in the format
	from domain
similarly there is only one FOR address allowed - perhaps a new grammer
should have been given here. Otherwise things like the RFC-822 ->
X.400 gateways that try and preserve trace are going to have problems
parsing these lines.

Section 5.2.14
New date format is good - but is this going to break existing systems
and implementations I wonder?

Section 5.2.17 
Urgghhhhh! This is awful. Making this a MUST is horrible. Domain
literals should be stamped out. Parsing a domain literal is ok,
getting the semantics right is yucky in the extreme, it should at the
maximum have been a MAY. Next thing we'll need to recognise our own
ethernet addresses in mail messages.  So to be conformant you HAVE to
be able to discover all your current IP addresses and to match on
them. Does this really have to be a MUST? How many current systems can
accept this syntax? I think this will be my biggest stumbling block to
conformance.

My ideal text for this section would have been "Domain literals are not
intended for address use, an Implementation MAY make use of them for
routing, and SHOULD NOT fail outright if one is detected.  Instead if
domain literals are not supported, the affected addresses may be
returned with a failure notice. Domain literals are only intended for
tracing purposes."

Domain literals together with source routing should be dropped.

Section  5.5.3
This says if you have a source route as the originator of the message
then an error message SHOULD throw away the route.
So if somewhere on the Internet I get an address allegedly from
	<Internet-Host:user@hidden-host>
where hidden-host is not directly contactable I must throw away the
Internet-host route part when sending an error. The most likely reason
for having a route in the originator is because the hidden host does
not yet have an entry in the DNS or an MX record for its domain, so
in that case there is no way to get back without the route.



I think these are the main things that hit me when trying to
conform to the HR. 

I would welcome comments.
Julian.
-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 90 20:19:44 GMT
From:      lectroid!cloud9!banyan!cora@CS.BU.EDU  (Cora Wong@Eng@Banyan)
To:        tcp-ip@nic.ddn.mil
Subject:   GATED and IP Multicast Support Source Code for 4.3/4.4BSD
I would like to get hold of the source code for both the GATED 
and the IP Multicast support on 4.3BSD.  Any information on who I
should contact in order to get them e-mail to me (I have no access
to the Internet) would be greatly appreciated.

Cora Wong
cora@banyan.banyan.com
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 90 20:49:16 GMT
From:      ncrlnk!ncrcce!cavanaug@uunet.uu.net  (John David Cavanaugh)
To:        tcp-ip@nic.ddn.mil
Subject:   What IGP Do You Use?
I'm considering the question of what interior gateway protocols
people use in their TCP/IP networks.  The ones I'm aware of are:

-    Hello
-    RIP
-    IGRP (from cisco)
-    OSPF

I'd appreciate it if you could take a minute to drop me an e-mail
message stating which you use in your current network.  If you plan
to change to a different one in the near future, I'd appreciate
knowing that, too.  If there's interest, I'll post a summary of the
responses.

Thanks in advance.

-- 
John Cavanaugh                       John.Cavanaugh@StPaul.NCR.COM
NCR Comten, Inc.                     (612) 638-2822
2700 Snelling Ave. N
St. Paul, MN  55113                  Standard disclaimer.
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 90 20:54:45 GMT
From:      ncrlnk!ncrcce!cavanaug@uunet.uu.net  (John David Cavanaugh)
To:        tcp-ip@nic.ddn.mil
Subject:   IGRP Specification
I know this was recently hashed over, and I apologize for bringing
it up again.

I need a copy of the specification for cisco's IGRP protocol.  I
understand that they're promoting this as a standard and are
making it publicly available.  My question is, where do I get a
copy?  A copy from a mail server would be best (I don't have FTP),
but a plain old paper copy would do.

Please respond by e-mail.  I'll post a summary if there's interest.

Thanks.

-- 
John Cavanaugh                       John.Cavanaugh@StPaul.NCR.COM
NCR Comten, Inc.                     (612) 638-2822
2700 Snelling Ave. N
St. Paul, MN  55113                  Standard disclaimer.
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      4 Jan 90 21:26:08 GMT
From:      bii!dple@uunet.uu.net  (david levine)
To:        tcp-ip@nic.ddn.mil
Subject:   Sources for TCPIP.
I would like to get some information on TCP/IP sources under MSDOS.
I have the sources that were released by Berkley but we are thinking
of implementing it on a system that has an OS that is more like MSDOS.

If anyone has any such information, please send it to me and I will
post the results.


David Levine

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

	
     ...         ...
    .    .     .    .	David Levine
    .     *   .     .	Software Engineer
     .      .      .
      .   .   .   .	Bruker Instruments Inc. USA
       . BRUKER .	Billerica, MA. 01821
      .   .   .  .
     .      .     .	
    .     *  .     .	dple@bii.bruker.com		Internet
     ...        ...     ...!{uunet,ulowell}!bii!dple	UUCP

=================================================================
-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Fri, 05 Jan 90 08:35:35 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        j.onions@computer-science.nottingham.ac.uk
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: Host requirements and SMTP

Julian:
    
    Let me see if I can answer some of your questions.

> Section 5.2.3
> This seems nonsensical, saying essentially you MUST implement
> VRFY and SHOULD implement the EXPN commands, but both of these MAY be
> disabled.
> So to conform I can simply implement both these by replying with 
>    252 Cannot VRFY User
> and
>    550 Access Denied to you
> Just changing these from 
>    500 Unknown of unimplemented command
> seems pretty worthless
> What benefit do you gain from making VRFY a MUST when its quite
> acceptable to always answer "can't"?

Let me just clarify the text here.  It says MUST implement and MAY
provide the facility to allow users to turn them off.

The reason was that, in general, EXPN and VRFY are useful tools for
tracking problems in mail-lists expansions.  However, EXPN and VRFY
are also viewed by some members of the community as a violation of
privacy (Why should someone be able to find out whether I'm on mailing
list X?  Or why should someone be able to find out who is on my
personal mail-lists?).  Furthermore, both commands are minor security risks --
since mailbox names often are the same as account names.  So we state
that it is reasonable for users to ask for mail software in which they
can turn off EXPN and VRFY.

> Section 5.2.5

I don't know what to say here.  HELO is part of the protocol, so yes
you ought to do it.  That said, yes, it doesn't do much.

> Section 5.2.8
> Various things should be pushed into the Received line it notes, but I
> don't see how this can be done. Firstly the from field should contain
> both a source host and a domain literal of the IP address. Good - but
> how, the grammer gives exactly one FROM per received line in rfc-822
> in the format
> 	from domain
> similarly there is only one FOR address allowed - perhaps a new grammer
> should have been given here. Otherwise things like the RFC-822 ->
> X.400 gateways that try and preserve trace are going to have problems
> parsing these lines.

I believe you are right and we goofed here.

> Section 5.2.17 
> Urgghhhhh! This is awful. Making this a MUST is horrible. Domain
> literals should be stamped out. Parsing a domain literal is ok,
> getting the semantics right is yucky in the extreme, it should at the
> maximum have been a MAY.

> <some text deleted...>
> 
> My ideal text for this section would have been "Domain literals are not
> intended for address use, an Implementation MAY make use of them for
> routing, and SHOULD NOT fail outright if one is detected.
> <more text deleted...>

Gee -- that's what we tried to do, only a bit more forcefully.  Domain
literals may show up, your mailer must not barf on them, and if the
domain literal = your host, your mailer ought to accept it.  In other
words, God help us, should you get a domain literal, do the minimum
rational thing -- don't fail, and swallow it if it is for you.

> Section  5.5.3
> This says if you have a source route as the originator of the message
> then an error message SHOULD throw away the route.
> So if somewhere on the Internet I get an address allegedly from
> 	<Internet-Host:user@hidden-host>
> where hidden-host is not directly contactable I must throw away the
> Internet-host route part when sending an error. The most likely reason
> for having a route in the originator is because the hidden host does
> not yet have an entry in the DNS or an MX record for its domain, so
> in that case there is no way to get back without the route.

This isn't what were saying.  What we were saying is there is good
reason in the envelope to track how the mail has proceeded -- the
typical way to do this is source routes (@A,@B:user@C) where user@C
is the originating system.  Now there's no point in replying via
all the intermediate hops -- and now that source routes are
discouraged, it may not even fly.  So just strip down to user@C.
In the case you cite, I'd argue the gateway should have sent stuff
out as user%hidden@host, which would then become @A,@B:user%hidden@host,
and you'd reply to user%hidden@host.

Craig
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 90 01:15:20 GMT
From:      ginger.acc.com!salt.acc.com!mason@ucbvax.Berkeley.EDU  (Bill Mason)
To:        tcp-ip@nic.ddn.mil
Subject:   Test Site for VAXBI X.25 device under ULTRIX

ACC is looking for a test site for the ACP 7250 (BI X.25 device) on a
VAXBI machine that is running ULTRIX. We would like testing to begin
around the end of January 1990.

The ACP 7250 is ACC's new X.25 front-end for VAXBI machines. It uses a
single VAXBI slot, and has the X.25 protocol resident in on-board firmware.
The ULTRIX device driver links into the networking kernel for support of
the TCP/IP stack over an X.25 network.

For anyone familiar with ACC's products, the ACP 7250 functions in the same
manner as the ACP 5250 (Q-bus) and ACP 6250 (UNIBUS) X.25 controllers that 
have been available for several years. The ACP 7250 can be thought of as the
BI version of these products.

Any interested parties should contact Bill Mason at (805) 963-9431, or
by FAX at (805) 962-8499, or by return mail to mason@salt.acc.com.

Thanks for your interest!

ACC

Bill Mason
-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Fri, 05 Jan 90 10:12:54 -0500
From:      gated-people-request@devvax.tn.cornell.edu
To:        lectroid!cloud9!banyan!cora@cs.bu.edu (Cora Wong@Eng@Banyan)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: GATED and IP Multicast Support Source Code for 4.3/4.4BSD
Gated is available via e-mail from the archive server,
gated-people-archive@devvax.tn.cornell.edu.  Send e-mail with a subject
line of "help" for more information.  Gated is available for annonymous
FTP from devvax.tn.cornell.edu in pub/gated/gated.tar.Z.  If you would
like to be on the gated mailing list, send a request to
gated-people-request@devvax.tn.cornell.edu. 

Jeff
-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      Fri, 05 Jan 90 09:57 PST
From:      Michael Stein                        <CSYSMAS@OAC.UCLA.EDU>
To:        tcp-ip@NIC.DDN.MIL
Cc:        Julian Onions <j.onions@COMPUTER-SCIENCE.NOTTINGHAM.AC.UK>     T-RELAY.
Subject:   Re: Host requirements and SMTP
> Section 5.2.5
> The discussion about resolution of the HELO parameter is not that
> essential anyway, to my mind what is more important is that you can
> discover where the SMTP connection is coming from.  I.e. if you
> can't resolve the IP address back to a domain name then you
> probably should not accept the mail because

HRRFC 5.2.5 says "However, the receiver MUST NOT refuse to accept
a message, even if the sender's HELO command fails verification."

I can't see how that could be clearer -- LET THE MAIL GO THROUGH.

I also remember (from one of the domain RFCs?) that the prefered
way to "check" the HELO name is to do a forward DNS lookup on the
supplied name and see if one of the A records contains the IP
address for this SMTP connection.  This is in preference to the
reverse lookup (IP address to domain name using IN-ADDR.ARPA).

In my opinion the forward lookup sounds much more reliable than
the reverse, however they both sound like they take too long for
a "high performance SMTP implementation".

>        a) you don't know who is sending you the message really, so
>        your chances of getting it back are limited if things blow up.
>        b) You don't know who is really sending the message - from a
>        security point of view. IP addresses can be forged but this is
>        better than nothing - certainly better than implicitly
>        believing the HELO.
> Therefore I would argue all the authentication should have been done
> before it gets to the HELO stage. A future HR should perhaps note that
> you should attempt to discover where the message is coming from.

There isn't any way to do this in SMTP.  All you have is the
domain name (claimed) and the IP address (also claimed).  You
don't know who sent the "bits" or if they have been modified.  If
you really need authentication see the RFCs on privacy
enhancements for electronic mail (RFC1113-1115).
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Jan 90 11:49:54 PST
From:      braden@venera.isi.edu
To:        j.onions%computer-science.nottingham.ac.uk@nsfnet-relay.ac.uk, tcp-ip@nic.ddn.mil
Cc:        braden@venera.isi.edu
Subject:   Re:  Host requirements and SMTP
Julian,

Thanks for your comments.

	Section 5.2.3
	This seems nonsensical, saying essentially you MUST implement
	VRFY and SHOULD implement the EXPN commands, but both of these MAY be
	disabled.
	So to conform I can simply implement both these by replying with 
	   252 Cannot VRFY User
	and
	   550 Access Denied to you
	   
According to the intent of the HR WG, this would NOT satisfy the requirement
for implementation.  To implement the command, your code must include the
necessary algorithms and data structures which, if enabled by a particular
site administrator, would actually perform the intended function.
Note that the HR RFCs generally specify what must be present in the code, 
regardless of how particular sites choose to configure their systems.

	Section 5.2.5
	A question/comment - is HELO really required? I know of one implementation
	that doesn't send HELO messages (MH) and the HR makes it clear that
	you should mostly ignore the HELO stuff anyway.
	
Except as specifically mentioned in the HR RFC, all parts of RFC-821
are required.  Sending HELO is part of the SMTP protocol (see Section
3.5and all the examples of RFC-821); although the WG never discussed this
point (discussion would have been gratuitous), I think I can state with
certainty that sending HELO is required.

	The discussion about resolution of the HELO parameter is not that
	essential anyway, to my mind what is more important is that you can
	discover where the SMTP connection is coming from. I.e. if you can't
	resolve the IP address back to a domain name then you probably should
	not accept the mail because
		a) you don't know who is sending you the message really, so
		your chances of getting it back are limited if things blow up.
		b) You don't know who is really sending the message - from a
		security point of view. IP addresses can be forged but this is
		better than nothing - certainly better than implicitly
		believing the HELO.
		
The limitations of HELO validation and IP addresses for hard-core 
authentication are very well known.  However, there is a lot of experience
in which HELO parameters have been useful for diagnosing mail delivery
problems.

	Therefore I would argue all the authentication should have been done
	before it gets to the HELO stage. A future HR should perhaps note that
	you should attempt to discover where the message is coming from.

The requirement in Section 5.2.8 to include the IP source address in the
Received: line is intended to do exactly that.  It was felt that both
pieces of information are useful for diagnosis.

	Various things should be pushed into the Received line it notes, but I
	don't see how this can be done. Firstly the from field should contain
	both a source host and a domain literal of the IP address. Good - but
	how, the grammer gives exactly one FROM per received line in rfc-822
	in the format
		from domain
	similarly there is only one FOR address allowed - perhaps a new grammer
	should have been given here. 
	
Some argued for this, but the WG decided that this should be left to
a future revision.  Many (but not all) WG members felt that the intent of the
Received: line is to provide trace information for humans, so that a
precise syntax is not a very important.  Here's a suggestion: put the domain
literal after the host domain name, with one or more blanks separating the two.

    Otherwise things like the RFC-822 ->
	X.400 gateways that try and preserve trace are going to have problems
	parsing these lines.

Gateways are specifically prohibited from modifying modifying Received:
lines! (Section 5.3.7 (B)).  So they don't need to, and should not try,
to parse these lines.

	Section 5.2.14
	New date format is good - but is this going to break existing systems
	and implementations I wonder?

The WG felt that we have a choice of breaking things gradually over the
next 10 years or all at once on 12/31/99, and preferred the former.  One
could argue that, I suppose.

 	Section 5.2.17 
	Urgghhhhh! This is awful. Making this a MUST is horrible. Domain
	literals should be stamped out. 
	
The WG felt that domain literals are an important escape mechanism for
users when the DNS is screwed up: a user-helpful feature.  Implementation does
not seem to me to be that big a deal compared with the overall 821/822
implementation job.

Again, we appreciate your comments, and they will be saved for the lucky
people who get to revise the HR RFC.

Bob Braden

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 90 07:37:02 GMT
From:      zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!labtam!enno@tut.cis.ohio-state.edu  (Enno Davids)
To:        tcp-ip@nic.ddn.mil
Subject:   BOOTP server identification

I am about to add to the abilities of the BOOTP daemon code that we
are using around here. The specific characteristic I am interested in is
to allow the daemon to specify some host other than itself as the server
to boot from when replying to a bootp request.

Specifically, I intend to add a new keyword (e.g. sr) to the bootp database
reader and allow any machine entry to have ... :sr=nn.nn.nn.nn: ... as one
of it's fields. For reference, the code I am using came from uunet's public
area and has since seen modification for SysV.

My questions are:
    - has anybody else done this already?
    - is 'sr' a reasonable choice (if not, why not).
    - other observations or comments.


Enno.


--------
Enno Davids.				Labtam Information Systems P/L.
enno@labtam.oz.au			43 Malcolm Rd.
					Braeside, 3195
Voice: + 61 3 587 1444			Australia.
Fax:   + 61 3 580 5581

"Wasn't it Sartre who said, 'Hell is to be locked in a small room with all your
friends for eternity.' Of course, all Sartre's friends were French." - Red Dwarf
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Fri, 05 Jan 90 16:40:07 -0500
From:      Jeffrey C Honig <jch@risci.TN.CORNELL.EDU>
To:        tcp-ip@nic.ddn.mil, ietf-interest@venera.isi.edu, vmtp-ip@gregorio.stanford.edu
Subject:   IP Multicasting in SunOS
Below is a copy of the RFE (Request for Enhancement) I submitted to
Sun asking them to support IP Multicasting.  I'd like to encourage
other people to do the same, and not just with Sun, but with other
vendors too.  For most BSD 4.3 based systems the code is already
available so implementation should not be too difficult from a
technical aspect.  The hard part is convincing them that we want it.

Jeff


The purpose of this RFE is to request that SunOS support IP multicast
communications and Internet Group Management Protocol (IGMP) as soon
as possible.

IP Multicasting and IGMP, as defined in [RFC1112], are both
"recommended standard" internet protocols for use in the DARPA
Internet.  IP Multicasting is listed as a feature that "SHOULD" be
implemented and IGMP is a listed as a feature that "MAY" be
implemented in [RFC1122].

Whenever multicast capability has been made available on local area
networks, applications which exploited and benefited from it have
rapidly evolved.  Since the Internet is moving toward an environment of
high-speed circuits, and high-performance hosts, we can expect an
increasing demand for real-time interactive and transaction-style
applications not just on local networks but across the nation.

IP multicasting provides many benefits.  On the local network level it
reduces the amount of broadcast traffic a host must process.  A host
need only subscribe to the multicast groups it desires.  On a regional
and national level multicasting will reduce the amount of traffic
required to "flood" information to distributed applications in the
internet.

One protocol to support wide-area multicasting already exists, more
sophisticated ones are under currently under development, support is
already committed by some major router vendors.  Widely available
support for IP multicasting in SunOS would greatly benefit this
development.

One major use for IP multicasting is the Open Shortest Path First
(OSPF) designed by the IETF and submitted as a "proposed protocol" for
Internet routing.  OSPF is a much more robust interior routing
protocol than RIP and is a major candidate to be the "recommended
standard" interior routing protocol for the Internet.  OSPF was
designed to use IP multicasting instead of IP broadcasting to reduce
the broadcast traffic that must be handled by non-participating hosts.

Suns are the Unix system of choice for use as high speed routers.
Their ability to support IP multicasting and hence OSPF will be
crucial in their continuing to be so.  The Internet of the near future
will not be able to survive without a more robust interior routing
protocol than RIP.

Sun has proven itself to be a leader in workstation field, especially
in wide-spread use of networking.  Implementation of IP multicasting
would help maintain this leadership.


RFC1112:
	Deering, S. "Host Extensions for IP Multicasting".  August,
	1989. 

RFC1122
	Internet Engineering Task Force. "Requirements for Internet
	Hosts -- Communication Layers".  October 1989.

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Fri, 5 Jan 90 13:53:13 EST
From:      barns@gateway.mitre.org
To:        j.onions%computer-science.nottingham.ac.uk@NSFnet-Relay.AC.UK, tcp-ip@nic.ddn.mil
Subject:   Re:  Host requirements and SMTP
If I don't answer this, Rayan Zachariassen probably will, and I like my
version better...  (Rayan is a good sort really, but we did have a lot of
interesting or tedious discussions during the editing of this part of
HR.)  Most of these issues involve unprovable propositions - I for one will
concede that in advance.  Herewith my recollections and comments:

	Section 5.2.3
	So to conform I can simply implement both these by replying with 
	   252 Cannot VRFY User
	and
	   550 Access Denied to you
	Just changing these from 
	   500 Unknown of unimplemented command
	seems pretty worthless
	What benefit do you gain from making VRFY a MUST when its quite
	acceptable to always answer "can't"?

A trivial answer to this is, "if you choose to implement something in
the stupidest way you shouldn't be surprised if the product is worthless."
The hoped-for result here was: Almost all SMTP implementations ought to
be capable of doing real EXPN and VRFY service for some set of cases.
Many will find it unduly costly or infeasible for some other set of cases.
Finally, there may be security or policy reasons why it is desired not
to make certain names visible in this way.  This might be all of the names
at a site or only a few.  So the intent here is to tell the developer to
produce the code with the ability to do the functions in the cases where
it is technically reasonable, and let the user/purchaser decide what
additional restrictions to apply.
	
	Section 5.2.5
	A question/comment - is HELO really required? [...]

As an abstract question, this has no provable answer.  As a matter of
protocol definition, it is required.  People's sentiments vary, but
the implication of what was ultimately specified is something like this:

The HELO command is there so the server will have an identity assertion
about the client process.  It is not intended to be a real
authentication procedure.  Strong authentication, or even "halfway"
authentication, takes more work and not everyone thinks the effort is
justified.  Some people (including me) feel that receipt of mail (in
the normal workaday world - not talking about multilevel secure
systems, electronic funds transfer or other specific needs) should not
be conditioned on any type of authentication - you take anything that
shows up at the door, and then assess its worth after you read it if
you still care.

Converting the IP address back to a host name requires sending more
traffic and doing more overhead work.  Opinions vary on whether it is
worth it.  There's also the practical problem that the IP-address
part of the domain tree seems to have more screwups in it.  HR dodges
all of these concerns by saying "invert the IP address if you wish but
don't throw away the mail because of anything that happens - instead
tell the recipient and let the recipient decide".
	
	Section 5.2.8
	Various things should be pushed into the Received line it notes, but I
	don't see how this can be done. [...]

Most of the miscellaneous things were envisioned as syntactic comments,
which are permitted by the RFC822 syntax rules.  For example:
   Received: from ALLEGED.DOMAIN ([11.22.33.44]) by MY.DOMAIN [etc.]
The question of the syntax of the FOR was brought up by Rayan
Zachariassen during the editing (as I am sure we will be justly
reminded).  I suppose there was some feeling that in view of the
attitude expressed in the second chunk of DISCUSSION in section 5.2.8
("Received: lines are primarily intended for humans...") that it wasn't
too important to make this concrete.  Syntaxes discussed for the
contents of the FOR included 1#mailbox, 1#route-addr, and 1#(addr-spec
/ route-addr) with the last given being the last one discussed
(according to my files).  I think that 1#mailbox covers the other
cases, so if I wanted to parse it today, I'd use 1#mailbox until it
broke.

	Section 5.2.14
	New date format is good - but is this going to break existing systems
	and implementations I wonder?

RFC733, the predecessor of 822, allowed four digit years.  I thought it
was strange that it was taken out in 822, but in those days I wasn't
involved in the writing of these things.  I know there was a feeling
that 733 allowed an excessive number of date formats for no particular
reason.  I suppose "they" overreacted slightly when updating it (in
822).  I hope and believe we are converging on sanity at least in this
one area.

	Section 5.2.17 
	Urgghhhhh! This is awful. Making this a MUST is horrible. Domain
	literals should be stamped out. Parsing a domain literal is ok,
	getting the semantics right is yucky in the extreme, it should at the
	maximum have been a MAY [...]

Having had misadventures with DNS, I'm a believer in this provision as
an escape mechanism when the DNS misbehaves and you really need to talk
to someone.  Given this rule, hosts A and B can manage to talk despite
any DNS screwups on C.  I don't really understand why this is hard.
True, it's one more thing to code.  I don't see huge semantic problems
at least when the domain literal is a dotted-decimal IP address, which
is the only case actually addressed in HR (which is about *Internet*
hosts).  It is slightly ugly that one ought to cope with [11.22.33.44]
and [011.022.033.044] being equivalent, but this can be handled by
converting to the 32-bit number.  The code may be a little disgusting,
but it shouldn't have to be lovingly optimized since it shouldn't be
used very often.  If you were thinking that you have to canonicalize it
(rewrite the header or some such), you don't - read section 5.2.2
closely; it legitimizes allowing domain literals to pass unaltered.

	Section  5.5.3
	This says if you have a source route as the originator of the message
	then an error message SHOULD throw away the route. [...]

The philosophy arrived at by a combination of discussion and decree was
something like:  We wish explicit source routes within the Internet had
never been defined.  Since this unfortunate decision was made and many
people implemented it, we will put in enough requirements so that mail
items using them won't be rejected by anyone as illegal, but we will do
everything possible to keep any more such mail items from being
created.

Note that this doesn't refer to "%-hack" or the like.  The
left-hand-side is a local matter relative to the specified
right-hand-side.  (This is just about the only aspect of this touchy
topic on which I tend to wax religious.)

So, the "blessed" answer to the scenario you describe is for the
original sender to use %-hacks or the like on the LHS with the
cooperation of some Internet-registered domain, or perhaps use domain
literals for a very short time, but eventually get MX's or full DNS
connectivity.

Incidentally, Jon Postel "decreed" years ago that it was always
intended that all domain names appearing on the Internet, including
those in source routes, are supposed to be Internet-registered names.
Under that dictum, the case you describe as most common should never
have been allowed to occur, with or without the HR RFCs.  (As all
sensible people know, the real world doesn't always follow the rules.
The point is just that any variations were unsanctioned by the Powers
That Be.)

The topic of explicit mail source routes is exceedingly controversial
and generated about 20-25% of the total volume of discussion that led
to these RFCs.  It has been like this for years.  Groan.

Bill Barns
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 90 13:35:35 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Host requirements and SMTP


Julian:
    
    Let me see if I can answer some of your questions.

> Section 5.2.3
> This seems nonsensical, saying essentially you MUST implement
> VRFY and SHOULD implement the EXPN commands, but both of these MAY be
> disabled.
> So to conform I can simply implement both these by replying with 
>    252 Cannot VRFY User
> and
>    550 Access Denied to you
> Just changing these from 
>    500 Unknown of unimplemented command
> seems pretty worthless
> What benefit do you gain from making VRFY a MUST when its quite
> acceptable to always answer "can't"?

Let me just clarify the text here.  It says MUST implement and MAY
provide the facility to allow users to turn them off.

The reason was that, in general, EXPN and VRFY are useful tools for
tracking problems in mail-lists expansions.  However, EXPN and VRFY
are also viewed by some members of the community as a violation of
privacy (Why should someone be able to find out whether I'm on mailing
list X?  Or why should someone be able to find out who is on my
personal mail-lists?).  Furthermore, both commands are minor security risks --
since mailbox names often are the same as account names.  So we state
that it is reasonable for users to ask for mail software in which they
can turn off EXPN and VRFY.

> Section 5.2.5

I don't know what to say here.  HELO is part of the protocol, so yes
you ought to do it.  That said, yes, it doesn't do much.

> Section 5.2.8
> Various things should be pushed into the Received line it notes, but I
> don't see how this can be done. Firstly the from field should contain
> both a source host and a domain literal of the IP address. Good - but
> how, the grammer gives exactly one FROM per received line in rfc-822
> in the format
> 	from domain
> similarly there is only one FOR address allowed - perhaps a new grammer
> should have been given here. Otherwise things like the RFC-822 ->
> X.400 gateways that try and preserve trace are going to have problems
> parsing these lines.

I believe you are right and we goofed here.

> Section 5.2.17 
> Urgghhhhh! This is awful. Making this a MUST is horrible. Domain
> literals should be stamped out. Parsing a domain literal is ok,
> getting the semantics right is yucky in the extreme, it should at the
> maximum have been a MAY.
 
> <some text deleted...>
> 
> My ideal text for this section would have been "Domain literals are not
> intended for address use, an Implementation MAY make use of them for
> routing, and SHOULD NOT fail outright if one is detected.
> <more text deleted...>

Gee -- that's what we tried to do, only a bit more forcefully.  Domain
literals may show up, your mailer must not barf on them, and if the
domain literal = your host, your mailer ought to accept it.  In other
words, God help us, should you get a domain literal, do the minimum
rational thing -- don't fail, and swallow it if it is for you.

> Section  5.5.3
> This says if you have a source route as the originator of the message
> then an error message SHOULD throw away the route.
> So if somewhere on the Internet I get an address allegedly from
> 	<Internet-Host:user@hidden-host>
> where hidden-host is not directly contactable I must throw away the
> Internet-host route part when sending an error. The most likely reason
> for having a route in the originator is because the hidden host does
> not yet have an entry in the DNS or an MX record for its domain, so
> in that case there is no way to get back without the route.

This isn't what were saying.  What we were saying is there is good
reason in the envelope to track how the mail has proceeded -- the
typical way to do this is source routes (@A,@B:user@C) where user@C
is the originating system.  Now there's no point in replying via
all the intermediate hops -- and now that source routes are
discouraged, it may not even fly.  So just strip down to user@C.
In the case you cite, I'd argue the gateway should have sent stuff
out as user%hidden@host, which would then become @A,@B:user%hidden@host,
and you'd reply to user%hidden@host.

Craig

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Fri, 05 Jan 90 14:40:27 +0000
From:      Julian Onions <j.onions%computer-science.nottingham.ac.uk@NSFnet-Relay.AC.UK>
To:        Craig Partridge <craig@nnsc.nsf.net>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Host requirements and SMTP

Craig, thanks for the reply - it clears up most of the points.

> > Section>  5.2.17 
> > Urgghhhhh! This is awful. Making this a MUST is horrible. [I waffle on]..

> Gee -- that's what we tried to do, only a bit more forcefully.  Domain
> literals may show up, your mailer must not barf on them, and if the
> domain literal = your host, your mailer ought to accept it.  In other
> words, God help us, should you get a domain literal, do the minimum
> rational thing -- don't fail, and swallow it if it is for you.

Having to deal with them at all is the problem. The bit that grates on
me is half way through parsing the address you have to suddenly fly
off and discover what all your current IP numbers are. In an otherwise
faily portable bit of software such as an address parser, suddenly
having to dig down into the depths of the currently configured
interfaces is ugly. IP addresses have no place at the mail address
parsing level.

I can now sort of see the rationale behind them. From reading the HR
spec, I sort of imagined (rightly or wrongly) that the debate went
something like:
  "Look, its a really useful debugging technique to send direct to IP
  addresses, so lets force everyone to handle d-lits and debugging
  becomes a lot easier. We can even source route using IP addresses
  then if required."
I would still prefer that you MUST be able to parse the construct but
that you MAY ignore them and can bounce a message if it requires
understanding them.

I think the reason for my unease is that the HR are pretty strong on
discouraging source routing. The d-lit section doesn't say they are
discouraged, just that you must be able to parse them and recognise
your own - which sounds more like encouragement of their use.
Inserting your text above would really show what was meant!

Julian.
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 90 17:11:35 GMT
From:      cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!utzoo!yunexus!davecb@tut.cis.ohio-state.edu  (David Collier-Brown)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Host requirements and SMTP
j.onions@computer-science.nottingham.ac.UK (Julian Onions) writes:
>Section 5.2.5
>The discussion about resolution of the HELO parameter is not that
>essential anyway, to my mind what is more important is that you can
>discover where the SMTP connection is coming from.

	Well, one of them comes from my CP/M-80 machine via a terminal
	server... If I wanted to pay thge long distance costs, they could
	come from "dial smtp" on a Multics box, etc, etc.

	And if you do happen to be using IP, your name may not
	be registered yet.

>	a) you don't know who is sending you the message really, so
>	your chances of getting it back are limited if things blow up.

	I have to agree with this: without a previous agreement at
	the human level the mailer using smtp won't know to queue
	the mail for me and will simply refuse it.

>	b) You don't know who is really sending the message - from a
>	security point of view. IP addresses can be forged but this is
>	better than nothing - certainly better than implicitly
>	believing the HELO.
>Therefore I would argue all the authentication should have been done
>before it gets to the HELO stage. A future HR should perhaps note that
>you should attempt to discover where the message is coming from.

	And we clearly need an authentication mechanism, for which
	the HELO construct is the normal hook (ie, its included even
	though not strictly necessary: guess jon was thinking ahead (:-))

--dave
-- 
David Collier-Brown,  | davecb@yunexus, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave 
Willowdale, Ontario,  | Joyce C-B:
CANADA. 416-223-8968  |    He's so smart he's dumb.
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 90 17:57:00 GMT
From:      CSYSMAS@OAC.UCLA.EDU (Michael Stein)
To:        comp.protocols.tcp-ip
Subject:   Re: Host requirements and SMTP

> Section 5.2.5
> The discussion about resolution of the HELO parameter is not that
> essential anyway, to my mind what is more important is that you can
> discover where the SMTP connection is coming from.  I.e. if you
> can't resolve the IP address back to a domain name then you
> probably should not accept the mail because

HRRFC 5.2.5 says "However, the receiver MUST NOT refuse to accept
a message, even if the sender's HELO command fails verification."

I can't see how that could be clearer -- LET THE MAIL GO THROUGH.

I also remember (from one of the domain RFCs?) that the prefered
way to "check" the HELO name is to do a forward DNS lookup on the
supplied name and see if one of the A records contains the IP
address for this SMTP connection.  This is in preference to the
reverse lookup (IP address to domain name using IN-ADDR.ARPA).

In my opinion the forward lookup sounds much more reliable than
the reverse, however they both sound like they take too long for
a "high performance SMTP implementation".

>        a) you don't know who is sending you the message really, so
>        your chances of getting it back are limited if things blow up.
>        b) You don't know who is really sending the message - from a
>        security point of view. IP addresses can be forged but this is
>        better than nothing - certainly better than implicitly
>        believing the HELO.
> Therefore I would argue all the authentication should have been done
> before it gets to the HELO stage. A future HR should perhaps note that
> you should attempt to discover where the message is coming from.

There isn't any way to do this in SMTP.  All you have is the
domain name (claimed) and the IP address (also claimed).  You
don't know who sent the "bits" or if they have been modified.  If
you really need authentication see the RFCs on privacy
enhancements for electronic mail (RFC1113-1115).

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 90 22:10:22 GMT
From:      ogicse!blake!Tomobiki-Cho!mrc@decwrl.dec.com  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Host requirements and SMTP
In article <24861.631484091@cs.nott.ac.uk> j.onions@computer-science.nottingham.ac.UK (Julian Onions) writes:
>Section 5.2.17 
>Urgghhhhh! This is awful. Making this a MUST is horrible. Domain
>literals should be stamped out. Parsing a domain literal is ok,
>getting the semantics right is yucky in the extreme, it should at the
>maximum have been a MAY. Next thing we'll need to recognise our own
>ethernet addresses in mail messages.  So to be conformant you HAVE to
>be able to discover all your current IP addresses and to match on
>them. Does this really have to be a MUST? How many current systems can
>accept this syntax? I think this will be my biggest stumbling block to
>conformance.

You must recognize a domain literal that refers to yourself.  There
are reasons for using domain literals, including being able to get
through to a working IP address that can't (for some reason) be
accessed by a name.  There are any number of reasons for this
including DNS failure, inconsistent DNS information, or no DNS!!!

There have been abundant problems because of stupid stupid mailers
that fail to recognize one of their own IP addresses in a domain
literal and eventually get into a loop or bounce the message.

A few years ago, the TOPS-20 mailer was stuck with a DNS resolver
which did not offer reasonable canonicalization or MX access.  The
only way it could get the canonical form of a name (as opposed to a
possible non-fully-qualified name or CNAME) was to look up the
IN-ADDR.ARPA PTR record for that IP address.  It couldn't MX at all.
The problem is that many hosts did not have IN-ADDR records or the
information was inconsistent.  If it could not get an IN-ADDR record,
it substituted the domain literal rather than inflict a name that
someone else may not recognize on the rest of the world.

Today, TOPS-20 systems have a reasonable resolver to talk to that
supports DNS-level canonicalization as well as MX.  So these systems
tend to use domain literals a lot less.  However, they still support
domain literals as an escape mechanism.

Consider the modern case.  I try to mail to you.  However, the DNS
server for you is down and has been down for several days.  I know
your IP address, I can telnet to you, but I can't mail to you.  Even
though my mailer knows that your address is "unresolvable" instead of
"bad" and keeps on trying for a few days, eventually it returns the
message as undeliverable.  Well, damnit, I should be able to mail to
you using your IP address.

Well, I can.  But if you have a stupid mailer that sees the message as
a "mail to IP address a.b.c.d" and passes it on without realizing that
you *ARE* a.b.c.d the message is in a loop.

The correct way to handle domain literals is to consider both a host
name and a domain literal as a single atomic entity with a name
property and an IP address property.  When dealing with mailbox at
this atomic entity, you have to check to see if this entity is
yourself.  So, the name property, when canonicalized, should be the
same as your local name.  You simply have to implement the concept of
"canonicalizing" for a domain literal.  That is, finding out, if
possible, what host the domain literal refers to and substituting that
name.  Presumably, if the domain literal refers to one of your own IP
addresses you should be able to substitute your local name!!!!!!!!

Really, this is pretty important.  Too many mailers implement this
wrong.
 _____     ____ ---+---   /-\   Mark Crispin           Atheist & Proud
 _|_|_  _|_ ||  ___|__   /  /   6158 Lariat Loop NE    R90/6 pilot
|_|_|_| /|\-++- |=====| /  /    Bainbridge Island, WA  "Gaijin! Gaijin!"
 --|--   | |||| |_____|   / \   USA  98110-2098        "Gaijin ha doko ka?"
  /|\    | |/\| _______  /   \  +1 (206) 842-2385      "Niichan ha gaijin."
 / | \   | |__| /     \ /     \ mrc@CAC.Washington.EDU "Chigau. Gaijin ja nai.
kisha no kisha ga kisha de kisha-shita                  Omae ha gaijin darou."
sumomo mo momo, momo mo momo, momo ni mo iroiro aru    "Iie, boku ha nihonjin."
uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru    "Souka. Yappari gaijin!"
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      5 Jan 90 22:41:00 GMT
From:      snorkelwacker!usc!samsung!shadooby!sharkey!itivax!scs@bloom-beacon.mit.edu  (Steve Simmons)
To:        tcp-ip@nic.ddn.mil
Subject:   Ethernet Analysis Programs Wanted

We've looked at buying an ethernet sniffer, and the cost is pretty
amazing.  Several alternatives have come to mind.  One is to do software
from scratch, which would be a lot of work.  Anybody done simple
promiscuous ethernet stuff for BSD, Ultrix or Suns?

Another idea is to take one of our old Sun-2s and run an analysis
tool onto etherfind.  Anybody ever done this?

If there's sufficient interest I'll summarize to the net.
-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 90 01:44:10 GMT
From:      bionet!turbo.bio.net!lear@apple.com  (Eliot Lear)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Host requirements and SMTP
RE HR 5.2.3:

The goal was to give the option to the system administrator the option
of disabling these commands either altogether or for private lists,
depending on that particular site's requirements (as stated in
DISCUSSION).

RE HR 5.2.5:

I would agree that HELO has really outlived its usefulness (sendmail
doesn't even require it).  Were I you, I would check the connecting
address and use that instead of HELO to do verifications.  In either
case, you need to accept the mail involved.  On the client side, you
would be foolish to implement code that does not issue a HELO, as
there are sites out there that will barf with a protocol botch error.

RE HR 5.3.3 (I presume, as there is no 5.5.3):

I don't understand.  In the previous line you say, ``Doamin literals
together with source routing should be dropped,'' and then go on to
argue the case where you want to use source routing.  In either the
case where you have MX records, or even if you are dealing with a
site that isn't registered, source routes as defined by RFC822 are
useless because all the hosts listed have to be registered.
-- 
Eliot Lear
[lear@turbo.bio.net]
-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 90 02:38:37 GMT
From:      stealth.acf.nyu.edu!brnstnd@nyu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Want to gamma-test an RFC 931 Authentication Server implementation?
As specified by RFC 931, an Authentication Server on machine X listens
at TCP port 113. Someone on machine Y connects and asks about another
X-Y connection; the Authentication Server reports the name of the user
on the X side. This has obvious applications to SMTP and NNTP: forgery
above the TCP level becomes impossible. (For security below TCP, you
need Kerberos or an equivalent system.)

I've implemented the Authentication Server and related utilities, and
I'd like to gamma test the final (BSD) versions before releasing them
to the net. There are three programs:

  authd - the server itself
  authtcp - a general TCP connector, understands authd
  attachport - a single-port inetd (sort of), understands authd

The programs don't need to be setuid root, but they do need their own
uid and directory.

You don't need to change the kernel to run these programs; this means
that old applications won't suddenly create authenticated connections.
You have to update programs to take advantage of the extra security.
I don't feel guilty about this: a communications program that uses
authtcp or attachport doesn't need to understand TCP at all, so the
whole system becomes much more portable and modular. My one-line
mconnect clone illustrates the idea.

Anyway, if you're interested, write me.

---Dan
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 90 08:14:22 GMT
From:      eru!luth!sunic!tut!santra!mcsun!prlbcom!lln-cs!sunbim!syteke!jim@BLOOM-BEACON.MIT.EDU  (Jim Sanchez)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: LAT-to-Telnet Gateway
Since I do not know your application this may not be appropriate but why
not just use a multi-protocol terminal server(we make such an animal
by the way :-)).  zvLb#:AVoIt can be made pretty transparent.
-- 
Jim Sanchez  {sun,hplabs}!sytek!syteke!jim OR
Hughes LAN Systems, Brussels  uunet!prlb2!sunbim!syteke!jim
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      Sat, 6 Jan 90 23:51:15 CST
From:      Stan Barber <sob@tmc.edu>
To:        tcp-ip@nic.ddn.mil
Cc:        info-vax@sri.com
Subject:   proxyarpd for VAX/VMS available
I have converted the proxyarpd program that was written by Haavard Eidnes
so it will work under VAX/VMS with WIN/TCP. If this is interesting to anyone,
drop me a line. The program was my first attempt to do C development on
the VAX and so it may be crude to seasoned VMS gurus. 

It requires VMS 5.X, VAXC 3.0 and WIN/TCP 5.0.

Stan Barber, Director of Networking and Systems Support
Systems Support Center
Baylor College of Medicine
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      Sun, 7 Jan 90 02:19:40 EST
From:      Dave Katz <katz@merit.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Port numbers
Does anybody recognize any of the following port numbers?
  592
  605
  700
  747
  871
  888
 1021
 1022
 
Thanks in advance.
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      6 Jan 90 21:39:02 GMT
From:      polygen!bill@CS.BU.EDU  (Bill Poitras)
To:        tcp-ip@nic.ddn.mil
Subject:   using SLIP with KA9Q - *** AGAIN *** -
I had posted an article asking for help on a SLIP/Ethernet gateway using 
KA9Q.  Thank you everyone that replied.  Unfortunately, one of the replys I
got, the one that was most helpful, I misplaced (read "I deleted the mail message, and lost the printout") that reply.  The advice that person gave was using 
'arp publish' in the autoexec.net.  Could that person please send your 
autoexec.net file again.  

	And also I want to ask you this.  After you set up the SLIP/Ethernet 
computer, what does the 'route' and 'arp' line in the autoexec.net in the 
SLIP only computer look like?  I almost have the setup I am looking for.  On 
the subject of connecting the two computers, can I setup the SLIP/Ethernet
computer with a modem in autoanswer mode, and then start net.  On the 
other side, do I just dial up the SLIP/Ethernet computer, and again, start net?
I know these are a lot of questions, but they are things that I want to make
sure of, so I can rule them out when I am debugging my setup.  Thanks for 
any help you can give me.


+-----------------+---------------------------+-----------------------------+
| Bill Poitras    | Polygen Corporation       | {princeton mit-eddie        |
|     (bill)      | Waltham, MA USA           |  bu sunne}!polygen!bill     |
|                 |                           | bill@polygen.com            |
+-----------------+---------------------------+-----------------------------+
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Sun, 07 Jan 90 19:24:36 -0800
From:      cire@cisco.com
To:        gauss.llnl.gov!casey@lll-winken.llnl.gov (Casey Leedom)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: IP Multicasting in SunOS

Except for the problems with Casey's proposal it is fine.  :-)

In this discussion I'm using the popular Ethernet meaning of 'multicast'.
That is a multicast addresses is an Ethernet/802.3 address that is 
non-specific and non-broadcast.

Prob 1: Not all ethernet controllers implement multicast addresses.  Those
that do implement only a finite number.

Prob 2: There is potentially an unbounded number of protocols that would
need to use a multicast address.  But there is only a finite number of
multicast addresses available in a given ethernet controller.

These problems can be dealt with in a number of ways.

1) Broadcast must continue to be used to take care of those controllers
that don't use multicast.  This is the final safety net that insures
things keep working.

2) It makes good sense to provide a multicast facility where available.
This facility could be used by ARP, IP Multicast, etc.  The facility must
be able to handle running out of resources.  Namely multicast addr
slots.

3) Running out of slots can be handled in two ways (probably more but two
here).  If the controller supports accept all multicast addresses that
works.  (This type of controller typically does not have any multicast
slots).  For those controllers that have multicast slots, a well known
multicast address could be defined that is used to catch generic multicast
traffic.  This is almost the same as broadcast (broadcast multicast) but
all hosts wouldn't receive it which would be a good thing.


Now a really good question is "Is this additional complexity worth it?"
I don't think so.  Note that the complexity is only needed if this is
implemented fully.  That is an arbritrary node with an arbritrary ethernet
controller should work.

The big problem is that ARP needs to be ubiquitous for IP.  All IP nodes need
to implement what ever is needed to receive ARP packets.  Forcing ARP to
change to a multicast only causes problems for a significant number of nodes
and is not a good idea.  Implementing one or more mechanisms for extended
ARP mechanisms (multicast) adds to the complexity for new hosts significantly
without necessarily eliminating the ARP broadcast traffic.

Given that ARP is a cached protocol (I don't think 'lazy' applies) extending
it to use multicast doesn't seem like a big win.  Except for ARP storms :-)
ARPing doesn't happen that often.

IP Multicast on the other hand doesn't have to be ubiquitous.  It would
be nice but it doesn't have to be.  Therefore it is no big deal if the
use of multicast addresses in an IP Multicast environment is restricted
to those hosts with decently advanced controllers.

-c

cire|eric

"I could have done it in a much more complicated
way", said the Red Queen, immensely proud.
			-- Lewis Carrol, Alice in Wonderland
Eric B. Decker
cisco Systems - engineering
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

>> Date: 8 Jan 90 00:57:50 GMT
>> From: gauss.llnl.gov!casey@lll-winken.llnl.gov  (Casey Leedom)
>> Organization: Lawrence Livermore National Laboratory
>> Subject: Re: IP Multicasting in SunOS
>> 
>>   While you're at it, you should hit up IETF to convert ARP from using
>> Ethernet broadcasts to using Ethernet multicasts.  The fact the ARP
>> scales up nicely on large networks (fundamentally because it's a lazy
>> evaluation algorithm) doesn't excuse it from the bad etiquette of using
>> the Ethernet broadcast address.  After all, why should all the non-IP
>> stations on an Ethernet be bothered with IP ARP packets?
>> 
>>   But this is just an example of the more general complaint of ``Why
>> Ethernet broadcasts at all?'' I have yet to hear of a legitimate need for
>> Ethernet broadcasts.  If the Ethernet Data Link Layer we're more
>> sophisticated and supported facilities that required communication beyond
>> mere packet delivery, then there might be a need for broadcasts.  But as
>> it stands now, the only Data Link Layer facility that Ethernet offers is
>> delivery of packets.  There are no control type messages that might need
>> to be delivered to all stations and therefore (as far as I can see) no
>> need for Ethernet broadcasts at all.
>> 
>>   Abolish Ethernet broadcast!
>> 
>> Casey
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      7 Jan 90 06:29:05 GMT
From:      brian@ucsd.edu  (Brian Kantor)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Host requirements and SMTP
HELO is of use in an environment where the underlying transport does not
provide a means for identifying the peer: i.e., it's not tcp/ip.  I'm
told that DATAKIT is one such; clearly there are others.

We've added an optional HOST command to NNTP for precisely such
purposes.

Occasionally I forget that some of the higher-level Internet protocols
are used on other than the Internet.
	- Brian
-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 90 00:57:50 GMT
From:      gauss.llnl.gov!casey@lll-winken.llnl.gov  (Casey Leedom)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP Multicasting in SunOS

  While you're at it, you should hit up IETF to convert ARP from using
Ethernet broadcasts to using Ethernet multicasts.  The fact the ARP
scales up nicely on large networks (fundamentally because it's a lazy
evaluation algorithm) doesn't excuse it from the bad etiquette of using
the Ethernet broadcast address.  After all, why should all the non-IP
stations on an Ethernet be bothered with IP ARP packets?

  But this is just an example of the more general complaint of ``Why
Ethernet broadcasts at all?'' I have yet to hear of a legitimate need for
Ethernet broadcasts.  If the Ethernet Data Link Layer we're more
sophisticated and supported facilities that required communication beyond
mere packet delivery, then there might be a need for broadcasts.  But as
it stands now, the only Data Link Layer facility that Ethernet offers is
delivery of packets.  There are no control type messages that might need
to be delivered to all stations and therefore (as far as I can see) no
need for Ethernet broadcasts at all.

  Abolish Ethernet broadcast!

Casey
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 90 01:29:02 GMT
From:      van-bc!skl@uunet.uu.net  (Samuel Lam)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: using SLIP with KA9Q - *** AGAIN *** -
In article <660@fred.UUCP>, bill@fred.UUCP (Bill Poitras) wrote:
>After you set up the SLIP/Ethernet computer, what does the 'route' and
>'arp' line in the autoexec.net in the SLIP only computer look like?

The "arp" command is only useful if the computer is connected to Ethernet
directly, so your SLIP-only computer wouldn't need it.

If your SLIP-only computer only has one SLIP link, and thus that link is
the link to the "outside" world, then the only "route" command you need is
the one that sets a default route to point everything to your SLIP neighbour.
It will look like:

   route add default (LINK)

where (LINK) is the name you gave to the SLIP link in the "attach" command
for it.  e.g. sl0.

>On the subject of connecting the two computers, can I setup the
>SLIP/Ethernet computer with a modem in autoanswer mode, and then
>start net.  On the other side, do I just dial up the SLIP/Ethernet
>computer, and again, start net?

Yes, that will work.  However, security could be a problem.  Since anyone
that knows the phone number and your SLIP-only computer's IP address could
call the SLIP/Ethernet computer up and be attached to your network and
impersonate your SLIP-only computer.

...Sam
-- 
Internet: <skl@wimsey.bc.ca>	UUCP: {van-bc,ubc-cs,uunet}!wimsey.bc.ca!skl
-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 90 03:24:36 GMT
From:      cire@CISCO.COM
To:        comp.protocols.tcp-ip
Subject:   Re: IP Multicasting in SunOS


Except for the problems with Casey's proposal it is fine.  :-)

In this discussion I'm using the popular Ethernet meaning of 'multicast'.
That is a multicast addresses is an Ethernet/802.3 address that is 
non-specific and non-broadcast.

Prob 1: Not all ethernet controllers implement multicast addresses.  Those
that do implement only a finite number.

Prob 2: There is potentially an unbounded number of protocols that would
need to use a multicast address.  But there is only a finite number of
multicast addresses available in a given ethernet controller.

These problems can be dealt with in a number of ways.

1) Broadcast must continue to be used to take care of those controllers
that don't use multicast.  This is the final safety net that insures
things keep working.

2) It makes good sense to provide a multicast facility where available.
This facility could be used by ARP, IP Multicast, etc.  The facility must
be able to handle running out of resources.  Namely multicast addr
slots.

3) Running out of slots can be handled in two ways (probably more but two
here).  If the controller supports accept all multicast addresses that
works.  (This type of controller typically does not have any multicast
slots).  For those controllers that have multicast slots, a well known
multicast address could be defined that is used to catch generic multicast
traffic.  This is almost the same as broadcast (broadcast multicast) but
all hosts wouldn't receive it which would be a good thing.


Now a really good question is "Is this additional complexity worth it?"
I don't think so.  Note that the complexity is only needed if this is
implemented fully.  That is an arbritrary node with an arbritrary ethernet
controller should work.

The big problem is that ARP needs to be ubiquitous for IP.  All IP nodes need
to implement what ever is needed to receive ARP packets.  Forcing ARP to
change to a multicast only causes problems for a significant number of nodes
and is not a good idea.  Implementing one or more mechanisms for extended
ARP mechanisms (multicast) adds to the complexity for new hosts significantly
without necessarily eliminating the ARP broadcast traffic.

Given that ARP is a cached protocol (I don't think 'lazy' applies) extending
it to use multicast doesn't seem like a big win.  Except for ARP storms :-)
ARPing doesn't happen that often.

IP Multicast on the other hand doesn't have to be ubiquitous.  It would
be nice but it doesn't have to be.  Therefore it is no big deal if the
use of multicast addresses in an IP Multicast environment is restricted
to those hosts with decently advanced controllers.

-c

cire|eric

"I could have done it in a much more complicated
way", said the Red Queen, immensely proud.
			-- Lewis Carrol, Alice in Wonderland
Eric B. Decker
cisco Systems - engineering
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

>> Date: 8 Jan 90 00:57:50 GMT
>> From: gauss.llnl.gov!casey@lll-winken.llnl.gov  (Casey Leedom)
>> Organization: Lawrence Livermore National Laboratory
>> Subject: Re: IP Multicasting in SunOS
>> 
>>   While you're at it, you should hit up IETF to convert ARP from using
>> Ethernet broadcasts to using Ethernet multicasts.  The fact the ARP
>> scales up nicely on large networks (fundamentally because it's a lazy
>> evaluation algorithm) doesn't excuse it from the bad etiquette of using
>> the Ethernet broadcast address.  After all, why should all the non-IP
>> stations on an Ethernet be bothered with IP ARP packets?
>> 
>>   But this is just an example of the more general complaint of ``Why
>> Ethernet broadcasts at all?'' I have yet to hear of a legitimate need for
>> Ethernet broadcasts.  If the Ethernet Data Link Layer we're more
>> sophisticated and supported facilities that required communication beyond
>> mere packet delivery, then there might be a need for broadcasts.  But as
>> it stands now, the only Data Link Layer facility that Ethernet offers is
>> delivery of packets.  There are no control type messages that might need
>> to be delivered to all stations and therefore (as far as I can see) no
>> need for Ethernet broadcasts at all.
>> 
>>   Abolish Ethernet broadcast!
>> 
>> Casey

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Jan 90 09:14:47 EST
From:      mep@aqua.whoi.edu (Michael E. Pare)
To:        snorkelwacker!usc!samsung!shadooby!sharkey!itivax!scs@bloom-beacon.mit.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Ethernet Analysis Programs Wanted
Doing software from scratch will cost you more than the Sniffer and you
still won't have a PC to run on.  If you want cheap and you have a PC
with an ethernet board, you might want to contact FTP Software, Inc.  They
have a glorified version of MIT's Netwatch available for around $1000.00.
You can call them at (617) 246-0900.  Personally I prefer the Sniffer.
Educational institutions can qualify for a 40% discount on the Sniffer
and asociated software.  Excelan has packages that range from $5200 to
$15755 so you can select your price range (1-800-392-3526).  Good luck.
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Jan 90 11:44:31 CST
From:      Guy Almes <almes@rice.edu>
To:        ncrlnk!ncrcce!cavanaug@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re: What IGP Do You Use?
John,
  Sesquinet uses IGRP, and has no current plans to change.
	-- Guy
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Jan 90 14:20:22 PST
From:      braden@venera.isi.edu
To:        parmelee@cu-arpa.cs.cornell.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  %-Hack .vs. Route Address

	I still think the writers of the Host Requirements RFC screwed up when
	they encouraged the "%-hack" over Route-Addresses.  Has anything been
	published yet to officially state what the "%-hack" is?  In particular,
	how does it relate to the other mail address operators "@" and "!"?
	How do you interpret "foo!bar%baz@blef"?

Please see the DISCUSSION part of Section 5.2.16 for an answer to this 
question.

Bob Braden


-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Mon, 08 Jan 90 12:14:23 EST
From:      Rudy.Nedved@RUDY.FAC.CS.CMU.EDU
To:        Dave Katz <katz@merit.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Port numbers

871 we use for CMU SUP file service.
888 seemes to be used for some type of login/environment passing system.?

-Rudy
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 90 08:19:23 GMT
From:      voder!dtg.nsc.com!andrew@ucbvax.Berkeley.EDU  (Lord Snooty @ The Giant Poisoned Electric Head )
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP Multicasting in SunOS

Why is it that (unlike Ethernet), IBM Token Ring products do not support
multicasting, despite the fact that the protocol (i.e. Group Addresses)
exists already? No vendor (TI or IBM) support more than one Group Address!
-- 
...........................................................................
Andrew Palfreyman	andrew@dtg.nsc.com	Albania before April!
-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      Tue, 09 Jan 90 00:09:17 -0800
From:      warner@TWG.COM
To:        sob@tmc.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   proxyarpd for VAX/VMS available
I'd like to check out what you have.  Please send me a copy of
proxyarpd.  Either that or post it to info-vax.

	Warner Losh
-- 
Warner Losh	warner@twg.com (formerly warner@hydrovax.nmt.edu)
My views and spelling are my own.  Only the letters have been changed.
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Jan 90 16:44:06 EST
From:      "Monica L. Hart" <mhart@NRI.Reston.VA.US>
To:        tcp-ip@nic.ddn.mil
Cc:        mhart@NRI.Reston.VA.US, mcsun!cernvax!chx400!cgch!news@uunet.uu.net
Subject:   A new version of the NOCtools Catalog
A third revision of the NOCtools Network Management Tool Catalog is
now available from the online library of NIC.DDN.MIL and 
NNSC.NSF.NET.

	Title:         A Draft Network Management Tool Catalog:
		       Tools for Monitoring and Debugging TCP/IP
		       Internets and Interconnected Devices
	Editor:        Robert Stine/Sparta of the NOCtools WG
	Filename(s):   draft-ietf-noctools-debugging-02.txt,
		       draft-ietf-noctools-debugging-02.ps, and
		       draft-ietf-noctools-debugging-02.ms

The goal of this draft is to provide practical information to
site administrators and network managers.  It is not a statement
of Internet policy or recommendations.  Distribution of this 
draft is unlimited.  Comments, critiques, editorial suggestions,
and new or updated tool descriptions are welcome, and should be sent 
to Robert Stine, at stine@sparta.com, or to the NOCtools working
group, at noctools@merit.edu.

This draft can be obtained via FTP from NIC.DDN.MIL and NNSC.NSF.NET,
with the FILENAMES above (txt=ascii, ps=postscript, ms=troff -ms).
Login with FTP, username ANONYMOUS and password GUEST.  Once connected
to the NIC cd "internet-drafts:" and when connected to NNSC
cd "internet-drafts".

If you encounter any problems please let me know.

Monica Hart/NRI
-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      Mon, 8 Jan 90 17:15:12 EST
From:      Rob Austein <sra@lcs.mit.edu>
To:        Julian Onions <j.onions@computer-science.nottingham.ac.uk>
Cc:        tcp-ip@nic.ddn.mil, sra@lcs.mit.edu
Subject:   Host requirements and SMTP
Julian,

Back when Mark Crispin and I were implementing the current interface
between the TOPS-20 mailer and domain resolver, we concluded that we
would be best off avoiding the IN-ADDR.ARPA portion of the DNS tree if
at all possible.  Informal observation convinced us that the IN-ADDR
tree is, on the whole, significantly less accurate than the main
portion of the DNS tree.  Sad, but true.  So our validation mechanism
does indeed want the name from the HELO command as a starting point.
It will let the mail through if the validation fails, it just makes a
lot of rude comments and flags the failure in the Received: header.

There are other reasons why the HELO command is useful (eg, the BSMTP
protocol), but this one is rooted in a real and current Internet
problem.  I for one would be unhappy if the SMTP protocol didn't have
the HELO command.

--Rob Austein
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 90 12:33:06 GMT
From:      rich@pluto.UUCP (Rich)
To:        comp.protocols.tcp-ip,comp.os.vms
Subject:   Re: LAT-to-Telnet Gateway

In article <686@syteke.be>, jim@syteke.be (Jim Sanchez) writes:
> Since I do not know your application this may not be appropriate but why
> not just use a multi-protocol terminal server(we make such an animal
> by the way :-)).  zvLb#:AVoIt can be made pretty transparent.
> -- 
> Jim Sanchez  {sun,hplabs}!sytek!syteke!jim OR
> Hughes LAN Systems, Brussels  uunet!prlb2!sunbim!syteke!jim

A multi-protocol terminal server is fine in the case of a new installation
or replacing an existing unit. But there are a lot of single-protocol
boxes out there now.

A 'Gateway' needs to address making better use of existing hardware.

Datability's VISTA Product line includes a Network Protocol Translator (NPT)
card that allows any LAT terminal server (DECserver 200, etc) to communicate
with TCP/IP Telnet based hosts. (Of course it works TELNET -> LAT also).

(The above comments are my own, although I work for Databilitly.)
-- 

----------------------------------------------------------------------------
Richard L. Rupp                                           rich@pluto.dss.com
Datability Software Systems, Inc.            212 807 7800, Fax: 212 807 0958

-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 90 15:32:03 GMT
From:      parmelee@cu-arpa.cs.cornell.edu  (Larry Parmelee)
To:        tcp-ip@nic.ddn.mil
Subject:   %-Hack .vs. Route Address
Excuse me for jumping in in the middle of things...

In article <9001060126.AA11937@ucbvax.Berkeley.EDU>
craig@NNSC.NSF.NET (Craig Partridge) writes:
> 
> [...], I'd argue the gateway should have sent stuff
> out as user%hidden@host, [...] .
> 
> Craig

I still think the writers of the Host Requirements RFC screwed up when
they encouraged the "%-hack" over Route-Addresses.  Has anything been
published yet to officially state what the "%-hack" is?  In particular,
how does it relate to the other mail address operators "@" and "!"?
How do you interpret "foo!bar%baz@blef"?

RFC 976 defines how to translate back and forth between uucpish pure
"!" addresses and internet address form, including route-addresses; and
also defines the interpretation of "hybrid" forms containing both "@"
and "!".  It recommends avoiding "%".  I fully agree:  because the 
"%-hack" is not defined, hosts can handle it however they wish,
and what they do may not be what you intended.

Until something/someone officially defines the "%-hack", I will
strongly resist using it, prefering route-addresses as the only
un-ambiguous alternative.  Unfortunately, the Host Requirements RFC
will undoubtedly eventually cause trouble with this approach.  Hopefully
someone will come up with a unified definition of "%", "!", and "@"
before things get too bad.

-Larry Parmelee
parmelee@cs.cornell.edu
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Tue, 09 Jan 90 01:07 PST
From:      Denis DeLaRoca (213) 825-4580        <CSP1DWD@OAC.UCLA.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   KA9Q with PPP and Van's Header Compression code
I think one of the beta implementations of PPP was done with
ka9q, possibly including Van Jacobsen's Header Compression
code, is this version of ka9q available somewhere?

-- Denis

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 90 17:14:23 GMT
From:      Rudy.Nedved@RUDY.FAC.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Port numbers


871 we use for CMU SUP file service.
888 seemes to be used for some type of login/environment passing system.?

-Rudy

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 90 17:42:21 GMT
From:      zaphod.mps.ohio-state.edu!mips!excelan!george@tut.cis.ohio-state.edu  (George Powers)
To:        tcp-ip@nic.ddn.mil
Subject:   looking for OSPF source code
I am looking for source to OSPF we can crib for a new product.
I hear that U Maryland has something like this, but I don't
know who to contact...

--
UUCP: {ames,sun,apple,mtxinu,cae780,sco}!excelan!george  George Powers
Internet: george@excelan.com 
--
-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 90 20:56:52 GMT
From:      amdahl!rtech!wrs!hwajin@ames.arc.nasa.gov  (Hwa Jin Bae)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP Multicasting in SunOS
While newer ethernet boards designed around recent chip sets such
as LANCE and National's NIC (DP8390) family do provide ability to program
your multicast addresses this is not yet available every where.
Even the boards built around such advanced chips do not provide 
direct access to the chip registers (e.g. some of cmc and excelan boards)
thus making the multicast address programming less than straight forward
at the driver level.  The complexity involved shouldn't be ignored
either.  A well maintained ARP cache, in my opinion, is a good 
compromise.  Besides, in the real world most people do not forward
random broadcast packets via gateways, thereby restricting the local
broadcast traffic.  The only big problem I can see is the occasional
broadcast storms caused by early 4.2bsd derived systems which sent
out ARP's for certain unrecognized broadcast IP addresses, but this
bug is quickly disapearing.

hwajin
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      8 Jan 90 22:18:59 GMT
From:      ogicse!blake!Tomobiki-Cho!mrc@ucsd.edu  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Host requirements and SMTP
In article <9001060622.AA28788@ucbvax.Berkeley.EDU> CSYSMAS@OAC.UCLA.EDU (Michael Stein) writes:
>HRRFC 5.2.5 says "However, the receiver MUST NOT refuse to accept
>a message, even if the sender's HELO command fails verification."

This brings up a related issue.  The TOPS-20 SMTP server will reject a
HELO under two circumstances:
 a) syntax invalidity
 b) the HELO claims to be the local host, but the IP address is not
    one of the known local IP addresses.

It also requires the successful negotiation of a HELO before starting
a MAIL transaction.

As I read the HRRFC, this is not allowed behavior any more, but I
haven't heard any complaints about this behavior either.  That is, I
have never heard any complaints of mail not getting through to a
TOPS-20 system because the SMTP client:
 a) uses bogus syntax in its HELO
 b) claims to be the TOPS-20 system it is talking to.
 c) doesn't want to do a HELO before starting a transaction

My question is, do we really want to outlaw behavior that isn't
causing a problem?  I can get rid of these behaviors; it involves the
deletion of a few lines of code.  I don't believe it's desirable to do
so.  However, I have this nightmare of someone with a truly sick SMTP
client taking me to task for not obeying the HRRFC.

The check for local host is a useful behavior, albeit less useful in
TCP days.  Basically, it catches "mirrors" (which is what HELO was put
in to get rid of).  Mirrors were a common problem in NCP days, but
still pop up from time to time in TCP.  I've seen hosts in debugging
states that reflect TCP connections.

My understanding of what the HRRFC was trying to outlaw was rejecting
a HELO when the name was unknown, or the name didn't match; problems
that generally were due to out of date host tables or DNS information.
Has the HRRFC gone a bit too far in the opposite direction?
 _____     ____ ---+---   /-\   Mark Crispin           Atheist & Proud
 _|_|_  _|_ ||  ___|__   /  /   6158 Lariat Loop NE    R90/6 pilot
|_|_|_| /|\-++- |=====| /  /    Bainbridge Island, WA  "Gaijin! Gaijin!"
 --|--   | |||| |_____|   / \   USA  98110-2098        "Gaijin ha doko ka?"
  /|\    | |/\| _______  /   \  +1 (206) 842-2385      "Niichan ha gaijin."
 / | \   | |__| /     \ /     \ mrc@CAC.Washington.EDU "Chigau. Gaijin ja nai.
kisha no kisha ga kisha de kisha-shita                  Omae ha gaijin darou."
sumomo mo momo, momo mo momo, momo ni mo iroiro aru    "Iie, boku ha nihonjin."
uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru    "Souka. Yappari gaijin!"
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 90 00:34:56 GMT
From:      cs.utexas.edu!samsung!munnari.oz.au!cluster!usage!ccadfa!cjsv%cs.adfa.oz.au@tut.cis.ohio-state.edu  (Christopher J S Vance)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: %-Hack .vs. Route Address
In article <35783@cornell.UUCP> parmelee@cs.cornell.edu (Larry Parmelee) writes:
> Excuse me for jumping in in the middle of things...

Me too?

> Until something/someone officially defines the "%-hack", I will
> strongly resist using it, prefering route-addresses as the only
> un-ambiguous alternative.  Unfortunately, the Host Requirements RFC
> will undoubtedly eventually cause trouble with this approach.  Hopefully
> someone will come up with a unified definition of "%", "!", and "@"
> before things get too bad.

But it seems to me that you're only allowed to use route-addresses when all
the hosts are registered with the NIC.  Since they won't want to register
every PC in the world, or even every mainframe on lots of networks which are
not on the Internet, it seems you've got to break some rules to make things
work.  Personally, I think source-routes are nasty since they aren't pure
left-to-right or right-to-left.  But then I've never had to use them....
-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      Tue, 09 Jan 90 08:41:53 PST
From:      cire|eric <cire@cisco.com>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: IP Multicasting in SunOS

Well its not that Token Ring doesn't support multicasting ...  it does.
It just does so in a different way.  The Group Address is the form that
the Ether community is used to thinking as Multicasting.  However as you
pointed out there is only one of those in the current implementations.

The useable form of multicasting though is the Functional address.  These
are bit significant addresses.  A Token Ring interface can have upto 31
of these assigned.  For example, if I had an interface assigned the
functional address c000.0080.1000, this interface would receive packets
with the destination addresses that had either of those bits set.  ie.
c000.0080.0000 or c000.0000.1000 or c000.0080.1000 or c000.07f0.d000
etc.

This provides essentially a superset of the ethernet multicast capability.
The biggest dissadvantage however is the small address space.  However you
don't have to convince the various hardware vendors to implement n
multicast address slots.  Which in practice is as much as a limitation.

Another argument is that they are not universal and thus will lead to
address collisions.  I maintain that this can ge dealt with via 
appropriate naming authority mechanisms.

-c
cire|eric

"I could have done it in a much more complicated
way", said the Red Queen, immensely proud.
			-- Lewis Carrol, Alice in Wonderland
Eric B. Decker
Token Ring Development
cisco Systems - engineering
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 90 01:13:34 GMT
From:      voder!pyramid!infmx!kwang@ucbvax.Berkeley.EDU  (Kwang Sung)
To:        tcp-ip@nic.ddn.mil
Subject:   Status of interoperation with GOSIP and a NATO OSI profile
Hi... there,

	Does anybody know the status of interoperation with GOSIP and
a NATO OSI profile ??  Thanx. 


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang
-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 90 02:10:48 GMT
From:      gauss.llnl.gov!casey@lll-winken.llnl.gov  (Casey Leedom)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP Multicasting in SunOS
| From: cire@CISCO.COM
| 
| Except for the problems with Casey's proposal it is fine.  :-)

  Yes, I know that it's really too late to get rid of Ethernet
broadcasts, but I had to bring it up because too many people think that
Ethernet broadcasts are the Right Way to do things (for instance all the
&^*%&*^ groady broadcast license schemes floating around).

| Given that ARP is a cached protocol (I don't think 'lazy' applies)
| extending it to use multicast doesn't seem like a big win.

  "Lazy" refers to Lazy Evaluation which is an algorithm technique that
can often work wonders for theoretically large polynomial or even
non-polynomial problems.  The basic idea is that instead of always trying
to be prepared at every stage of an algorithm with every possible value
one might need to compute the next stage of the algorithm, you don't pre-
compute anything.  Instead you fault when you need a value that hasn't
been compute yet.  It's called Lazy Evaluation because of the analogy of
a Lazy Person not doing anything until it's needed.

  In this particular case I'm comparing the non-Lazy Hello type Address
Resolution Protocols to the Lazy Ethernet/IP Address Resolution
Protocol.  In the ARPs of the former type, every station constantly
screams its Ethernet/Network address pairing to the entire net to make
sure everyone knows how to get to it.  This technique doesn't scale up
well at all for larger networks.  Unfortunately it's used by a lot of
network protocols.  The IP/Ethernet ARP on the other hand scales up very
nicely.

  Thus, I essentially agree with you that there's not a lot to be gained
in converting IP/Ethernet ARP to Ethernet multicasting.  But I still hate
the use of Ethernet broadcasts.  I just don't think they ever should have
existed, or their use should have been specifically described for use in
an Ethernet level Control Message Protocol (and even then that should
simply have been yet another multicast address; thus I can't find any
good reason to support Ethernet broadcasts).

Casey
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      Tue, 09 Jan 90 18:41:35 -0800
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
To:        haven!uvaarpa!randall@purdue.edu (Randall Atkinson)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: %-Hack .vs. Route Address

>There are special cases that won't be covered, but this solution DOES
>handle the case of PCs on an internal network or any other  such situation.
>The main case it won't (legally) handle is gatewaying to a network whose
>machines aren't under your theoretical administrative control.
>NASA's SPAN DECnet is circumventing this by having *.SPAN.NASA.GOV and
>I heartily approve of NASA's solution even though many nodes on that
>DECnet aren't owned or operated by NASA.

This was/is a hack to enable reasonable functionality for mail
relay to SPAN systems.  It's not the right thing to do, but was
expedient.  The reason it's not right is that SPAN is not run by
a single organizational unit (to use OSIspeak).  The right way
of skinning the cat would be to use individual MX records for
machines at sites to map them into the local domain name space
of the facility.

For example, a DECNET node named SAT located at Ames, should not
be addressed at user@sat.span.nasa.gov, but user @sat.arc.nasa.gov.  This
way, if the machine happens to speak IP (as it does), it could be
considered a CNAME for it's full hostname, or an MX record could
be used that points mail at an Ames local MAIL-11 relay system.  If
you use an MX record for *.span.nasa.gov, then all of it has to
go through a single mail relay.  You can get into the case of a JPL host
sending internet mail to a JPL DECNET host via a relay at ARC or GSFC.
If the JPL DECNET host had an MX record in the jpl.nasa.gov subdomain,
a more optimal path could be taken.  I think JPL actually does this,
but the point is the obvious.

The problem with this is that it means having all the individual
system administrators interacting with all the site domain managers
and whoever runs a relay at the site to fix things so they work
right, which is harder than fixing it once using the span.nasa.gov 
pseudodomain.

The same reason holds why a .BIT.NET or .CS.NET (or maybe .ONE.NET
these days I guess) is a bad idea.  Those systems really should reside
in a site's name local namespace.  If people obeyed these rules, Internet
mail delivery would be much more transparent, and the fact that a 
particular network (SPAN,BITNET,CSNET, etc...) was being used as
transport would be hidden from the users.  And that makes life easier
on them.  Why should 3 different forms of different address 
specifications be used to talk to 3 machines connected in different
ways at one site?


					Thanks,
					   Milo

PS All the usual disclaimers about the government not being responsible
for anything I say apply of course...

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 90 12:31:40 EST (Tuesday)
From:      Marty <Leisner.Henr@Xerox.COM>
To:        tcp-ip@nic.ddn.mil
Cc:        leisner.Henr@Xerox.COM
Subject:   TCP/IP printing protocol
Is there a TCP/IP printing protocol?  Is there such a thing as a TCP/IP print server?

Any information is appreciated, 

thanks,

marty
ARPA:	leisner.henr@xerox.com
GV:  leisner.henr
NS:  leisner:wbst139:xerox
UUCP:	hplabs!arisia!leisner
 
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 90 09:07:00 GMT
From:      CSP1DWD@OAC.UCLA.EDU (Denis DeLaRoca  825-4580, 213)
To:        comp.protocols.tcp-ip
Subject:   KA9Q with PPP and Van's Header Compression code

I think one of the beta implementations of PPP was done with
ka9q, possibly including Van Jacobsen's Header Compression
code, is this version of ka9q available somewhere?

-- Denis

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Tue, 09 Jan 90 10:17:16 +0000
From:      Julian Onions <j.onions%computer-science.nottingham.ac.uk@NSFnet-Relay.AC.UK>
To:        mrc%tomobiki-cho.cac.washington.edu@NSFnet-Relay.AC.UK
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Host requirements and SMTP

It all seems to me that there is a lot of effort going into brain
damaging protocols like RFC-822 just to work around broken DNS
implementations. In the end, DNS has to provide the service and whilst
pragmatic workarounds are OK for debugging, fixing them in concrete
seems silly.

Surely the solution is improving the DNS rather enforcing the use of
IP addresses in mail addresses. If you allow escapes all the time so
that the DNS can perform poorly, it will most likely continue to
perform poorly.  Yes - it may be occasionally useful to be able to
directly aim mail at an IP address - but is it worth enforcing this
capability. I might make the same claim that if I have a machine with
a broken ARP mechanism it would be useful to mail directly to an
ethernet address without requiring IP or names - but the solution is
to fix the ARP implementation.

In the UK, we had a similar situation for our registry, the NRS. A few
years ago, people were loath to use this database, rarely kept up to
date and only registered new hosts in it when they remembered.
Then in certain implementations of the mail software we started
refusing to accept mail from sites that were not registered (if you're
not willing to identify yourself, we dont want to know + its almost
trivial to loose email in such situations). I won't say this changed
things overnight, but people now realise if they want to be part of
this community, they better play by the rules and there are few sites
now unregistered and everyone makes use of the NRS now.

One of the problems I see with the IP d-lits is that it really isn't
smtp specific - no matter what the HR says. We run RFC-822 (which is
what the question is really about) over several networks, each
supporting their own style of d-lits. The natural course is to follow
the HR which means I need to understand lots of different styles of
d-lits now (IP, X.25, yellow book ...). Its painful after having split
up a system into SMTP and generic RFC-822 components to then have to
go and stick back into the generic components SMTP specific bits.

I guess if you'd split the HR into RFC-821 specific things and RFC-822
specific things maybe this wouldn't have arisen. Perhaps another idea
for a future HR.

Julian.
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 90 15:46:04 GMT
From:      ddl@husc6.harvard.edu  (Dan Lanciani)
To:        tcp-ip@nic.ddn.mil
Subject:   is Van Jacobson tcp header prediction code available?

	...and if so, where?

			Dan Lanciani
			ddl@harvard.*
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 90 16:41:53 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Re: IP Multicasting in SunOS


Well its not that Token Ring doesn't support multicasting ...  it does.
It just does so in a different way.  The Group Address is the form that
the Ether community is used to thinking as Multicasting.  However as you
pointed out there is only one of those in the current implementations.

The useable form of multicasting though is the Functional address.  These
are bit significant addresses.  A Token Ring interface can have upto 31
of these assigned.  For example, if I had an interface assigned the
functional address c000.0080.1000, this interface would receive packets
with the destination addresses that had either of those bits set.  ie.
c000.0080.0000 or c000.0000.1000 or c000.0080.1000 or c000.07f0.d000
etc.

This provides essentially a superset of the ethernet multicast capability.
The biggest dissadvantage however is the small address space.  However you
don't have to convince the various hardware vendors to implement n
multicast address slots.  Which in practice is as much as a limitation.

Another argument is that they are not universal and thus will lead to
address collisions.  I maintain that this can ge dealt with via 
appropriate naming authority mechanisms.

-c
cire|eric

"I could have done it in a much more complicated
way", said the Red Queen, immensely proud.
			-- Lewis Carrol, Alice in Wonderland
Eric B. Decker
Token Ring Development
cisco Systems - engineering
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 90 17:45:42 GMT
From:      haven!uvaarpa!randall@purdue.edu  (Randall Atkinson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: %-Hack .vs. Route Address
In article <836@ccadfa.adfa.oz.au> cjsv@cs.adfa.oz.au (Christopher J S Vance) writes:

>But it seems to me that you're only allowed to use route-addresses when all
>the hosts are registered with the NIC.  Since they won't want to register
>every PC in the world, or even every mainframe on lots of networks which are
>not on the Internet, it seems you've got to break some rules to make things
>work.  Personally, I think source-routes are nasty since they aren't pure
>left-to-right or right-to-left.  But then I've never had to use them....

Actually, any node on the GE internal DECnet can be reached as
node.DNET.GE.COM and there are no A records or in fact IP addresses
for virtually all of the machines on that network.  The RFC states
that you are only allowed to use route-addresses with fully-qualified
domain names in registered domains.  GE's solution is fairly general
and requires only a single MX record pointing *.DNET.GE.COM to a
relay-host directly on the Internet.

There are special cases that won't be covered, but this solution DOES
handle the case of PCs on an internal network or any other  such situation.
The main case it won't (legally) handle is gatewaying to a network whose
machines aren't under your theoretical administrative control.
NASA's SPAN DECnet is circumventing this by having *.SPAN.NASA.GOV and
I heartily approve of NASA's solution even though many nodes on that
DECnet aren't owned or operated by NASA.

The %-hack is widely overused and I'd like to see it used only when
really necessary because it causes a lot of mail delivery problems.

  Ran
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 90 19:10:00 WET DST
From:      "John" <laws@ccint1.rsre.mod.uk>
To:        "voder!pyramid!infmx!kwang" <voder!pyramid!infmx!kwang@ucbvax.berkeley.edu>
Cc:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   RE: Status of interoperation with GOSIP and a NATO OSI profile

Kwang,

I would think that the person to ask is Otto Shultz (JTC3A DCA DOD) as he
is the US Prin Rep to the NATO TSGCEE SG/9 that is working on the NATO OSI
profile and is aware of the issues of interoperability of both US and UK
GOSIP.

I don't have Otto's e-mail address to hand but he can be reached via
mcdowell@dca-ems.arpa

John

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      9 Jan 90 22:13:12 GMT
From:      sdcc6!ee299at@ucsd.edu  (Subhasis Chaudhuri)
To:        tcp-ip@nic.ddn.mil
Subject:   Net Management Tutorials for TCP/IP Internets
Hi

Could members of this group point me to
tutorial type articles or books on
managing tcp/ip Internets.I am aware of the
one which appears in the IETF Noc Tools Catalogue

Thanks Much
Pushp
-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 90 03:36:32 GMT
From:      laws@CCINT1.RSRE.MOD.UK ("John")
To:        comp.protocols.tcp-ip
Subject:   RE: Status of interoperation with GOSIP and a NATO OSI profile


Kwang,

I would think that the person to ask is Otto Shultz (JTC3A DCA DOD) as he
is the US Prin Rep to the NATO TSGCEE SG/9 that is working on the NATO OSI
profile and is aware of the issues of interoperability of both US and UK
GOSIP.

I don't have Otto's e-mail address to hand but he can be reached via
mcdowell@dca-ems.arpa

John

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 90 11:42:00 PDT
From:      "DV" <saboml@d3.ams.wpafb.af.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   Re: SNMP product overview (RFC)
Re: SNMP product overview (RFC)

> during our SNMP (and CMOT) discussion in this newsgroup last year,
> we were informed, that a RFC will be published in december 1989
> containing an overview on the SNMP products suppliers. Has this
> special RFC been published? which is his number? where and how
> is it available?

> thank you
> armin


 >      Armin R. Schweizer, CIBA-GEIGY AG, R1045.P.06, WRZ
 >                 4002 Basel / Switzerland
 >                   phone: -41-61-697'79'46

I am not aware of an RFC being developed on SNMP products 
suppliers.  However, DATAPRO Research has completed an extensive 
market survey on SNMP (manager and agent) suppliers.  This 
information along with another article on SNMP internals, is 
apparently scheduled to be published in their Volume on Network 
Management in a couple of weeks.  Most University libraries carry 
the DATAPRO Research series.  For more information contact Jill 
Huntington-Lee at 1(800) DATAPRO.

-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 90 05:55:30 GMT
From:      gds@cs.ucla.edu
To:        tcp-ip@nic.ddn.mil
Subject:   queueing theory poll
Hello out there.  I am curious to know if any of you use queueing
theory or applications in your job or research as network designers,
protocol designers, etc., and how you use it.  I'd also like to know
where you learned it and how useful you have found it.  Please follow
up by email.

--gregbo
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 90 10:05:52 GMT
From:      mcsun!inria!chorus!sylvain@uunet.uu.net  (Sylvain Langlois)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP Multicasting in SunOS

In article <819@wrs.wrs.com> hwajin@wrs.wrs.com (Hwa Jin Bae) writes:

Hwa Jin>    While newer ethernet boards designed around recent chip sets such
Hwa Jin>    as LANCE and National's NIC  (DP8390)  family  do  provide
Hwa Jin>    ability  to program your multicast addresses this is not
Hwa Jin>    yet available every where.

Hwa Jin>    Even the boards built around such advanced chips do not provide 
Hwa Jin>    direct access to the chip registers (e.g. some of cmc and
Hwa Jin>    excelan  boards)  thus  making  the  multicast  address
Hwa Jin>    programming less than straight forward at the driver level.  

I'm  trying  to bring up Multicast IP (V 1.2 of june 89) on a Sun 3/80
running sun OS 4.0.3 ... 
It  seems  that  the Lance Ethernet driver has been changed a lot for
the 3/80 (numerous references to this  type  of  architecture  in  the
sources!). As far as I understand, Mutlicast IP, as distributed by ftp
has not been ported on such a box. I've tried to hack  around  between
Steve's sources and Sun Kernel sources but I  still  cannot  boot:  it
seems that me IP layer is totally dead  (init  process  cannot  launch
ypbind for instance!). 

Has  anyone  already  faced  these problems? Is it planned that a next
release of Multicast IP will be running on this particular configuration?


Sylvain

--
----------------
Sylvain Langlois		  "Dogmatic attachement to the supposed merits
(sylvain@chorus.fr)		   of a particular structure hinders the search
(sylvain%chorus.fr@mcsun.EU.net)   of an appropriate structure" (Robert Fripp)
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Wed, 10 Jan 90 17:12:12 CST
From:      santa@opus.cray.com (Dave Sadler)
To:        tcp-ip@nic.ddn.mil
Subject:   SNMP Product Overview (RFC)
Maybe the NIC Implementation and Vendors Guide (NIC 50002) could contain a section -
ion on SNMP products?

Dave Sadler
Cray Research Inc.
santa@cray.com
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 90 18:18:50 GMT
From:      pollux!ccruss@ucdavis.ucdavis.edu  (Russ Hobby)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP printing protocol
Currently there is no offical TCP/IP protocol for printing, and there is
a need. Amoung UNIX systems lpr is used a lot. Several printer vendors have 
their own protocols. 

I am in search of people interested in this problem to form an IETF Working
Group to come up with a good network printer protocol.  Some of the things that
the protocol would need to consider are:
   1) Authentication/security/accounting
   2) Printing modes and options (Postscript, plain text, page/line size,...)
   3) Scheduling priorities
   4) Begin/end job control
   5) Printers that are directly connected to a network or through a host.

If you are interested in working on such a protocol or just have some good
ideas, let me know.

Russ Hobby                              INTERNET: rdhobby@ucdavis.edu  
IETF Area Director - Applications       BITNET:   RDHOBBY@UCDAVIS  
                                        UUCP:  ...!ucbvax!ucdavis!rdhobby 
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 90 18:42:00 GMT
From:      saboml@D3.AMS.WPAFB.AF.MIL ("DV")
To:        comp.protocols.tcp-ip
Subject:   Re: SNMP product overview (RFC)

Re: SNMP product overview (RFC)

> during our SNMP (and CMOT) discussion in this newsgroup last year,
> we were informed, that a RFC will be published in december 1989
> containing an overview on the SNMP products suppliers. Has this
> special RFC been published? which is his number? where and how
> is it available?
 
> thank you
> armin


 >      Armin R. Schweizer, CIBA-GEIGY AG, R1045.P.06, WRZ
 >                 4002 Basel / Switzerland
 >                   phone: -41-61-697'79'46

I am not aware of an RFC being developed on SNMP products 
suppliers.  However, DATAPRO Research has completed an extensive 
market survey on SNMP (manager and agent) suppliers.  This 
information along with another article on SNMP internals, is 
apparently scheduled to be published in their Volume on Network 
Management in a couple of weeks.  Most University libraries carry 
the DATAPRO Research series.  For more information contact Jill 
Huntington-Lee at 1(800) DATAPRO.

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 90 18:45:57 GMT
From:      geof@ames-aurora.arpa  (Geoffrey H. Cooper)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP printing protocol
In article <900109-093140-4953@Xerox> Leisner.Henr@XEROX.COM (Marty) writes:
>Is there a TCP/IP printing protocol?  Is there such a thing as a TCP/IP print server?

IMAGEN (now QMS) has been selling TCP-IP print servers since 1983 for
their line of high-end printers (20ppm, duplex, many
emulations/languages).  QMS itself has a product called "PrintLink"
that also speaks TCP-IP (I think it only uses a standard FTP server).
DEC also has a TCP-IP print server that runs at 40ppm.

DEC has its own protocol, which is somewhat more complex than
IMAGEN's.  I'll let one of the DEC people explain it, since I'm not
fully familiar with it.

IMAGEN's protocol was designed to maximize simplicity, since the
printer has other mechanisms for communicating everything about a
print job (#copies, duplex on/off, emulation to select, etc).  The
protocols are documented in manuals shipped with the printers.  There
are three protocols: "transport1", "status1", "accounting1".  (The "1"
part was an optimistic hope that there would be fancier protocols to
come.  That these were never really needed is partially a tribute to
how much can be achieved with how little and partially a sign that
people are only mildly interested in doing fancy things with their
printers). 

IMAGEN's approach has been to distribute software for popular machines
that implements its printing protocols.

Status1 is a UDP-based protocol.  The printer listens on a dedicated
UDP port (35) for packets, and returns every packet it receives with a
description of the current state of the printer: print a job, paper
jam, out of paper, etc..

Transport1 is a TCP-based protocol.  The printer listens on a
dedicated TCP port (35) for connections.  All data sent down the
connection is processed as a single print job.  The sender sends a
FIN to indicate end-of-job, and the printer responds with its FIN when
it is willing to accept full responsibility for printing the tail of
the job.

To talk to the printer, Status1 and Transport1 are enjoined into a
"combined protocol" that arbitrates multiple access.  Under this
protocol, the sender probes with Status1 until it sees that the
printer is ready to accept a new job (most implementations of the
suite do not locally spool data, and for other reasons they can't 
accept a TCP connection until they are actually ready to start
processing the print job).  Then it attempts to open a Transport1
connection.  If this fails, the loop repeats.

In the early days, host UDP support of sometimes poor (hello apollo)
so a modified combined protocol also exists whereby only Transport1 is
used.  In the rare case that I personally did an installation, I was
able to implement this with a shell script that piped into telnet, so
that I could demo the printer immediately.

Accounting1 is a UDP-based protocol.  The printer can be configured
with a number of trusted "accounting hosts" and sends datagram packets
to them at the end of each job.  The protocol is not completely
reliable, but you can make it pretty useful if you have multiple hosts
receiving UDP packets (there was a paper done some time ago about the
doing reliable broadcasts without ACK's).  This is probably the
weakest link of the "suite".

- Geof
-- 
geof@aurora.com / aurora!geof@decwrl.dec.com / geof%aurora.com@decwrl.dec.com
-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 90 19:13:09 GMT
From:      bbn.com!clements@bbn.com  (Bob Clements)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sources for TCPIP.
In article <m0gl9Ll-0001UEC@utower.gopas.sub.org> fischer@utower.gopas.sub.org writes:
>Get the KA9Q Sources, they are PD and written for MSDOS.

NO, NO, NO, NO, NO!

The KA9Q sources are NOT PD.
They are copyrighted, but are freely copyable for Amateur Radio and
educational institutions.  For other use, contact the author.

There are versions for MSDOS, Unix and a buncha other systems.

>-Axel
>--
>fischer@utower.gopas.sub.org / fischer@db0tui6.BITNET / fischer@tmpmbx.UUCP
>Bang-Europe : ...!{doitcr,gopnbg,tmpmbx}!utower!fischer
>Bang-USA    : ...!uunet!unido!gopnbg!utower!fischer


Bob Clements, K1BC, clements@bbn.com

[Sorry for the repetition of this info, but people keep repeating the
above falseness.  Sigh.]
-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 90 19:27:30 GMT
From:      att!cbnewsh!hpk@ucbvax.Berkeley.EDU  (howard.p.katseff)
To:        tcp-ip@nic.ddn.mil
Subject:   Public-domain gateway code wanted
We are about to build a stand-alone Internet gateway between two
Ethernets.  It seems to me that this has been done before!

Can anybody point me to public domain code that implement a gateway?
-- 
Howard Katseff
Room 4G-622, AT&T Bell Laboratories, Holmdel, NJ  07733
UUCP: att!vax135!hpk       INTERNET: hpk@vax135.att.com
PHONE: 201 949-5337
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 90 21:01:31 GMT
From:      asuvax!mcdphx!varese.UUCP!kjj@handies.ucar.edu  (Kevin Johnson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP printing protocol
In article <6434@ucdavis.ucdavis.edu> rdhobby@ucdavis.edu (Russ Hobby) writes:
>Currently there is no offical TCP/IP protocol for printing, and there is
>a need. Amoung UNIX systems lpr is used a lot. Several printer vendors have 
>their own protocols. 

I'm curious why there isn't an RFC addressing this...

. . .

>If you are interested in working on such a protocol or just have some good
>ideas, let me know.

apol. for tacking this in but the news posting is going out anyway...
Sure, I'll byte...
-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 90 22:22:04 GMT
From:      att!cbnewsl!vass@ucbvax.Berkeley.EDU  (srinivas.vasantharajan)
To:        tcp-ip@nic.ddn.mil
Subject:   FTP/File Transfer Benchmarks
I am interested in running some benchmarks on AT&T's version of the FTAM-FTP
gateway. Could somebody please tell me of of some industry standard 
benchmarks or papers that talk about file transfer benchmarks for FTP.
Your help in this matter is appreciated. Thanks

vas
vas@attunix.att.com
-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      10 Jan 90 22:32:03 GMT
From:      mcsun!ukc!pyrltd!trevan!trevor@uunet.uu.net  (Trevor J. Harris)
To:        tcp-ip@nic.ddn.mil
Subject:   Internet gateways in USA
Please can anyone tell me if there are any Internet gateways in the USA
with which I could connect using a TrailBlazer with SLIP. Please mail
responses.
		regards trevor		ukc!trevan!trevor
-- 
-------------------------------------------------------------------------
Trevor J. Harris					ukc!trevan!trevor
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jan 90 08:41:05 -0500
From:      schoff@psi.com (Martin L. Schoffstall)
To:        tcp-ip@nic.ddn.mil, opus.cray.com!santa@uu.psi.com
Subject:   Re:  SNMP Product Overview (RFC)
The NIC Vendor's guide does contain a section on network management
products, NYSERNet Inc's (Now PSI's) SNMP distribution has been
registered there for well over a year.

Marty
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 90 00:43:52 GMT
From:      zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!roy@tut.cis.ohio-state.edu  (Roy Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   How best to distribute files?

	This is only marginally related to tcp-ip, but I couldn't think of a
better place, so here goes.  I'm setting up an anonymous ftp server to
distribute various bits of software.  Much of it will be in the form of (L-Z)
compressed tar files.  I expect the majority of the people using the server
will have Unix, but not all and I don't want to needlessly shut out those who
don't.  So, my question is, how universal is this format?  Are there readily
available programs for VMS, Macintosh, MS-DOS, etc, that can read tar.Z
files?  Is there some other more universal format I should consider?
-- 
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"
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jan 90 10:48:43 -0500
From:      schoff@psi.com (Martin L. Schoffstall)
To:        opus.cray.com!santa@uu.psi.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  SNMP Product Overview (RFC)

Absolutely! Everyone should be encouraged to register SNMP products and
everything else related to TCP/IP products there.  In running NYSERNet and now
CAPNet we send the vendors guide to every new Internet site the joins
the networks as a reference document for determining their options.

In Consumer Union nomenclature, I would denote The Guide as "Best Buy".

Marty
-----------------------


>Hummmm. You are correct. There is an entry in The Guide for SNMP, the NYSERNet
>product (section 2.23). But we should encourage all vendors to include SNMP
>info in The Guide. I believe The Guide is about due for a revision - the 
>current Guide is dated February, 1989.
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 90 02:31:14 GMT
From:      cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!attcan!darkover!seachg!jalsop@tut.cis.ohio-state.edu  (John Alsop)
To:        tcp-ip@nic.ddn.mil
Subject:   network print spooling
Are the sources for network print spooling programs such as rlpdaemon, rlp,
rlpstat, etc. in the public domain?

If so, where can I get a copy from?

Thanks,

-- 
John Alsop

Sea Change Corporation
1100 Central Parkway W., Suite 38
Mississauga, Ontario, Canada L5C 4E5
Tel: 416-272-3881 Fax: 416-272-1555
UUCP: ...!uunet!attcan!darkover!seachg!jalsop
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 90 02:41:30 GMT
From:      zaphod.mps.ohio-state.edu!math.lsa.umich.edu!emv@tut.cis.ohio-state.edu  (Edward Vielmetti)
To:        tcp-ip@nic.ddn.mil
Subject:   map name (or addr) to regional network ?

I have a list of internet hosts which I would like to group
geographically or logically by regional network.  I.e. umich.edu and
ohio-state.edu hosts would be grouped together (CICnet), uky.edu and
gatech.edu (Suranet), etc.  I suppose this would actually be done
according to IP addresses.

Thanks for any info.

--Ed
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jan 90 07:47:13 EST
From:      "Doug Sewell" <DOUG%YSUB.BITNET@CORNELLC.cit.cornell.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   How best to distribute files?
There are MSDOS versions of Compress and Tar.  I can't speak for
other operating systems.

An alternative you might consider is 'ZOO' by Rahul Deszi.  This is
similar to ARC, ZIP, and many other common PC bundle-and-compress
programs, but has been ported to Unix, MSDOS, AmigaDos, VM/SP, VMS,
and I-don't-know how many other environments.  If I remember cor-
rectly, one of the requirements for implementations of ZOO (source
in C is available from SIMTEL20) is that files must be compatible
across all implementation platforms.

Doug
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jan 90 09:43:13 CST
From:      santa@opus.cray.com (Dave Sadler)
To:        schoff@psi.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  SNMP Product Overview (RFC)
Hummmm. You are correct. There is an entry in The Guide for SNMP, the NYSERNet
product (section 2.23). But we should encourage all vendors to include SNMP
info in The Guide. I believe The Guide is about due for a revision - the 
current Guide is dated February, 1989.

Dave
-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 90 04:45:30 GMT
From:      haven!umbc3!tron!carson@ames.arc.nasa.gov  (Dana Carson)
To:        tcp-ip@nic.ddn.mil
Subject:   subnet faking

   Is it possible to have one system with one ethernet port on two
subnets?  We have a class B network address divided up into subnets
(eight bits for subnet).  We have a different subnet number from other
parts of the company in the area but due to the way the network is laid
out the ethernet is bridged so it's all one network.  Can I use some
magic when I configure a system to make it talk to both subnets on the
same device so it can be the gateway between them?

--
Dana Carson
Westinghouse Electronic Systems Group  Mail Stop 1615
UUCP:carson@tron.UUCP 
     ...!uunet!tron!carson
AT&T: (301) 765-3513
WIN: 285-3513
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jan 90 14:13 EST
From:      Amin Shafie - Univ of Cincinnati Comp Ctr <SHAFIE@UCBEH.SAN.UC.EDU>
To:        386USERS@TWG.COM, 9370-L%HEARN.BITNET@MITVMA.MIT.EDU, AAI@ST-LOUIS-EMH2.ARMY.MIL, ADA-SW@WSMR-SIMTEL20.ARMY.MIL, ADVISE-L%CANADA01.BITNET@CUNYVM.CUNY.EDU, ADVSYS@EDDIE.MIT.EDU, AG-EXP-L%NDSUVM1.BITNET@CUNYVM.CUNY.EDU, AI-ED@SUMEX-AIM.STANFORD.EDU, AIDSNEWS%RUTVM1.BITNET@CUNYVM.CUNY.EDU, AIList@AI.AI.MIT.EDU, AIX-L%BUACCA.BITNET@MITVMA.MIT.EDU, ALLIN1-L@CCVM.SUNYSB.EDU, AMETHYST-USERS@WSMR-SIMTEL20.ARMY.MIL, AMIGA-RELAY@UDEL.EDU, ANDREW-DEMOS@ANDREW.CMU.EDU, ANTHRO-L%UBVM.BITNET@CUNYVM.CUNY.EDU, apollo@UMIX.CC.UMICH.EDU, ARMS-D@XX.LCS.MIT.EDU, ARPANET-BBOARDS@MC.LCS.MIT.EDU, ASM370%UCF1VM.BITNET@CUNYVM.CUNY.EDU, AVIATION@MC.LCS.MIT.EDU, AVIATION-THEORY@MC.LCS.MIT.EDU, bicycles@BBN.COM, BIG-LAN@SUVM.ACS.SYR.EDU, BIG-LAN@SUVM.BITNET, BIOTECH%UMDC.BITNET@CUNYVM.CUNY.EDU, BIOTECH@UMDC.UMD.EDU, BITNEWS%BITNIC.BITNET@CUNYVM.CUNY.EDU, BMDP-L%MCGILL1.BITNET@CORNELLC.CCS.CORNELL.EDU, bug-1100@SUMEX-AIM.STANFORD.EDU, CA@THINK.COM, CADinterest^.es@XEROX.COM, CAN-INET@MC.LCS.MIT.EDU, cisco@SPOT.COLORADO.EDU
Subject:   SIGUCCS CALL for PARTICIPATION
<--------------------------------------------------------------------
< 
<                 SIGUCCS User Services Conference XVIII
<                        Call For Participation
<
<                  New Centerings in Computing Services
< 
<                  September 30 through October 3, 1990
<
<                           Westin Hotel
<                         Cincinnati, Ohio
< 
<
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<< 
<<Attention Directors, Managers, Analysts, Consultants, Programmers,
<<Technical Writers, Trainers, and Librarians!
<< 
<<The higher education computing scene in the 1990s will present exciting
<<challenges.  To accommodate users' needs, computing service organizations
<<are now visibly transforming in function and structure.  The widespread
<<adoption of personal computing by all disciplines, the increasing demand
<<for desktop access to shared resources, the growth in demand for
<<supercomputing capabilities, and the proliferation of powerful desktop
<<workstations exert irresistible forces on central computing services.
<<In response, the central site grows exponentially in staff and machinery
<<at one academic institution; at another, the computing center is disbanded
<<to provide distributed computing!  At some sites increasing specialization
<<is urged; at others, generalization is required.  Regardless of the
<<transforming strategy adopted by an individual institution, one fact
<<seems clear:  the user is the center toward which all computing services
<<are directed.
<< 
<<SIGUCCS '90 invites you to participate in the examination and discussion
<<of the myriad challenges facing user services professionals as we enter a
<<new decade and of the new centerings computing service organizations are
<<discovering to meet them.  Please join us!
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<<You can Participate
<< 
<<	Presentations
<< 
<<	Papers
<< 
<<	Panel Discussions
<< 
<<	Quick Workshops
<< 
<<	Educational Materials Competition
<< 
<<	Newsletter Competition
<< 
<<	Technical Writing Competition
<< 
<<	Documentation Display
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<< 
<< 
<<Important Dates
<< 
<<	March 1, 1990		Presentation proposals due
<<	April 1, 1990		Notification of proposal acceptance
<<	May 1, 1990		Final Papers due
<<	June 1, 1990		Newsletter entries due
<<	June 1, 1990		Technical writing entries due
<<	June 15, 1990		Notification of paper/panel acceptance
<<	September 1, 1990	Deadline for materials for
<<				documentation display
<< 
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<<Presentation Topic Areas
<< 
<< 
<<Information Exchange Technology
<< 
<<Information exchange may well be the most important computing
<<activity of the 1990s. The infrastructure for information delivery, the
<<National Research and Academic Network (NREN), is presently being developed.
<<How do we meet the challenges of a world where the
<<facilitation of information delivery may be a principal user services
<<responsibility?  Topics of particular interest include:
<< 
<<	new approaches to information exchange
<< 
<<	campus activity in implementing information exchange
<<	facilities that comply with emerging international standards
<< 
<<	research and development of computer-mediated information
<<	exchange methods
<< 
<< 
<<Distributed Services
<< 
<<As the role of user services shifts to providing distributed support,
<<we must create new ways of providing traditional services as well as
<<designing new services.  Topics of particular interest include:
<< 
<<	providing support staff in departments and colleges
<< 
<<	funding issues
<< 
<<	if and how to charge back for services
<< 
<<	human networking of distributed support staff
<< 
<<	nonlabor-intensive support strategies
<< 
<<	cooperative efforts with other departments
<< 
<< 
<< 
<<Management Strategies
<< 
<<How do user services managers cooperate with other administrative and
<<academic units that use or provide computing resources?  How do they
<<meet the many and diverse demands?  Topics of particular interest include:
<< 
<<	reorganization
<< 
<<	interaction with faculty advisory groups
<< 
<<	delegating and distributing responsibility
<< 
<<	coordinating university computing resources
<< 
<<	staff professional development
<< 
<< 
<<Marketing your Services
<< 
<<Changing roles may require changing your services and, often, your image on
<<campus as you provide new services to new users.  Topics of particular in-
<<terest include:
<< 
<<	promotional strategies
<< 
<<	conducting market research
<< 
<<	designing services for unique or special audiences
<< 
<< 
<< 
<<Strategies for Small Schools
<< 
<<How can a small liberal arts college have distributed user services and
<<centralized user services?  How do distributed and centralized services work
<<together to provide computing services beyond word processing?  The
<<sciences have become computer literate; now, how do we reach out  from the
<<center to the humanities and fine arts?  Are we getting out of the
<<office and into the trenches?  Are we making too many "house calls"?
<<Should we make them at all?
<< 
<< 
<<Security and Ethics
<< 
<<As electronic mail and conferencing become more popular, computing
<<systems are widely accessible to more users.  How secure should academic
<<computing resources be?  What are the ethical guidelines provided for users
<<of electronic mail and conferencing systems?  Topics of particular interest
<<include:
<< 
<<	promoting responsible and ethical use of computing resources
<< 
<<	security strategies
<< 
<<	adopting an ethics policy
<< 
<< 
<<Serving New Audiences
<< 
<<People from the humanities, the arts, and other traditionally nontechnical
<<disciplines are discovering that computers can help in areas other than
<<word processing.  In an increasingly proactive stance in the central
<<computing facility, what do we do to attract and support these new audi-
<<ences?  Topics of interest include:
<< 
<<	providing information about off-the-shelf specialized
<<	programs for music, fine arts, and the humanities
<< 
<<	facilitating technical support of nontraditional areas
<< 
<<	serving the computing beginner who wants to do
<<	sophisticated tasks
<< 
<< 
<<Consulting, Training, and Documentation
<< 
<<Supporting those who use the computing resources that we provide re-
<<mains an important responsibility of user services organizations.  Topics
<<of particular interest include:
<< 
<<	new approaches to training
<< 
<<	providing distributed consulting
<< 
<<	documentation distribution services
<< 
<< 
<<and/or other topics that would be of interest to your national
<<and international colleagues
<< 
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<<Submitting Proposals
<< 
<< 
<<Submit proposals via electronic mail to:
<< 
<<	SIGPAPER@OHSTVMA.BITNET or
<< 
<<	SIGPAPER@OHSTVMA.IRCC.OHIO-STATE.EDU
<< 
<<If you do not have access to electronic mail, send a printed copy to:
<< 
<<		Susan Jenkins Saari
<<		Instruction and Research
<<		Computer Center
<<		The Ohio State University
<<		1971 Neil Avenue
<<		Columbus, OH 43210
<< 
<<		phone:      (614) 292-4843
<<		fax:      (614) 292-7081
<< 
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<<Accepted Proposals
<< 
<< 
<<Proposals must be received by March 1, 1990.  Any submisson received
<<after this date will not be considered by the Program Committee.  You will
<<be notified of the Program CommitteeUs decision by April 1, 1990.  If your
<<proposal is accepted, you will be asked to submit a full paper by May 1,
<<1990.  Any papers received after this date will not be considered.  You will
<<be notified of the Program CommitteeUs decision by June 15, 1990.
<< 
<<If your presentation is accepted, SIGUCCS is depending on you.  If you are
<<ker to make your presentation (not a substitute presentation).
<< 
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<< 
<<How to Participate
<< 
<< 
<<Proposals
<< 
<<For each proposal, include your name, title, affiliation, mailing ad-
<<type of  proposal (presentation or panel discussion) and its topic area.
<<In addition, you must enclose the proper materials from the following
<<requirements list:
<< 
<<Description
<< 
<<Papers		Papers will be presented in 20-minute ntervals, with
<<		three papers scheduled per 90-minute session. Speakers'
<<		papers will be published in the conference proceedings.
<< 
<<Panels		Panels will be in-depth treatments of a single topic by
<<		two to four speakers from at least two different schools,
<<		coordinated by a moderator.  Allow ample time for audience
<<		discussion.  Abstracts for panels should be submitted
<<		as a unit by the person who wishes to act as a moderator.
<<		Panelists' papers will be published in the conference
<<		proceedings.
<< 
<<Quick Workshops	Quick workshops provide 90-minute overviews of new technolo-
<<		gies, innovative applications, and creative strategies
<<		for addressing the needs of computer users on campus.
<< 
<< 
<<Requirements
<< 
<<Papers		A 250- to 300-word abstract of the paper.  Acceptance of
<<		a proposal does not automatically ensure acceptance
<<		of a paper for presentation; you must submit a full
<<		paper to be considered for the conference program.
<< 
<<Panels		A 250- to 300-word description of the panel, including
<<		each panelist's name, title, affiliation, and presentation
<<		topic.  Acceptance of a panel description does not
<<		automatically ensure acceptance of the panel for
<<		presentation; each panelist must submit a full paper
<<		to be considered for the conference program.
<< 
<<Quick Workshops	A one- to two-page outline of the presentation and a
<<		10-minute videotape excerpt from the proposed presentation.
<<		Acceptance of a proposal does not automatically ensure
<<		acceptance of a workshop for presentation; you must
<<		submit a full paper to be considered for the conference
<<		program.  Only three or four presentations will be a
<<		ccepted in this category because it is highly competiive.
<< 
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<< 
<<Other Ways to Participate
<< 
<<Education and Training Materials Competition
<< 
<<Interest in and the importance of user education and training have grown
<<with each SIGUCCS conference.  The 1990 SIGUCCS Conference offers,
<<for the first time, competition for user education and training materials for
<<colleges and universities.*  We invite you to submit no more than two
<<entries in any or all of the following categories: curriculum catalog, class-
<<room printed materials, or self-contained printed tutorials.  Although the
<<first year of this competition includes only printed materials, we would like
<<to know if there is an interest in expanding our future competitions to
<<include video, audio, and computer-based tutorials.  Deadline for entry is
<<June 1, 1990.  For more details and an entry form, or to address the issue
<<of future competition categories, contact:
<< 
<<		Diane Jung-Gribble
<<		Indiana University
<<		750 North State Road 46 Bypass
<<		Bloomington, IN  47405
<< 
<<		(812) 855-0962
<< 
<< 
<<		JUNG@IUBACS.BITNET
<<		JUNG@JADE.BACS.INDIANA.EDU
<< 
<<*NOTE:  this competition is not open to commercial materials
<< 
<<Newsletter Competition
<< 
<<Winning an award in the SIGUCCS Newsletter Competition is a mark of
<<distinction for your institution, and for your editors, writers,artists,and
<<designers.  You will be asked to submit two consecutive issues published
<<between June 1989 and May 1990.  Deadline for entry is June 1, 1990.
<<For more details and an entry form, contact:
<< 
<<		Jess Anderson
<<		Madison Academic Computing Center
<<		University of Wisconsin-Madison
<<		1210 West Dayton Street
<<		Madison, WI   53706
<< 
<<		(608) 263-6988
<< 
<<		ANDERSON@MACC.WISC.EDU
<<		ANDERSON@WISCMACC.BITNET
<< 
<< 
<<Technical Writing Competition
<< 
<<If you have written or published a particularly good article in a computing
<<newsletter, enter it in the Technical Writing Competition.  Each computing
<<center may enter one article.  Deadline for entry is June 1,1990.  To obtain
<<entry forms and more details, contact:
<< 
<<		Donald J. Montabana
<<		University of Pennsylvania
<<		Computing Resources Center
<<		1202 Blockley Hall
<<		Philadelphia, PA  19104-6021
<< 
<<		(215) 898-9085
<< 
<<		MONTABANA@A1.RELAY.UPENN.EDU
<< 
<< 
<< 
<<Documentation Display
<< 
<<The documentation room will feature an online system for submitted
<<documentation.  Conference attendees who have BITNET or INTERNET
<<access will be able to email documentation to their university or college.
<<Documentation may be submitted electronically to DOCUMENT@MIAMIU,
<<by hardcopy, or diskette (IBM or Mac formatted) and must be received
<<before September 1, 1990.  Direct inquries to:
<< 
<<		Al Kaled
<<		Academic Computing Services
<<		Miami University
<<		Oxford, OH  45056
<< 
<<		(513) 529-6226
<< 
<<		AK75STAF@MIAMIU
<< 
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<< 
<<More Information
<< 
<< 
<<General Information
<
<<Amin Shafie, Conference Chair
<<University of Cincinnati
<< 
<< 
<<		e-mail:		SHAFIE@UCBEH.BITNET
<< 
<<		phone:		(513) 556-9001
<< 
<<		fax:		(513) 556-0035
<< 
<< 
<<Call for Participation
<<Susan Jenkins Saari, Program Chair
<<The Ohio State University
<< 
<<		e-mail:		SIGPAPER@OHSTVMA.BITNET
<< 
<<		phone:		(614) 292-4843
<< 
<<		fax:		(614) 292-7081
<< 
<< 
<<Registration
<<Ken Maccarone, Registration Chair
<<University of Cincinnati
<< 
<<		e-mail:		MACCARON@UCBEH.BITNET
<< 
<< 
<<		phone:		(513) 556-9098
<<		fax:		(513) 556-0035
<< 
<< 
<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
<< 
<< 
<<ACM SIGUCCS
<< 
<<The Association of Computing Machinery's (ACM) Special Interest Group
<<for University and College Computing (SIGUCCS) is one of ACM's
<<organizational units devoted to the technical activities of its members.
<<SIGUCCS provides a link for guidance and the interchange of ideas among
<<computing professionals in the full range of small to large institutions.
<<Its newsletter, annual conferences, and workshops promote the discussion
<<of mutual problems. networks, user services, and computer center management.
<<This SIGUCCS conference emphasizes practical ways to improve services for
<<those who use university and college computing centers.


Amin Shafie
Assistant Director
Academic Computing Services                UCBEH::SHAFIE
University of Cincinnati                   SHAFIE@UCBEH.SAN.UC.EDU
ML 088                                     SHAFIE@UCBEH.BITNET
Cincinnati, Ohio  45221
(513) 556-9022
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jan 90 16:28:16 CST
From:      Mike Rackley <RACKLEY%MSSTATE.BITNET@CORNELLC.cit.cornell.edu>
To:        <tcp-ip@sri-nic.arpa>
Subject:   Whose bridges support SNMP?
We are contemplating a change in bridge vendors from Retix to some other
company.  If we do so, we would like to go to a bridge that can be
monitored/managed by some of the various SNMP packages that are available.
We have looked at the Calbetron NB series bridge but have been told
that it uses Cabletron's own proprietary protocol for management.  We
were also told that Cabletron would supply us the MIB, but we would
have to "write some code" to actually be able to manage these boxes
via SNMP.  Does anyone have any idea how much code we are talking about
to accomplish this?

Does anyone have any recommendations for SNMP capable ethernet bridges
for under $3,000 per copy?

At this point in the evolution of SNMP, is it realistic to expect to be
able to purchase a single SNMP management package such as the one from
SUN, or the one from NYSERnet, or the one from Jeff Case's company
and be able to manage ethernet bridges/cisco terminal servers/
proteon routers/Unix boxes?

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
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      Thu, 11 Jan 90 16:01:48 EST
From:      mep@aqua.whoi.edu (Michael E. Pare)
To:        haven!umbc3!tron!carson@ames.arc.nasa.gov, tcp-ip@nic.ddn.mil
Subject:   Re:  subnet faking
I don't know what type of devices you have but I do that on one of our
Proteon gateways.  The two subnets are normally joined by two of these IP
routers.  The networks are also joined together by bridges for all other
protocols.  If one of the routers fails, I shut the IP filtering off on the
bridges, and add the interface address of the broken gateway to the
good gateway on the same ethernet interface.  The bridges make the system
look like one ethernet and the gateway handles the routing for the IP
packets.
-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 90 12:47:13 GMT
From:      DOUG@YSUB.BITNET ("Doug Sewell")
To:        comp.protocols.tcp-ip
Subject:   How best to distribute files?

There are MSDOS versions of Compress and Tar.  I can't speak for
other operating systems.

An alternative you might consider is 'ZOO' by Rahul Deszi.  This is
similar to ARC, ZIP, and many other common PC bundle-and-compress
programs, but has been ported to Unix, MSDOS, AmigaDos, VM/SP, VMS,
and I-don't-know how many other environments.  If I remember cor-
rectly, one of the requirements for implementations of ZOO (source
in C is available from SIMTEL20) is that files must be compatible
across all implementation platforms.

Doug

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Jan 90 08:22:44 -0800
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        clefor@secola.columbia.ncr.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: SNMP standards
I think your message is more appropriately addressed to the
snmp@nisc.nyser.net discussion group.  Let's move this thread there.

/mtr
-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 90 22:27:22 GMT
From:      zaphod.mps.ohio-state.edu!swrinde!emory!hubcap!ncrcae!secola!clefor@tut.cis.ohio-state.edu  (Cheryl LeFor)
To:        tcp-ip@nic.ddn.mil
Subject:   SNMP standards
Hi!

I have some questions about some SNMP standards and would appreciate any
feedback from "those in the know."

I am writing some applications that will communicate with an SNMP agent in
order to retrieve mib variables.  In one case, I retreive the mib Interface
Table entries.  My question concerns the ifPhysAddress field of the ifTable.

According to the RFC which describes the mib (RFC 1066), ifPhysAddress is
defined as such:

	OBJECT: 	ifPhysAddress	{ ifEntry 6 }
	Syntax: 	OCTET STRING
	Definition:
		The interface's address at the protocol layer immediately "below"
		IP in the protocol stack.

My question is: 	What is the standard format for this octet string?
                	6 byte phys addr:	080014118562
            OR, 	character string:	"08:00:14:11:85:62"

This question also pertains to the Address Translation Table atPhysAddress
field (OCTET STRING).

With the particular SNMP agent I'm using, ifPhysAddress came back in the 
"08:00..." form, and atPhysAddress came back in the 6 byte form.

One last question...
(This is probably more for a Nysernet dude but here goes..)
WHY are the components of the mib path defined as unsigned longs?  Isn't that
a lot of space for a number which is usually a one digit number?

			iso.org.dod.internet.mgmt.mib
	i.e.:	1.3.6.1.2.1   would have 6 unsigned longs.

	Thanks for your time!!
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 90 22:28:16 GMT
From:      RACKLEY@MSSTATE.BITNET (Mike Rackley)
To:        comp.protocols.tcp-ip
Subject:   Whose bridges support SNMP?

We are contemplating a change in bridge vendors from Retix to some other
company.  If we do so, we would like to go to a bridge that can be
monitored/managed by some of the various SNMP packages that are available.
We have looked at the Calbetron NB series bridge but have been told
that it uses Cabletron's own proprietary protocol for management.  We
were also told that Cabletron would supply us the MIB, but we would
have to "write some code" to actually be able to manage these boxes
via SNMP.  Does anyone have any idea how much code we are talking about
to accomplish this?

Does anyone have any recommendations for SNMP capable ethernet bridges
for under $3,000 per copy?

At this point in the evolution of SNMP, is it realistic to expect to be
able to purchase a single SNMP management package such as the one from
SUN, or the one from NYSERnet, or the one from Jeff Case's company
and be able to manage ethernet bridges/cisco terminal servers/
proteon routers/Unix boxes?

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

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 90 22:48:59 GMT
From:      nis!quest!ssb@UMN-CS.CS.UMN.EDU  (Scott S. Bertilson)
To:        tcp-ip@nic.ddn.mil
Subject:   VJ compressed SLIP auto-conf added to SunOS-4 driver

  I've added the automatic compressed client recognition to
the SunOS-4 SLIP driver distributed with Van Jacobson's
beta release.  It works fine with uncompressed clients, but
I haven't tested it with compressed clients because I'm
still hacking compression into KA9Q NET.  The changes are
fairly straightforward, so I feel pretty confident that I
didn't break anything.  I'd be happy to e-mail the changes
to anyone who'd like them.
-- 

Scott S. Bertilson   ...scott@poincare.geom.umn.edu
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 90 23:27:09 GMT
From:      mccc!labii!collier@princeton.edu  (Todd Collier)
To:        tcp-ip@nic.ddn.mil
Subject:   UNIX NETWORKING POSITION

SPECTRUM TECHNOLOGY GROUP is looking for a UNIX, DATA COMMUNICATIONS SPECIALIST

Spectrum Technology Group, Inc. specializes in database technology. We offer
consulting and educational services with an emphasis on relational technology.
Our headquarters is located in NJ, with three other offices in Tampa, Orlando,
and DC. We are a ten year old growth oriented company with an emphasis upon
team building. We currently need:

DATA COMMUNICATIONS SPECIALISTS WITH STRONG UNIX BACKGROUND

You will discover what an existing network will do and find solutions to
update the changes needed to expand this massive application. You will work
in a team and be the liaison to the client. Must have a diplomatic manner!
An understanding of the politics of change is essential. This is a high
visibility position. These skills are key:

		-UNIX, C
		-LANS & WANS (ex: Datakit, Starlan, TCP-IP, X.25 protocols)
		-A 4GL database would be a plus (Oracle, Informix, Sybase)
		-May need to bridge various architectures

Write or call to get in on the beginning of a long term solution:

	Spectrum Technology Group, Inc.
	1250 Rt. 28
	North Branch, NJ  08876
	attn: Todd A. Collier
	
ph:(201)725-4000
uunet!murphy!spectr!todd    or
uunet!labii!collier
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      11 Jan 90 23:39:42 GMT
From:      swrinde!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!attcan!ncrcan!becker!bdb@ucsd.edu  (Bruce Becker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Sources for TCPIP.
In article <50714@bbn.COM> clements@BBN.COM (Bob Clements) writes:
|In article <m0gl9Ll-0001UEC@utower.gopas.sub.org> fischer@utower.gopas.sub.org writes:
|>Get the KA9Q Sources, they are PD and written for MSDOS.
|
|NO, NO, NO, NO, NO!
|
|The KA9Q sources are NOT PD.
|They are copyrighted, but are freely copyable for Amateur Radio and
|educational institutions.  For other use, contact the author.
|
|There are versions for MSDOS, Unix and a buncha other systems.

	I wonder if the Unix version will support
	BSD-type socket interface?


-- 
  \\\\	 Bruce Becker	Toronto, Ont.
w \66/	 Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu
 `/v/-e	 BitNet:   BECKER@HUMBER.BITNET
_<  \_	 "Head-slam me, Jesus, on the turnbuckle of life" - Godzibo
-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Jan 90 10:41:02 PST
From:      @atc.boeing.com:slm@wsc-sun (Shamus McBride)
To:        tcp-ip@nic.ddn.mil
Subject:   tcp port numbers
Is there some organization or "official" list of tcp port uses above
256 (last one specified in RFC1010) or is /etc/services the best
one can hope for?

--
Shamus Mc Bride		
Employer: Boeing Computer Services
Email:    slm%wsc-sun@atc.boeing.com  (static routers)
 or  :    slm@wsc-sun.boeing.com      (domain routers)
 UUCP:    uw-beaver!uw-june!bcsaic!wsc-sun!slm
Voice:    (206) 865-5047
US mail:  MS 7A-35/Boeing Computer Services/P.O.Box 24346/Seattle, WA 98124-0346
DISCLAIMER: I speak for myself. The opinions expressed above do not
	    necessarily reflect those of The Boeing Company.
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Jan 90 08:42:13 EST
From:      Brian Holmes <BHOLMES%CMS.CC.WAYNE.EDU@CORNELLC.cit.cornell.edu>
To:        TCP/IP newsgroup <TCP-IP@SRI-NIC.ARPA>
Subject:   Re: Whose bridges support SNMP?
ACC's ethernet bridges/routers support SNMP.  FYI

                        Brian Holmes
                        UCC Operating Systems & Communications

PHONE:    (313) 577-3750  FAX=577-5626          Wayne State University
BITNET:   BHOLMES@WAYNEST1                      5925 Woodward
INTERNET: BHOLMES@CMS.CC.WAYNE.EDU              Detroit, MI 48202  U.S.A
-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Jan 90 12:17:11 EST
From:      Brad Clements <bkc@omnigate.clarkson.edu>
To:        "Scott S. Bertilson" <nis!quest!ssb@umn-cs.cs.umn.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  VJ compressed SLIP auto-conf added to SunOS-4 driver
Btw, I have modified Clarkson's version of NCSA Telnet to do VJ compression
in slip mode, and also added the auto VJ enable to the Sunos streams driver.

I'm also messing around with Splay tree data compression of packets, so far
I can get about 2700 baud out of a 2400 baud modem.. Not much of an improvement..

But 3270 data streams really get squashed quite a bit..

I also have a Streams PPP driver that I developed, and am using with the PPP
version of KA9Q... when I have a chance I'll add PPP to NCSA Telnet.



| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clutx.bitnet 
| Network Engineer       Clarkson University              (315)268-2292
-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Fri, 12 Jan 90 14:39:01 EST
From:      stev@vax.ftp.com
To:        tcp-ip@nic.ddn.mil
Subject:   UDP checksums on SUNs, a plea for help

(*sigh*)

could som ekind soul please mail me the patches for the currently used SUN
operating systems ( 3.X and 4.X.Y) to apply to the kernel to turn on UDP
checksums for NFS usage? as an added incentive, i will make the list
available for anonymous FTP access after i have compiled it. your help would
be greatly appreciated. i have checked the sun-fixes directory on uunet, and
there does not seem to be any there. i now return you to your normally
scheduled flamage.



stev knowles
stev@ftp.com


-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 90 11:21:36 GMT
From:      ozalp@cu-arpa.cs.cornell.edu  (Ozalp Babaoglu)
To:        tcp-ip@nic.ddn.mil
Subject:   BOLOGNA 90:  An Advanced Course on Distributed Systems

BOLOGNA '90			 		        AN ADVANCED COURSE
						    ON DISTRIBUTED SYSTEMS

		     July 23 -- August 2, 1990
		University of Bologna, Bologna (ITALY)

Lecturers:

Prof. O. Babaoglu, Bologna, Italy
Dr. A. J. Herbert, APM Ltd, UK
Dr. B. Lampson, DEC, USA
Dr. S. J. Mullender, CWI, NL
Prof. R. M. Needham, Cambridge, UK
Prof. M. Satyanarayanan, CMU, USA
Prof. F. B. Schneider, Cornell, USA
Dr. M. D. Schroeder, DEC, USA
Prof. S. Toueg, Cornell, USA
Prof. W. E. Weihl, MIT, USA


OBJECTIVE:   Bologna '90 is the third offering of the Advanced Course on
Distributed Systems.  The two previous offerings were held in Ithaca,
New York (Fingerlakes '89) and Tromso, Norway (Arctic '88).  The
objective of the course is to familiarize practitioners and researchers
with key issues in distributed systems.  The lectures will discuss the
fundamental problems of the area, review known solutions and paradigms,
and show how to apply known theoretical results to the design of
practical systems.  Bologna '90 lecturers are internationally-known
researchers whose interests and experiences span the full range of
distributed computing.


COURSE OUTLINE:

Introduction
	Why distributed systems?  (Schroeder)
	Motivation, requirements, goals, advantages, limitations  (Schroeder)
	Fundamental issues for implementors  (Schneider)

Fundamental Concepts
	Ordering of events, causality, logical clocks  (Babaoglu)
	Stable states, consistent cuts, distributed snapshots  (Toueg)

Communication
	Interprocess communication  (Mullender)
	Remote procedure calls (Mullender)
	Design of high-speed local networks  (Schroeder)

Distributed Services and Access Control
	Design of a distributed name service  (Needham)
	Cryptography-based authentication servers  (Needham)
	Protection and security in distributed systems  (Lampson)

Fault Tolerance
	Agreement, coordination  and commitment  (Babaoglu)
	Reliable clock synchronization  (Schneider, Toueg)
	Replication management (Schneider)

Language Support for Reliable Distributed Applications
	Transactional and other models and their applications  (Weihl)
	Theory of distributed transactions  (Weihl)

Data Storage
	Distributed file system design  (Satyanarayanan)
	Replicated data management  (Toueg)

Methodology
	High-level specifications of distributed applications  (Weihl)
	Derivation of provably-correct distributed programs (Schneider)
	Abstractions for simplifying distributed algorithms  (Toueg)

Distributed Systems Architecture
	Design of high-performance kernels for distributed systems (Mullender)
	The Advanced Networked Systems Architecture (Herbert)

For further information, contact

------
Ozalp Babaoglu				E-mail:	ozalp@dm.unibo.it
University of Bologna
Department of Mathematics
Piazza di Porta S. Donato, 5		TEL:	+39 51 354430
40127 Bologna  ITALY			FAX:	+39 51 354490

------
Ozalp Babaoglu				E-mail:	ozalp@dm.unibo.it
University of Bologna
Department of Mathematics
-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 90 13:06:49 GMT
From:      oli-stl!asylum!karl@decwrl.dec.com  (Karl Auerbach)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SNMP standards
In article <469@secola.Columbia.NCR.COM> clefor@secola.UUCP () writes:
>I have some questions about some SNMP standards and would appreciate any
>feedback from "those in the know."

You really ought to be posting this to snmp@nisc.nyser.net.

>My question is: 	What is the standard format for this octet string?
>                	6 byte phys addr:	080014118562
>            OR, 	character string:	"08:00:14:11:85:62"

The former -- the value is the binary value of the address.  When we
did the SMI we could have defined a special type, but that would have
left an unending need to allocate types for all the different forms of
addresses on all kinds of media.  (In practice, the it really may not
be that much of a problem as lots of things use 48-bit addresses.)

>With the particular SNMP agent I'm using, ifPhysAddress came back in the 
>"08:00..." form, and atPhysAddress came back in the 6 byte form.

Somebody is doing it wrong.  However, you may want to look deeper as
some manager/client-side programs either know that these items are
special and know how to pretty-print them, or delve into the values to
find the most human oriented way to print them.  You might find that
the value is being returned over-the-wire in the "correct" format but
is being pretty-printed for you.

>(This is probably more for a Nysernet dude but here goes..)
>WHY are the components of the mib path defined as unsigned longs?  Isn't that
>a lot of space for a number which is usually a one digit number?

I'm not a PSI (ne Nysernet) dude, but anyway...
Some early SNMP implementations got into trouble by assuming that
object identifier components are a single digit.  Right off the bat
you run into TCP and UDP port numbers as components, and these must be
at least 16 bits (which can map into as many as three bytes in the
ASN.1 encoded object identifier.)  I'm starting to run into equipment
where the number of instances is often in the thousands and a single
byte just doesn't make it.

I sure hope I'm being lucid -- I don't know what spirit is moving me
to read mail at 4am.

				--karl--
				Karl Auerbach
				Epilogue Technology Corp.
				Santa Cruz, California
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 90 13:42:13 GMT
From:      BHOLMES@CMS.CC.WAYNE.EDU (Brian Holmes)
To:        comp.protocols.tcp-ip
Subject:   Re: Whose bridges support SNMP?

ACC's ethernet bridges/routers support SNMP.  FYI

                        Brian Holmes
                        UCC Operating Systems & Communications

PHONE:    (313) 577-3750  FAX=577-5626          Wayne State University
BITNET:   BHOLMES@WAYNEST1                      5925 Woodward
INTERNET: BHOLMES@CMS.CC.WAYNE.EDU              Detroit, MI 48202  U.S.A

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 90 13:52:23 GMT
From:      brf@zip.eecs.umich.edu  (Bill Friday)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: subnet faking
I do not know of any way to configure one ethernet board to have to IP
addresses and be configured to route two subnets that exist on
the same wire ('ifconfig' does not permit that which define the
partameters asociated with the ethernet interface). There is something
you can try that is not very elegent but might work.

Assumptions about your net:
	1 - class 'b' address with netmask 255.255.255.0
	2 - subnet 130.140.80 and subnet 130.140.81 are connected with a
	    bridge and they need to communicate but have no route

Partial solution that might help:
	1 - This will allow direct communication between node
	    130.140.80.10 and 130.140.81.10 that live on the logical
	    network.
	2 - manually update the routing table on 130.140.81.10 with the
	    following:
	    'route add net 130.140.80 130.140.81.10 0'
	3 - manually update the routing table on 130.140.80.10 with the
	    following:
	    'route add net 130.140.81 130.140.80.10 0' 

	The above command will establish a route between the two
	specified hosts. Assume that the above nodes are sun
	fileservers. If the diskless clients had a net mask of 
	255.255.0.0 nfs works fine between the two subnets. Oh yea, the
	metric or hop count equal to zero means that the subnet is on
	the same wire in the above route commands. By routing the net
	through yoiurself it simple puts the packet on the wire. If
	could be simplifies with route defalult to yourself if not
	already used.  You could include the manual route add in 
	your '/etc/rc.local'.


-----------------------------------------------------------------------------
Bill Friday					UUCP: uunet!philabs!brf
Computing Resources				ARPA: brf@philabs.philips.com
Philips Laboratories				Voice (914) 945-6087
Briarcliff Manor, NY 10510
-----------------------------------------------------------------------------
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 90 17:17:11 GMT
From:      bkc@OMNIGATE.CLARKSON.EDU (Brad Clements)
To:        comp.protocols.tcp-ip
Subject:   Re:  VJ compressed SLIP auto-conf added to SunOS-4 driver

Btw, I have modified Clarkson's version of NCSA Telnet to do VJ compression
in slip mode, and also added the auto VJ enable to the Sunos streams driver.

I'm also messing around with Splay tree data compression of packets, so far
I can get about 2700 baud out of a 2400 baud modem.. Not much of an improvement..

But 3270 data streams really get squashed quite a bit..

I also have a Streams PPP driver that I developed, and am using with the PPP
version of KA9Q... when I have a chance I'll add PPP to NCSA Telnet.



| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clutx.bitnet 
| Network Engineer       Clarkson University              (315)268-2292

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 90 22:36:27 GMT
From:      zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!hubcap!ncrcae!ncrlnk!ncrcce!cavanaug@tut.cis.ohio-state.edu  (John David Cavanaugh)
To:        tcp-ip@nic.ddn.mil
Subject:   Public Domain OSPF, EGP
I'm interested in obtaining public domain implementations (with
source code) of OSPF and EGP for Unix.  I'd prefer STREAMS
implementations, but I'll take what I can get.

Please let me know if you know of such a thing.  Thanks.

-- 
John Cavanaugh                       John.Cavanaugh@StPaul.NCR.COM
NCR Comten, Inc.                     (612) 638-2822
2700 Snelling Ave. N
St. Paul, MN  55113                  Standard disclaimer.
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      12 Jan 90 23:59:59 GMT
From:      sdcc6!ee299at@ucsd.edu  (Subhasis Chaudhuri)
To:        tcp-ip@nic.ddn.mil
Subject:   Needed Terminal Servers with Authentication,Billing and SNMP
I would appreciate pointers to Terminal Servers which
support Billing and Authentication and run SNMP

I am aware of the one from cisco systems.

Thanks
PM
-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 90 20:57:31 GMT
From:      kongur!heberlei@ucdavis.ucdavis.edu  (Louis Todd Heberlein)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp port numbers
In article <9001121841.AA25491@shuksan.> slm@wsc-sun (Shamus McBride) writes:
>Is there some organization or "official" list of tcp port uses above
>256 (last one specified in RFC1010) or is /etc/services the best
>one can hope for?
>
>--
>Shamus Mc Bride		
>Email:    slm%wsc-sun@atc.boeing.com  (static routers)
> or  :    slm@wsc-sun.boeing.com      (domain routers)

I too am, and I imagine many others would be too, interested in such a
list.  I see many ports being used which are not mentioned in
/etc/services nor in any other documentation that I have found.


Todd Heberlein
heberlei@kongur.ucdavis.edu	128.120.57.118
-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      13 Jan 90 23:05:51 GMT
From:      unsvax!jimi!herbert!doug@uunet.uu.net  (Doug Phillipson 5-0134)
To:        tcp-ip@nic.ddn.mil
Subject:   Bridges slow down over time.
Running SUNOS 4.0.3

   -----     ----     ---           ---     ----     -----
  |     |___|    |___|   |         |   |___|    |___|     |
  |     |   |    |   |   |  TELCO  |   |   |    |   |     |
   -----     ----     ---           ---     ----     -----
    Sun4    Bridge   Modem         Modem   Bridge     SUN4

        The bridges are Advanced Computer Communications
Model# ACS4030, the modems are NEC 9631 running in synchronous
mode at 9600. The problem:

        When transfering a file between the SUNS (or any other host).
The throughput gradually decreases over time. I.E transferring a one
meg file starts out good then in a little while the modem activity
decreases and I start getting "NFS host not responding" messages
(if using cp with a mounted file system). Or if using rcp the through
put just goes to heck. I have noticed that if lots of requests are
traversing the bridges (lots of separate rcp's or cp's on a mounted NFS)
the throughput stays good. Its as if the bridges like lots of parallel
traffic. Then when most of the rcp's are done the traffic trails off
again and the one or two unfinished copy commands go to crap.

Has anyone seen this problem?
Generally these bridges work well but this confuses me.

Douglas Phillipson (EG&G)
-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 90 00:17:08 GMT
From:      zaphod.mps.ohio-state.edu!uwm.edu!marque!lakesys!deanr@tut.cis.ohio-state.edu  (Dean Roth)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp port numbers

To get a list of assigned numbers (TCP ports, protocols, etc.),
send email to 

	 info-server@sh.cs.net

with the format shown below.  (The subject line is ignored.) 
The request will be filled by a program.
In the body of the message put:

REQUEST: RFC
TOPIC: RFC1010
REQUEST: END

The last time I got the list it was 80KB.

Dean
deanr@lakesys.lakesys.com
-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jan 90 15:35:25 -0800
From:      sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Close re 2MSL
zweig@tut.cis.ohio-state.edu (Johnny Zweig) writes:

>  <deleted> TIME-WAIT is
> a way of making it overwhelmingly likely that losing a single segment
> (that last ack) or spuriously retransmitting a single segment (the FIN)
> won't mess things up.
> 
> Keeping the connection descriptor around for 2 MSL is necessary so that
> I know what sequence numbers and whatnot to use  when I get a retransmission
> of a FIN I have ack'ed during that time.
 
	would it be a "good idea" to set the length of time a connection
	stays in the TIME_WAIT state to a (small) multiple of the smoothed
	round trip time accumulated during the connection's lifetime rather
	than a fixed (larger than necessary almost all of the time) constant?
	i find it hard to believe that the TIME_WAIT interval needs to be
	as large (default is 75 seconds i believe) on an ethernet as it
	does on a WAN from one coast to the other.

	Steven M. Schultz
	sms@wlv.imsd.contel.com

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jan 90 10:35:45 -0500
From:      Frederick E Serr BBNCC 20/666 x2474 <fserr@BBN.COM>
To:        tcp-ip@nic.ddn.mil
Subject:   Reporting MILNET Performance Problems
A few weeks ago several people posted queries regarding apparent
problems with MILNET performance, as measured by the throughput observed
with FTP.  While I cannot comment on their specific complaints (except
to say that it normally is possible to get substantially more than
4 kbits/sec through a connection when all links involved are running
at 56 kbits/sec and both host and network software is properly tuned),
there IS a MILNET Hotline for reporting network difficulties.  MILNET
users experiencing network connectivity or performance problems should
have their host administrator or node site coordinator contact the
MILNET trouble ticket desk (1-800-451-7413).  We ask that users go
through their host administrators, rather than calling the NOC directly,
so that each site has a central focal point for coordinating responses
and follow-up actions.

There is an entire organization devoted to maintaining and improving
the performance of the MILNET.  While the network is constantly monitored
and every attempt made to properly tune the network and proactively
provide additional resources where needed, we often will not be aware of
problems with specific host-host flows unless they are reported.  This
is the best way of ensuring that you get the resources needed to determine
the bottleneck in your communications:  host or network software, line
bandwidth, PSN CPU, etc.

Frederick Serr
Network Analysis Group
BBN Communications

[My apologies if some receive this message twice.  My original send attempt
didn't seem to get through.]

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 90 04:08:52 GMT
From:      wiltzius@lll-lcc.llnl.gov  (Dave P. Wiltzius)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP Close re 2MSL
Can someone explain exactly why TCP requires that one side
of the TCP connection remain active (in TIME_WAIT state)
for 2MSL when the connection is gracefully closed?  I could
not find this explained in the Host Requirements document
nor in RFC793 (not well enough for me, anyway).

Thanks.
  Dave (wiltzius@lll-lcc.llnl.gov)
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jan 90 11:14:49 EST
From:      Scott W. Rogers <rogers@osi540sn.gsfc.nasa.gov>
To:        kongur!heberlei@ucdavis.ucdavis.edu, tcp-ip@nic.ddn.mil
Subject:   Re: tcp port numbers
The Assigned Numbers RFC available from the NIC (nic.ddn.mil) lists
the officially assigned TCP and UDP port numbers.  The /etc/services
file may document additional "commonly" used unix TCP/UCP ports, but
may not be officially assigned.

To have a TCP or UDP port "officially" assigned for a specific use,
you can make a case to jkreynolds@isi.edu or Jon Postel (also of ISI).
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 90 07:57:30 GMT
From:      helios.ee.lbl.gov!ncis.tis.llnl.gov!lance.tis.llnl.gov!kehres@ucsd.edu  (Tim Kehres)
To:        tcp-ip@nic.ddn.mil
Subject:   IMAP 2 Protocol Question
[]

I am in the middle of implementing an mail server that communicates 
with the outside world (clients) via the IMAP 2 protocol as specified 
in RFC 1064.  In the protocol specification, it makes reference in several 
places to a Lisp-like S-expression format.  Not being a Lisp programmer, 
and not finding any other references to this in the RFC, I am not sure what 
such an expression format is to look like.  There are some examples in the 
RFC, but it would be nice if I could find a more formal description prior
to the final coding.  Does anyone know of a more formal description of 
what this format looks like?

In addition, there are a few areas that I am concerned with regarding
this protocol.  They are:

  o  No support in the protocol for the sending of messages.  We will 
     probably get around this by extending the protocol to allow a
     "pass-through" SMTP mode and/or having the server handle the
     queueing of the messages.

  o  There does not seem to be any way for the client to request a list
     of mailbox names that it has access to.  Perhaps I am just missing
     something here?

  o  The IMAP 2 SEARCH command only operates on the currently selected
     mailbox.  Since many mailbox searches will be across multiple mailboxes,
     this ability to perform multiple mailbox searches should probably be 
     present in the server instead of requiring the client to perform the
     multiple identical searches across many mailboxes.  In addition, if the 
     client does not know the names of the mailboxes it has access to (see 
     previous item), this might not even be possible.

By my comments here, please don't think that I am overly critical.  I believe
that it is probably the best of the current internet mailbox protocols.  I
do believe that there are some extentions that may be necessary in order to
produce robust clients and servers.  If there was just some way that we 
could make it look like the X.400 P7 protocol.   :-)   :-)

Has anyone else had any experience implementing either clients or servers
for this protocol?  Did you experience any similiar concerns, and did you
need to provide for any extentions?

Regards,

Tim Kehres
kehres@tis.llnl.gov
-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 90 10:52:24 GMT
From:      mcsun!ukc!icdoc!zmact58@uunet.uu.net  (S J Lacey)
To:        tcp-ip@nic.ddn.mil
Subject:   slip between mvax and a/ux

I'm looking to use slip between a MicroVax II and a MacII running A/UX.

Any information as to the availability of slip for the Mac would be 
gratefully recieved.

--

Steve.

Crypt.
> pull the cord
The room screeches to a halt and the guard rushes in. "Fifty pounds please."
Realising he is in the wrong plot, he leaves with an embarrassed expression 
on his face. <paraphrased from Fish!>

 email :              snailmail :
  sjl@cc.ic.ac.uk      Department Of Computing  | Magnetic Scrolls
  zmact58@doc.ic.ac.uk Imperial College         | 1 Chapel Court
                       180, Queen's Gate        | London SE1 1HH
                       South Kensington
                       London SW7   <My opinions are totally my own, so there!>
-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jan 90 11:15 CET
From:      "jjpansiot"                                 <D32107%FRCCSC21.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Cc:        PANSIOT@FRCCSC21.BITNET
Subject:   How many mailboxes?

  Our University Network is going to be connected to the
  outside world through BITNET, and I am writing a short
  internal paper to discuss the advantages of accessing
  the Internet through Email.
  Anybody can give an estimate of theses  numbers? :
  number of hosts on Internet
  number of mailboxes on Internet
  and even harder:
  Total number of mailboxes reachable through internet
  and connected networks.
  Of course, I don't expect precise numbers.
  Thanks
  Jean-Jacques Pansiot
  Departement d'Informatique, Universite Louis Pasteur
  Strasbourg , France
  E-mail:  D32107@FRCCSC21.bitnet
-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 90 15:20:35 GMT
From:      usc!elroy.jpl.nasa.gov!peregrine!ccicpg!conexch!stanton!donegan@ucsd.edu  (Steven P. Donegan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Bridges slow down over time.
In article <1990Jan13.230551.6884@herbert.uucp>, doug@herbert.uucp (Doug Phillipson 5-0134) writes:
> 
>         When transfering a file between the SUNS (or any other host).
> The throughput gradually decreases over time. 
> 
> Douglas Phillipson (EG&G)

Doug, I would connect a terminal to the console port on the rear of the unit
on the source side (where the file(s) are coming from), and set up the monitor
modes to performance and error modes. The things to look for are re-transmits
on the link side(probably not your problem here) and multilink q's filling up
(which probably is your problem). 9600 baud is really slow for what you are
attempting to do - I always spec a 56k/64k DDS type link for this type of
connection.


-- 
Steven P. Donegan (stanton!donegan)
Area Telecommunications Engineer
Corporate Telecommunications Services
Western Digital Corporation
The opinions expressed here are mine, not Western Digital's.
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 90 15:21:47 GMT
From:      samsung!sol.ctr.columbia.edu!cica!ssw@think.com  (Steve Wallace)
To:        tcp-ip@nic.ddn.mil
Subject:   I'm looking for packet drivers for UB ethernet cards.
Thanks,

Steven Wallace
ssw@lavanix.bacs.indiana.edu
-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 90 15:35:45 GMT
From:      fserr@BBN.COM (Frederick E Serr BBNCC 20/666 x2474)
To:        comp.protocols.tcp-ip
Subject:   Reporting MILNET Performance Problems

A few weeks ago several people posted queries regarding apparent
problems with MILNET performance, as measured by the throughput observed
with FTP.  While I cannot comment on their specific complaints (except
to say that it normally is possible to get substantially more than
4 kbits/sec through a connection when all links involved are running
at 56 kbits/sec and both host and network software is properly tuned),
there IS a MILNET Hotline for reporting network difficulties.  MILNET
users experiencing network connectivity or performance problems should
have their host administrator or node site coordinator contact the
MILNET trouble ticket desk (1-800-451-7413).  We ask that users go
through their host administrators, rather than calling the NOC directly,
so that each site has a central focal point for coordinating responses
and follow-up actions.

There is an entire organization devoted to maintaining and improving
the performance of the MILNET.  While the network is constantly monitored
and every attempt made to properly tune the network and proactively
provide additional resources where needed, we often will not be aware of
problems with specific host-host flows unless they are reported.  This
is the best way of ensuring that you get the resources needed to determine
the bottleneck in your communications:  host or network software, line
bandwidth, PSN CPU, etc.

Frederick Serr
Network Analysis Group
BBN Communications

[My apologies if some receive this message twice.  My original send attempt
didn't seem to get through.]

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      Mon, 15 Jan 90 21:49:24 EST
From:      "Jay Elinsky" <ELINSKY%YKTVMZ.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Resolver implementation
I'm posting this for someone who has read-only access to this list.  He
asks that you post comments to the list.

 I know of two different methods for implementing a resolver, which are
 described below.  I'd like to hear comments on which is preferred
 because of usability, and any problems with either of the schemes.

 Both require a RESOLV.CONF file that contain the standard DOMAIN
 statement and NAMESERVER statements.

 Example:  DOMAIN WATSON.IBM.COM
           NAMESERVER X.X.X.X

 Method I
 --------
 If the host name does not contain a period, append the domain name
 before sending the name to the resolver.

 Example:  PING YORKTOWN  sends  YORKTOWN.WATSON.IBM.COM  to the resolver.
           PING YORKTOWN.WATSON sends YORKTOWN.WATSON to the resolver.

 Advantages:  Simple to implement, simple to understand, only one
              query is ever sent to the name server.

 Method II
 ---------
 Always append the domain name, and gradually remove the first element
 in the DOMAIN statement trying all possibilities.

 Example:  PING YORKTOWN.WATSON.IBM.COM
 would send to the resolver:   YORKTOWN.WATSON.IBM.COM.WATSON.IBM.COM
                       then:   YORKTOWN.WATSON.IBM.COM.IBM.COM
                       then:   YORKTOWN.WATSON.IBM.COM.COM
                       then:   YORKTOWN.WATSON.IBM.COM  (success)
           PING YORKTOWN.WATSON
 would send to the resolver:   YORKTOWN.WATSON.WATSON.IBM.COM
                       then:   YORKTOWN.WATSON.IBM.COM  (success)

 Advantages:  A user could specify part of his domain (like
              YORKTOWN.WATSON), provided that part was in their domain
              tree.

 Disadvantages:  Complicated, the Hosts Requirements RFC says that if
                 this method is implemented that a method must be provided
                 to turn it off, and that all negative queries must be
                 cached to prevent further negative traffic to the DNS.


 Has anybody successfully implemented Method II?  And if so, what kind
 of user feedback have you gotten?

 Daniel M. Barton
 TCP/IP Development
 IBM Corporation
 Research Triangle Park, NC
-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 90 19:39:19 GMT
From:      cs.utexas.edu!usc!brutus.cs.uiuc.edu!zweig@tut.cis.ohio-state.edu  (Johnny Zweig)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Close re 2MSL
wiltzius@lll-lcc.UUCP (Dave P. Wiltzius) writes:

>Can someone explain exactly why TCP requires that one side
>of the TCP connection remain active (in TIME_WAIT state)
>for 2MSL when the connection is gracefully closed?  I could
>not find this explained in the Host Requirements document
>nor in RFC793 (not well enough for me, anyway).

"Gracefully" is in the eye of the beholder.  Recall that there could
be spurious retransmissions of the FIN you sent me which I have ack'ed,
and that I might send you an ack that doesn't get through. TIME-WAIT is
a way of making it overwhelmingly likely that losing a single segment
(that last ack) or spuriously retransmitting a single segment (the FIN)
won't mess things up.

Keeping the connection descriptor around for 2 MSL is necessary so that
I know what sequence numbers and whatnot to use  when I get a retransmission
of a FIN I have ack'ed during that time.

The TIME-WAIT state is there so that a retransmission of the other
guy's FIN segment won't cause a spurious RST segment (i.e. I need the
TCB around so I can figure out that it is merely a retransmission and
not some other scary piece of weirdness) to be transmitted. The only
reason you can get away without going into it (by going from ESTABLISHED
to CLOSE-WAIT to LAST-ACK to CLOSED) is because in that one case you can
only get an acknowledgement of your FIN segment if the other TCP has gotten
your ack of its FIN segment, because that's how the sequence-numbers work out.
A retransmission of the other guy's FIN could still occur after I go into
CLOSED state, but he'll silently ignore the RST I would send in reply to it.
In any case, the setup guarantees that both ends have received ack's of
their FIN segments at least once (unless the network is so bad that the
last ack never gets through even after my 2 MSL wait in TIME-WAIT state).

Is that any less confusing than what's in RFC793?

-Johnny Trying-not-to-be-confusing
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 90 20:24:10 GMT
From:      dvnspc1!tom@burdvax.prc.unisys.com  (Tom Albrecht)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for PD ASN.1 compiler

Anyone have any pointers to such a beast?

-- 
Tom Albrecht
-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      15 Jan 90 21:46:42 GMT
From:      ingea@IFI.UIO.NO (Inge Arnesen)
To:        comp.protocols.tcp-ip
Subject:   Tiny TCP

About two years ago, I came across a small hack on one of the EUUG
(European Unix User Group) distribution tapes by the name of
TINYTCP, a small and very cut-down TCP/IP for downloading the real
thing across the Ether. 

As it happens, I've lost the disk with the file, so I wondered if
anybody out there have a copy of this program ? If you do, please
mail me a note (not the program itself - 60 copies of it would
anger the administration at the University) .


Inge (BoB)  { ingea@ifi.uio.no }
=========================================================================
==   Inge Arnesen, University of Oslo, Norway.                         ==
==                                                                     ==

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 90 01:56:26 GMT
From:      snorkelwacker!usc!samsung!emory!ogicse!blake!Tomobiki-Cho!mrc@tut.cis.ohio-state.edu  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IMAP 2 Protocol Question

Bill Yeager (yeager@SUMEX-AIM.Stanford.EDU) and I are the primary
implementors of IMAP2-ware.  I'll send you a note offline from the
TCP-IP list answering your questions.  You may find that a lot of your
problems are already solved so you.

 _____     ____ ---+---   /-\   Mark Crispin           Atheist & Proud
 _|_|_  _|_ ||  ___|__   /  /   6158 Lariat Loop NE    R90/6 pilot
|_|_|_| /|\-++- |=====| /  /    Bainbridge Island, WA  "Gaijin! Gaijin!"
 --|--   | |||| |_____|   / \   USA  98110-2098        "Gaijin ha doko ka?"
  /|\    | |/\| _______  /   \  +1 (206) 842-2385      "Niichan ha gaijin."
 / | \   | |__| /     \ /     \ mrc@CAC.Washington.EDU "Chigau. Gaijin ja nai.
kisha no kisha ga kisha de kisha-shita                  Omae ha gaijin darou."
sumomo mo momo, momo mo momo, momo ni mo iroiro aru    "Iie, boku ha nihonjin."
uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru    "Souka. Yappari gaijin!"
-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 90 02:49:24 GMT
From:      ELINSKY@YKTVMZ.BITNET ("Jay Elinsky")
To:        comp.protocols.tcp-ip
Subject:   Resolver implementation

I'm posting this for someone who has read-only access to this list.  He
asks that you post comments to the list.

 I know of two different methods for implementing a resolver, which are
 described below.  I'd like to hear comments on which is preferred
 because of usability, and any problems with either of the schemes.

 Both require a RESOLV.CONF file that contain the standard DOMAIN
 statement and NAMESERVER statements.

 Example:  DOMAIN WATSON.IBM.COM
           NAMESERVER X.X.X.X

 Method I
 --------
 If the host name does not contain a period, append the domain name
 before sending the name to the resolver.

 Example:  PING YORKTOWN  sends  YORKTOWN.WATSON.IBM.COM  to the resolver.
           PING YORKTOWN.WATSON sends YORKTOWN.WATSON to the resolver.

 Advantages:  Simple to implement, simple to understand, only one
              query is ever sent to the name server.

 Method II
 ---------
 Always append the domain name, and gradually remove the first element
 in the DOMAIN statement trying all possibilities.

 Example:  PING YORKTOWN.WATSON.IBM.COM
 would send to the resolver:   YORKTOWN.WATSON.IBM.COM.WATSON.IBM.COM
                       then:   YORKTOWN.WATSON.IBM.COM.IBM.COM
                       then:   YORKTOWN.WATSON.IBM.COM.COM
                       then:   YORKTOWN.WATSON.IBM.COM  (success)
           PING YORKTOWN.WATSON
 would send to the resolver:   YORKTOWN.WATSON.WATSON.IBM.COM
                       then:   YORKTOWN.WATSON.IBM.COM  (success)

 Advantages:  A user could specify part of his domain (like
              YORKTOWN.WATSON), provided that part was in their domain
              tree.

 Disadvantages:  Complicated, the Hosts Requirements RFC says that if
                 this method is implemented that a method must be provided
                 to turn it off, and that all negative queries must be
                 cached to prevent further negative traffic to the DNS.


 Has anybody successfully implemented Method II?  And if so, what kind
 of user feedback have you gotten?

 Daniel M. Barton
 TCP/IP Development
 IBM Corporation
 Research Triangle Park, NC

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jan 90 11:05:24 MST
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        tcs@brl.mil
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  tcp port numbers
 >> Sun's NeWS system usurped port 2000
 
Sun also decided to use port 9 (DISCARD protocol) for "copy protection"
of their PC-NFS product.  Is that a low enough port number?  Nothing
like stomping all over convention.  Now I have beaucoup messages from
various blankity-blank Peesee's in a log on our network test machine.
Of course all the other systems on the net get to handle these
interrupts too.

A way to stop this noise is to send the data back to them.  Yuck, yuck.

We could call it "Well Known Socket Protection".

Phil
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jan 90 12:58:39 PST
From:      @atc.boeing.com:slm@wsc-sun (Shamus McBride)
To:        TCP-IP@NIC.DDN.MIL
Subject:   Re: tcp port numbers
I asked a question about tcp port numbers are assigned (my interest was the
256 - 1023 range).

To throw something else into the discussion I awk'ed out the following
two tables (tcp & udp) from all of the /etc/services files I could find
(see note at end).  For the most part the various systems I looked at
were consistant, but there were a couple of differences

    ALL = unicos ultrix sun & yp
 
 tcp:
    7 echo            ALL
    9 discard         ALL
   11 systat          ALL
   13 daytime         ALL
   15 netstat         ALL
   17 qotd            ultrix:unicos
   19 chargen         ultrix:unicos
   20 ftp-data        sun:yp
   21 ftp             ALL
   23 telnet          ALL
   25 smtp            ALL
   37 time            ALL
   42 nameserver      ultrix:unicos # IEN 116
   43 whois           ALL           # usually to sri-nic
   53 domain          ALL           # name-domain server
   57 mtp             ultrix:unicos # deprecated
   77 rje             ALL
   79 finger          ALL
   87 link            ALL
   95 supdup          ALL
  101 hostnames       ALL           # usually to sri-nic 
  102 iso-tsap:tsap   sun:yp:ultrix # for isode (M. Banan)
    # tsap     on ultrix
    # iso-tsap on sun yp yp
  103 x400            sun:yp        # ISO Mail
  104 x400-snd        sun:yp
  105 csnet-ns        sun:yp
  109 pop:pop-2       ALL           # Post Office
    # pop-2 on sun yp yp
    # pop   on ultrix ultrix unicos
  111 sunrpc          ALL
  113 auth            ultrix:unicos
  115 sftp            ultrix:unicos
  117 uucp-path       ALL
  119 nntp            ALL           # Network News Transfer # USENET News Transfer Protocol
  123 ntp             sun:yp        # Network Time Protocol
  144 NeWS            sun:yp        # Window System
  170 print-srv       ultrix        # network PostScript
  201 nqs             yp            # NQS daemon
    # port 607 on unicos
  260 rtape           ultrix        # remote tape from chaos *rsg*
  512 exec            ALL
  513 login           ALL
  514 shell           ALL           # no passwords used
  515 printer         ALL           # experimental # line printer spooler
  520 efs             ultrix:unicos # for LucasFilm
  526 tempo           ultrix:unicos
  530 courier         ALL           # experimental
  531 conference      ultrix:unicos
  532 netnews         ultrix:unicos
  540 uucp            ultrix:unicos # uucp daemon
  543 klogin          yp            # Kerberos authenticated rlogin
  544 kshell          yp            # and remote shell
  556 remotefs        ultrix:unicos # Brunhoff remote filesystem
  570 eval            ultrix        # remote eval service *rsg*
  600 pcserver        yp            # SunIPC
  607 nqs             unicos        # Cray Network Queueing System
    # port 201 on yp
  608 cde             unicos        # Cray Distributed Editor
  750 kerberos        yp            # Kerberos authentication--tcp
  751 kerberos_master yp            # Kerberos authentication
  754 krb_prop        yp            # Kerberos slave propagation
  755 kadmind         yp
  888 erlogin         yp            # Login and environment passing
  906 sample          yp            # Kerberos sample app server
 1109 kpop            yp            # Pop with Kerberos
 1234 mkuserd         yp
 1524 ingreslock      ALL
 2001 lgc_pd          unicos
 2002 lgc_sdsrv       unicos
 2053 knetd           yp            # Kerberos de-multiplexor
 2105 eklogin         yp            # Kerberos encrypted rlogin
 5000 VTVIN           unicos        # bill samayoa / nrao aps virtual tv
 5003 xcwcs           ultrix:yp     # CWCS control socket # experimental
 5004 cwdata          ultrix:yp     # CWCS file transfer socket # experimental
22375 quantic         unicos

 udp:
    7 echo            ALL
    9 discard         ALL
   13 daytime         ALL
   19 chargen         ultrix:unicos
   37 time            ALL
   39 rlp             ultrix:unicos # resource location
   42 name            sun:yp
   53 domain          ALL
   67 bootp           ultrix        # boot program server
   69 tftp            ALL
  111 sunrpc          ALL
  153 sgmp            ultrix        # 
  161 snmp            ultrix        # 
  162 snmp-trap       ultrix        # 
  512 biff            ALL
  513 who             ALL
  514 syslog          ALL
  517 talk            ALL
  518 ntalk           ultrix:unicos
  520 route           ALL
  525 timed           ultrix:unicos
  533 netwall         ultrix:unicos # -for emergency broadcasts
  550 new-rwho        sun:unicos:yp # experimental
  560 rmonitor        sun:unicos:yp # experimental
  561 monitor         sun:unicos:yp # experimental
  704 elcsd           ultrix        # errlog
  750 kerberos        yp            # Kerberos authentication--udp
  751 kerberos_master yp            # Kerberos authentication
  752 passwd_server   yp            # Kerberos passwd server
  753 userreg_server  yp            # Kerberos userreg server
  999 applix          ultrix        # Alis
 2049 nfs             unicos        # Network File System

 ----------------------------------------------------------------------
 "ultrix" = ULTRIX V3.1 & Ultix-32 V3.1 (Rev. 9).
 "sun" = SunOS Release 4.0.3.
 "unicos" = UNICOS Release 5.0.13
 "yp" = what I ripped off of local yellow pages servers.
------------------------------------------------------------------------
If people want to mail *ME* some /etc/services from some other systems
and there is enough interest I could republish this list. My interest
has been looking at colisions in the address space.


--
Shamus Mc Bride		
Employer: Boeing Computer Services
Email:    slm%wsc-sun@atc.boeing.com  (static routers)
 or  :    slm@wsc-sun.boeing.com      (domain routers)
 UUCP:    uw-beaver!uw-june!bcsaic!wsc-sun!slm
Voice:    (206) 865-5047
US mail:  MS 7A-35/Boeing Computer Services/P.O.Box 24346/Seattle, WA 98124-0346
DISCLAIMER: I speak for myself. The opinions expressed above do not
	    necessarily reflect those of The Boeing Company.
-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Tue 16 Jan 90 13:20:56-PST
From:      William "Chops" Westfield <BILLW@MATHOM.CISCO.COM>
To:        tcs@BRL.ARPA
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re:  tcp port numbers
> Is there some organization or "official" list of tcp port uses above
> 256 ...

Come on people.  Port numbers above 255 are BY DEFINITION un-official.
I could see some value in making the "official" space larger, but you
still need a whole bunch of numbers for the other side of the connection.

BillW
-------
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jan 90 10:22:20 EST
From:      Terry Slattery (SECAD) <tcs@BRL.MIL>
To:        Shamus McBride <@atc.boeing.com:slm@wsc-sun>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  tcp port numbers
> Is there some organization or "official" list of tcp port uses above
> 256 ...

I have been asking the same question of Jon Postel recently.  It seems that
Sun's NeWS system usurped port 2000, which has historically been used by
ttcp (a program to test TCP/UDP thoughput).  Upon discovering this I wanted
to have a published port number so that it wouldn't happen again.
Unfortunately, the number czar only handles low numbered ports.  Something
needs to be done about registering ALL port numbers so that this doesn't
continue to happen.

Personally, I don't see why the existing registration procedures can't be
applied to all port numbers.  Are there any significant problems in doing
this?

	-tcs
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jan 90 12:17 N
From:      <JAAP%HROEUR5.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   list removel

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Tue, 16 Jan 90 15:39:01 EST
From:      Doug Nelson <08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu>
To:        Jay Elinsky <ELINSKY@YKTVMZ>, "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>
Subject:   Re: Resolver implementation
> I know of two different methods for implementing a resolver, which are
> described below.  I'd like to hear comments on which is preferred
> because of usability, and any problems with either of the schemes.
>
> Method I
> --------
> If the host name does not contain a period, append the domain name
> before sending the name to the resolver.
>
> Method II
> ---------
> Always append the domain name, and gradually remove the first element
> in the DOMAIN statement trying all possibilities.
>
> Has anybody successfully implemented Method II?  And if so, what kind
> of user feedback have you gotten?

I have edited out the examples from Dan's comments above.

We don't use method II, but my biggest concern with it is the potential
for false hits, or the potential for hiding a domain name.  For example,
say I have a "com" (e.g. Communications) department.  And say they name
their Big Blue system "ibm" (for lack of creativity or whatever).  Its
full host name is thus "ibm.com.msu.edu".  Now what happens when a
reference is made to "ibm.com"?  Should this be my local system, or the
top-level entry for your company?  I think it has to be the latter.  In
other words, any name with a dot in it should *always* be tried first as
a fully qualified name prior to appending any portion of the local domain
or domain(s) from the DOMAIN list, or to removing part of the requested
name.  If this were done, I could accept a method II implementation.  I'd
suggest it be controlled by a keyword in the resolv.conf file (ALWAYSAPPEND).

Another method that I have seen is a variation on method II, where dotted
names are always tried as is, but single-part names are tried as in method
II (in domain a.b.c, first try host.a.b.c, then host.b.c, then host.c).
I have aided that process here by the fairly liberal use of CNAMEs - each
host system, and a number of workstations, named as "host.dept.msu.edu",
each have a CNAME entry under "host.msu.edu".

Another useful aid is to place more than one DOMAIN statement in your
resolv.conf file, giving a list of your favorite domains.

Doug Nelson                        nelson@msu.bitnet
Manager of Network Software        nelson@msu.edu
Michigan State University
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 90 15:22:34 GMT
From:      att!cbnewsm!matthews@ucbvax.Berkeley.EDU  (john.matthews)
To:        tcp-ip@nic.ddn.mil
Subject:   Twisted Pair Ethernet Feedback

Can anyone give me some good feedback as to how stable twisted pair ethernet
really is?  We are going to be building a new network in a new building that
we are moving to and I would like to use this if I don't hear to many bad
things about it.  I would like to hear from people that have actually
installed it and are putting ethernet under a reasonable load.
					Thanks in advance,
						John Matthews
-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 90 18:43:04 GMT
From:      ucsdhub!hp-sdd!ncr-sd!tw-rnd!jml@ucsd.edu  (Michael Lodman)
To:        tcp-ip@nic.ddn.mil
Subject:   PEP and SL/IP
Setup: 2 Sun-3 computers SunOS4.0.3, 2 Telebit 2500 modems, SL/IP software

Problem: I can get SL/IP running in the V.32 mode of the modems, at 9600bps
interface speed. When I try to run at 19200bps PEP, SL/IP will not work.

Is this a problem with the Sun serial ports, PEP, or SL/IP? Has anyone
else tried this? If they have, could they send me fixes and the modem
register setup they are using?

Thank you!

-- 
+-----------------------------------------------------------+
| Michael Lodman               Mike.Lodman@SanDiego.NCR.COM |
| NCR Corporation  -  Distributed Systems Lab  -  San Diego |
| 9900 Old Grove Rd.  San Diego, CA.  92131  (619) 693-5353 |
+-----------------------------------------------------------+
-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 90 17:13 +0100
From:      Olav Kvittem <kvittem@sintef.no>
To:        <TCP-IP@SRI-NIC.arpa>
Cc:        <cmu-tek-tcp@CS.CMU.edu>, <support@twg.com>
Subject:   VAX/VMS TCP/IP/X.25 support

In UNINETT, the Norwegian academic network, there are several
sites that have VAX/VMS machines that are connected to a X.25
service. They want to connect to the Internet (UNINETT).
A nice solution for them would be a TCP/IP-package
than could run on top of X.25. Does anyone know of software packages
that can do that ?

Olav Kvittem

==============================================================
 Olav Kvittem     kvittem@vax.runit.unit.uninett
 RUNIT (Comp. Centre at the Univ. of Trondheim), N-7034 Trondheim
 Phone: +47 7 596981 Telefax: +47 7 592971 Telex: 55620 sintf n
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 90 20:39:01 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Resolver implementation

> I know of two different methods for implementing a resolver, which are
> described below.  I'd like to hear comments on which is preferred
> because of usability, and any problems with either of the schemes.
>
> Method I
> --------
> If the host name does not contain a period, append the domain name
> before sending the name to the resolver.
>
> Method II
> ---------
> Always append the domain name, and gradually remove the first element
> in the DOMAIN statement trying all possibilities.
>
> Has anybody successfully implemented Method II?  And if so, what kind
> of user feedback have you gotten?

I have edited out the examples from Dan's comments above.

We don't use method II, but my biggest concern with it is the potential
for false hits, or the potential for hiding a domain name.  For example,
say I have a "com" (e.g. Communications) department.  And say they name
their Big Blue system "ibm" (for lack of creativity or whatever).  Its
full host name is thus "ibm.com.msu.edu".  Now what happens when a
reference is made to "ibm.com"?  Should this be my local system, or the
top-level entry for your company?  I think it has to be the latter.  In
other words, any name with a dot in it should *always* be tried first as
a fully qualified name prior to appending any portion of the local domain
or domain(s) from the DOMAIN list, or to removing part of the requested
name.  If this were done, I could accept a method II implementation.  I'd
suggest it be controlled by a keyword in the resolv.conf file (ALWAYSAPPEND).

Another method that I have seen is a variation on method II, where dotted
names are always tried as is, but single-part names are tried as in method
II (in domain a.b.c, first try host.a.b.c, then host.b.c, then host.c).
I have aided that process here by the fairly liberal use of CNAMEs - each
host system, and a number of workstations, named as "host.dept.msu.edu",
each have a CNAME entry under "host.msu.edu".

Another useful aid is to place more than one DOMAIN statement in your
resolv.conf file, giving a list of your favorite domains.

Doug Nelson                        nelson@msu.bitnet
Manager of Network Software        nelson@msu.edu
Michigan State University

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 90 20:47:46 GMT
From:      umabco!lwilson@cvl.umd.edu  (Lowell G. Wilson)
To:        tcp-ip@nic.ddn.mil
Subject:   Novell Networks

Does anyone know of a Novell LAN-based mail package that will talk SMTP?
We are in the [seemingly never-ending] process of completing
installation of a campus backbone that will connect all of our Novell
LANs (among other systems) and it would be nice if our users could send
and receive their Internet mail from the comfort of their own file
server.  We have mail systems in place that will allow our users to send
mail out to Internet addresses now, but that requires another login and
I'd like to see the extra authentication avoided.  Any hints?

Oh, while I'm here, I've gotten lots of help from this newsgroup before
(even when folks have just told me I can't do what I want to do) so, to
those who have replied to my messages in the past, thanks.... 

-- 
Lowell Wilson : Sinecure III        University of Maryland at Baltimore    
                                    Information Resources Mgt Division     
                                    UUCP: ...cvl!umabco!lwilson            
                                    Internet: umabco!lwilson@cvl.umd.edu
-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jan 90 10:30:11 -0800
From:      "Philip Almquist" <almquist@jessica.Stanford.EDU>
To:        tcp-ip@NIC.DDN.MIL, ietf@Venera.ISI.EDU
Cc:        ietf-rreq-editor@Jessica.Stanford.EDU
Subject:   revision of standards for IP routers
Currently, RFC1009 is the standard for IP routers.  The Internet Engineering
Task Force (IETF) will shortly be forming a working group to update and
expand that standard.

As we prepare to form this working group, we are curious about how the
Internet community feels we may improve and expand on RFC1009.  In
particular:

   1. Are there major topics should have been included in RFC1009 but
      were not?

   2. Are there any superfluous major topics in RFC1009?

   3. Which issues concerning IP routers are ill-defined or
      controversial?

   4. Should the new standard emulate the style and presentation used
      in the Host Requirements standards (RFC's 1122 and 1123)?  If
      not, why not, and how should we do it differently?

Please mail your comments to ietf-rreq-editor@Jessica.Stanford.EDU

If you wish to participate in the working group, please attend the first
meeting, which will be on February 6 at the IETF meeting at Florida State
University.  For information about attending IETF meetings, contact
ietf-request@Venera.ISI.EDU.

If you wish to participate in the group but cannot attend that meeting you
may join the group's mailing list by sending a request to:  

                  ietf-rreq-requests@Jessica.Stanford.EDU

If you don't wish to participate but would like to receive announcements
when draft versions of the document become available you may send a request
to:  

              ietf-rreq-interest-requests@Jessica.Stanford.EDU

                                      Philip Almquist
                                      Jim Forster
                                      co-chairs
                                      IETF Router Requirements Working Group
-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      16 Jan 90 21:48:35 GMT
From:      snorkelwacker!spdcc!dyer@tut.cis.ohio-state.edu  (Steve Dyer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PEP and SL/IP
In article <224@tw-rnd.SanDiego.NCR.COM> jml@tw-rnd.SanDiego.NCR.COM (Michael Lodman) writes:
>Setup: 2 Sun-3 computers SunOS4.0.3, 2 Telebit 2500 modems, SL/IP software
>Problem: I can get SL/IP running in the V.32 mode of the modems, at 9600bps
>interface speed. When I try to run at 19200bps PEP, SL/IP will not work.

Knowing what SLIP is like under PEP, I think you should stop and declare
victory having got them to work at 9600 V.32. :-)/2

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 90 00:32:42 GMT
From:      agcsun!marks@boulder.colorado.edu  (Mark Shepherd)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for distributed name service
Hi. I'm trying to find out if there are any existing or proposed 
protocols in the OSI or Internet protocol suite that will meet my
requirements. If anyone knows the answer, I'd appreciate hearing it.

Here's the situation: we are designing a network consisting of one or more 
LANs connected by some collection of bridges, routers, etc. Any node 
anywhere in the network may need to request services of some other
node somewhere else in the network. All the nodes in the network are
specialized application processors, which (a) probably don't have enough 
spare CPU/memory/disk to act as a name server; and (b) may be added or 
removed from the network (either logically or physically) at any time. 
The network will use a standard addressing scheme, such as IP or OSI.

Here's the question: How can a node find out what node(s) offer 
a given service, and what their address is? There are various existing 
solutions: OSI directory, Internet domain name protocol, yellow pages, etc.
but all of these seem to require a separate name or directory server. 
Restrictions (a) and (b) above would seem to preclude this approach.

An alternative is for each node to keep its own list of who's on the
network, but the administrative workload makes this highly unattractive.

What would be ideal is a protocol where a prospective client broadcasts
a request like "is there anyone out there who can provide service X"
and then anyone who can sends back an appropriate reply. 

Can anyone tell me if such protocol exists, or suggest another approach,
or explain how one of the existing standard solutions (which I am 
admittedly only somewhat familiar with) can do the job after all. 
 
Thanks in advance

Mark Shepherd
...!ames!ncar!boulder!agcsun!marks or ...!ucbvax!avsd!dse!agcsun!marks

claimer: resolving this issue is part of my job, so in some sense 
this message *does* represent the views of my corporation. 
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jan 90 15:17:46 -0800
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        Four.Lists:;
Subject:   ISODE 6.0 announcement
Sorry for the cross-posting, but this message only goes out about every
10 months

/mtr
///////

			  A N N O U N C E M E N T


    The next release of the "ISO Development Environment" will be
    available on 24 January 1990.  This release is called

				   ISODE 6.0

    This software supports the development of certain kinds of OSI protocols
    and applications.  Here are the details: 

  - The ISODE is not proprietary, but it is not in the public domain.  This was
    necessary to include a "hold harmless" clause in the release.  The upshot
    of all this is that anyone can get a copy of the release and do anything
    they want with it, but no one takes any responsibility whatsoever for any
    (mis)use.

  - The ISODE runs on native Berkeley (4.2, 4.3) and AT&T (SVR2, SVR3) systems,
    in addition to various other UNIX-like operating systems.  No kernel
    modifications are required.

  - Current modules include:
	OSI transport service (TP0 on top of TCP and X.25; TP4 for SunLink OSI)
	OSI session, presentation, and association control services
	ASN.1 abstract syntax/transfer notation tools, including:
	    remote operations stub-generator (front-end for remote operations)
	    structure-generator (ASN.1 to C)
	    element-parser (basic encoding rules)
	OSI reliable transfer and remote operations services
	OSI file transfer, access and management
	FTAM/FTP gateway
	OSI directory services
	OSI virtual terminal (basic class, TELNET profile)

  - ISODE 6.0 consists of final "IS" level implementations with a few
    exceptions: ROSE and RTSE are current to the last circulated drafts
    (March, 1988); VT is a DIS implementation.  The ISODE also contains
    implementations of the 1984 X.400 versions of ROS and RTS.  ISODE is
    aligned with the U.S. Government OSI Profile (GOSIP).

  - Modules planned for future releases include:
	OSI message handling system
	MHS/SMTP gateway

  - Although the ISODE is not "supported" per se, it does have a problem
    reporting address, Bug-ISODE@NISC.NYSER.NET.  Bug reports (and fixes) are
    welcome by the way. 

  - The discussion group ISODE@NIC.DDN.MIL is used as an open forum on ISODE.
    Contact ISODE-Request@NIC.DDN.MIL to be added to this list.

  - The primary documentation for this release consists of a five volume
    User's Manual (approx. 1000 pages) and a set of UNIX manual pages.  The
    sources to the User's Manual are in LaTeX format.  In addition, there are
    a number of notes, papers, and presentations included in the documentation
    set, again in either LaTeX or SLiTeX format.  If you do not have LaTeX, you
    should probably get a hardcopy from one of the distribution sites below.


    For more information, contact:

	PSI, Inc.
	PSI California Office
	Attn: Marshall T. Rose
        420 Whisman Court
        Mountain View, CA  94043-2112
	USA

        +1-415-961-3380


    DISTRIBUTION SITES

 1. FTP
    If you can FTP to the Internet, then use anonymous FTP to nisc.nyser.net
    [192.33.4.10] to retrieve the file isode-6.tar.Z in BINARY mode from the
    pub/isode/ directory.  This file is the tar image after being run through
    the compress program and is approximately 4.5MB in size.

 2. NIFTP
    If you run NIFTP over the public X.25 or over JANET, and are registered in
    the NRS at Salford, you can use NIFTP with username "guest" and your own
    name as password, to access UK.AC.UCL.CS to retrieve the file
    <SRC>isode-6.tar.  This is a 14MB tar image.  The file <SRC>isode-6.tar.Z
    is the tar image after being run through the compress program (4.5MB).

 3. NORTH AMERICA
    For mailings in NORTH AMERICA, send a check for 375 US Dollars to:

	University of Pennsylvania
	Department of Computer and Information Science
	Moore School
	Attn: David J. Farber (ISODE Distribution)
	200 South 33rd Street
	Philadelphia, PA 19104-6314
	USA

        +1-215-898-8560

    The tape will be written in tar format at 1600bpi, and returned with a
    documentation set.  Do not send tapes or envelopes.  Documentation only is
    the same price.

 4. EUROPE (tape and documentation)
    For mailings in EUROPE, send a cheque or bankers draft and a purchase order
    for 200 Pounds Sterling to:

        Department of Computer Science
        Attn: Natalie May/Dawn Bailey
        University College London
        Gower Street
        London, WC1E 6BT
        UK


  Page 2

    For information only:
	Telephone:	+44-1-380-7214
	Fax:		+44-1-387-1397
	Telex:		28722
	Internet:	natalie@cs.ucl.ac.uk, dawn@cs.ucl.ac.uk

    Specify either (a) 1600bpi 1/2-inch tape, or (b) Sun 1/4-inch
    cartridge tape.  The tape will be written in tar format and returned
    with a documentation set.  Do not send tapes or envelopes.
    Documentation only is the same price.

 6. EUROPE (tape only)
    Tapes without hardcopy documentation can be obtained via the European
    UNIX User Group (EUUG). The ISODE 6.0 distribution is called EUUGD14.
    
          EUUG Distributions
          c/o Frank Kuiper
          Centrum voor Wiskunde en Informatica
          Kruislaan 413
          1098 SJ  Amsterdam
          The Netherlands

    For information only:
          Telephone:	+31-20-5924121 (or: +31-20-5929333)
          Telex:	12571 mactr nl
	  Telefax:	+31-20-5924199
          Internet:	euug-tapes@cwi.nl

    Specify one of:
	- 1600bpi 1/2-inch tape:			130 Dutch Guilders
	- 800bpi 1/2-inch tape:				130 Dutch Guilders
	- Sun 1/4-inch cartridge tape (QIC-24 format):	190 Dutch Guilders
	- 1/4-inch cartridge tape (QIC-11 format):	190 Dutch Guilders

    If you require DHL this is possible and will be billed through.  Note that
    if you are not a member of EUUG, then there is an additional handling fee
    of 300 Dutch Guilders (please enclose a copy of your membership or
    contribution payment form when ordering).  Do not send money, cheques,
    tapes or envelopes, you will be invoiced.

 7. AUSTRALIA and NEW ZEALAND
    For mailings in AUSTRALIA and NEW ZEALAND, send a cheque for 250 dollars
    Australian to:  

	CSIRO DIT
	Attn: Andrew Waugh (ISODE DISTRIBUTION)
	55 Barry St
	Carlton, 3053
	Australia

    For information only:
	Telephone:	+61-3-347-8644
	Fax:		+61-3-347-8987
	Internet:	ajw@ditmela.oz.au


  Page 3


    Please specify the media you desire: (a) 1/2-inch tape at 1600bpi,
    3200bpi, or 6250bpi; or (b) Sun 1/4-inch cartridge tape in either
    QIC-11 or QIC-24 format. The tape will be written in tar format and
    returned with a documentation set.  Do not send tapes or envelopes.
    Documentation only is the same price.

 8. FTAM on the JANET or PSS
    The sources are available by FTAM at the UCL over X.25 using JANET
    (00000511160013) or PSS (23421920030013) with TSEL "259" (ascii encoding).
    Use the "anon" user-identity and retrieve the file <SRC>isode-6.tar.  This
    is a 14MB tar image.  The file <SRC>isode-6.tar.Z is the tar image after
    being run through the compress program (4.5MB).

 9. FTAM on the Internet
    The sources are available by FTAM over the Internet at host osi.nyser.net
    [192.33.4.20] (TCP port 102 selects the OSI transport service) with TSEL
    259 (numeric encoding).  Use the "anon" user-identity, supply any password,
    and retrieve the file isode-6.tar.Z from the pub/isode/ directory.  This
    file is the tar image after being run through the compress program and is
    approximately 4.5MB in size.

    For distributions via FTAM, the file service is provided by the FTAM 
    implementation in ISODE 5.0 or later (IS FTAM).

    For distributions via either FTAM or FTP, there is an additional file
    available for retrieval, called isode-ps.tar.Z which is a compressed tar
    image (7MB) containing the entire documentation set in PostScript format.


    SUPPORT

    A UK company has been set up to provide support for the ISODE and
    associated packages - X-Tel Services Ltd.  This company provides an update
    service, general assistance and site specific support.  Although inclusion
    of this information should not be considered an endorsement, it should be
    noted that one of the primary ISODE developers now works at X-Tel Services
    Ltd.

	X-Tel Services Ltd.
	13-03 Tower Block
	Nottingham University
	Nottingham, NG7 2RD
        UK

	Telephone:	+44-602-412648
	Fax:		+44-602-588138
	Telex:		37346
	Internet:	xtel@cs.nott.ac.uk

    If other organizations offering formal support for the ISODE wish to be
    included in future announcements, a suitable index will be organized.




  Page 4
-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 90 03:44:23 GMT
From:      xylogics!loverso@CS.BU.EDU  (John Robert LoVerso)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PEP and SL/IP
In article <224@tw-rnd.SanDiego.NCR.COM> jml@tw-rnd.SanDiego.NCR.COM (Michael Lodman) writes:
> Setup: 2 Sun-3 computers SunOS4.0.3, 2 Telebit 2500 modems, SL/IP software
> 
> Problem: I can get SL/IP running in the V.32 mode of the modems, at 9600bps
> interface speed. When I try to run at 19200bps PEP, SL/IP will not work.

If you've got T2500s, don't even bother with PEP.  Higher level protocols
(TCP) will work smoother over SLIP over a V.32 connection.  If your T2500s
have GA2.00 ROMs, then be sure to run with MNP5 with the serial interface
at 19200.  For the icing on the cake, use Van's recently announced SLIP
w/TCP header compression.

As for PEP w/SLIP; yes, I've run it (although not with a Sun running
SunOS4.0.3).  When rasing the speed link to 19200, be sure all points
(both Suns and both modems) are set to 19200.  Other than that, there
is no inherent impediment with what you want to do.

John
-- 
John Robert LoVerso			Xylogics, Inc.  617/272-8140x284
loverso@Xylogics.COM			Annex Terminal Server Development Group
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jan 90 09:10:27 EST
From:      stev@vax.ftp.com
To:        cpw%sneezy@LANL.GOV (C. Philip Wood)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  tcp port numbers
>  Now I have beaucoup messages from
>  various blankity-blank Peesee's in a log on our network test machine.
>  Of course all the other systems on the net get to handle these
>  interrupts too.
>  
>  A way to stop this noise is to send the data back to them.  Yuck, yuck.
>  
>  We could call it "Well Known Socket Protection".
>  
>  Phil
>  

i understand you are kidding, phil, but before anyone decides to go give
this a try, you should consider that you are voilating the paradym as badly
as they are (hope the spelling is correct there, someone ran off with the
dictionary). while it *seems* like a good idea at the beginning, and one
could argue that is you are only replying to the hosts that generate traffic
to the discard socket with the broadcast address, it is still a bad idea to
lower ones self to their level.


personally, i liked the idea of charging back for the packets:)


stev knowles
ftp software
stev@ftp.com

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jan 90 09:54:07 EST
From:      mep@aqua.whoi.edu (Michael E. Pare)
To:        att!cbnewsm!matthews@ucbvax.berkeley.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Twisted Pair Ethernet Feedback
I've installed thick, thin and twisted pair ethernet and highly recommend
twisted pair.  Try to have 22AWG wire installed (greater distances) and 
make sure it isn't shielded (unless you intend to use IBM's shielded wire
system).  Unshielded wiring is more flexible and easier to work with. I have
both and know this from experience.  You will need a backbone format which
could be thick, thin or fiber optics to link the floors together.  You 
shouldn't run twisted pair ethernet vertically (makes for a nice antenna).
You should also have at least 2prs for each connection in order to support
the new 10BASET standard.  Some twisted pair ethernet formats use 2pr now.
I'd recommend at least 4prs for each office for data alone.  Voice extra.

The key step will be in selecting your twisted pair ethernet vendor.  Good
luck.
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 90 05:03:06 GMT
From:      vsi1!daver!apt!brian@ames.arc.nasa.gov  (Brian Litzinger)
To:        tcp-ip@nic.ddn.mil
Subject:   Help with networks and slip and routing
I've gotten slip running on a couple servers, and
have had the slip links connected to PC's running such thing as
ka9q, pcip, and pcnfs. 

I would now like to use dialup slip between two servers.  However, I'm
not familiar enough with routing and networks to setup this up.

I've read my 386/ix TCP/IP Guide and UNIX Networking by Kochan & Wood,
but I'm still not sure what has to be done.

My two servers running slip are svr1 89.0.1.1 and svr2 89.0.2.1 each
serving a set of workstations at separate sites.  My question is
how do I get one server to realize that it must send requests across
the slip line when it wishes to talk with a machine on the other 
network.

Any help or pointers to documentation would be appreciated.

Thanks.

<>  Brian Litzinger @ APT Technology Inc., San Jose, CA
<>  UUCP:  {apple,sun,pyramid}!daver!apt!brian    brian@apt.UUCP
<>  VOICE: 408 370 9077      FAX: 408 370 9291
-- 
<>  Brian Litzinger @ APT Technology Inc., San Jose, CA
<>  UUCP:  {apple,sun,pyramid}!daver!apt!brian    brian@apt.UUCP
<>  VOICE: 408 370 9077      FAX: 408 370 9291
-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jan 90 15:24:45 -0500 (EST)
From:      Walter Lloyd Wimer III <ww0n+@andrew.cmu.edu>
To:        tcp-ip@nic.ddn.mil, agcsun!marks@boulder.colorado.edu (Mark Shepherd)
Subject:   Re: Looking for distributed name service

Excerpts from internet.tcp-ip: 17-Jan-90 Looking for distributed nam..
Mark Shepherd@boulder.co (1911)

> What would be ideal is a protocol where a prospective client broadcasts
> a request like "is there anyone out there who can provide service X"
> and then anyone who can sends back an appropriate reply. 


This sounds exactly like the Internet Resource Location Protocol (RLP)
described in RFC 887.  I don't know of any actual implementations,
though, and there seems to be a move to declare this protocol obsolete
and of "historical" interest only.  It's probably worth your time to
look at it, however.


Walt Wimer
Network Development
Carnegie Mellon University
-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Wed, 17 Jan 90 15:14:07 EST
From:      Doug Nelson <08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu>
To:        Mark Shepherd <agcsun!marks@boulder.colorado.edu>, "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>, tcp-ip-relay@nic.ddn.mil
Subject:   Re: Looking for distributed name service
>Hi. I'm trying to find out if there are any existing or proposed
>protocols in the OSI or Internet protocol suite that will meet my
>requirements. If anyone knows the answer, I'd appreciate hearing it.
>
>Here's the situation: we are designing a network consisting of one or more
>LANs connected by some collection of bridges, routers, etc. Any node
>anywhere in the network may need to request services of some other
>node somewhere else in the network. All the nodes in the network are
>specialized application processors, which (a) probably don't have enough
>spare CPU/memory/disk to act as a name server; and (b) may be added or
>removed from the network (either logically or physically) at any time.
>The network will use a standard addressing scheme, such as IP or OSI.
>
>Here's the question: How can a node find out what node(s) offer
>a given service, and what their address is? There are various existing
>solutions: OSI directory, Internet domain name protocol, yellow pages, etc.
>but all of these seem to require a separate name or directory server.
>Restrictions (a) and (b) above would seem to preclude this approach.
>
>An alternative is for each node to keep its own list of who's on the
>network, but the administrative workload makes this highly unattractive.
>
>What would be ideal is a protocol where a prospective client broadcasts
>a request like "is there anyone out there who can provide service X"
>and then anyone who can sends back an appropriate reply.
>
>Can anyone tell me if such protocol exists, or suggest another approach,
>or explain how one of the existing standard solutions (which I am
>admittedly only somewhat familiar with) can do the job after all.

Can you explain your restrictions (a) and (b) in more detail?  In particular,
what precludes adding one more processor to the network (say, a small Unix
box or even a PC) which can provide the directory service (DNS or otherwise)?

Doug Nelson
Michigan State University
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 90 13:03:19 GMT
From:      ucsdhub!hp-sdd!ncr-sd!ncrcae!secola!krupczak@ucsd.edu  (Bobby Krupczak)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Novell Networks
In article <863@umabco.UUCP> lwilson@umabco.UUCP (Lowell G. Wilson) writes:
>
>Does anyone know of a Novell LAN-based mail package that will talk SMTP?
>We are in the [seemingly never-ending] process of completing
>installation of a campus backbone that will connect all of our Novell
>LANs (among other systems) and it would be nice if our users could send
>and receive their Internet mail from the comfort of their own file
>server.  We have mail systems in place that will allow our users to send
>mail out to Internet addresses now, but that requires another login and
>I'd like to see the extra authentication avoided.  Any hints?
>

Hi!

Novell is working on "Portable" Netware.  This product is written to run
on Unix as well as VMS machines.  NCR is one company that will offer
"Portable" Netware on its Unix boxes.  Having a Netware file server on
a Unix box (presumably with TCP/IP), mail could be sent from a client on
a pc out to the Internet.  I dont know of any commercial based products that
are available yet for "Portable" NetWare, they arent too far down the line
Im sure -- or you could write one yourself.

Bobby
-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 90 14:10:00 GMT
From:      ucsdhub!hp-sdd!ncr-sd!ncrlnk!ncrorl!anderson@ucsd.edu  (Anderson)
To:        tcp-ip@nic.ddn.mil
Subject:   NFS and root
I have heard that some implementations of NFS do not allow root on the client
to access file on the server. I know about the root->nobody(uid=-2) translation
that goes on, but what I heard indicated that even this did not work.

Is this correct? Can somebody give me some more information on this, and if
there is a way to work around this limitation?

Any information would be greatly appreciated as I am in the middle on an NFS
implementation myself.

Thanks,

Stuart Anderson        anderson@Orlando.NCR.COM       NCR E&M Orlando, Florida
..!uunet!ncrlnk!ncrorl!anderson                       (407) 333-9250 ext. 288
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Jan 90 00:22:15 PST
From:      Greg Satz <satz@cisco.com>
To:        Mike Rackley <RACKLEY%MSSTATE.BITNET@CORNELLC.cit.cornell.edu>
Cc:        <tcp-ip@NIC.DDN.MIL>
Subject:   Re: Whose bridges support SNMP?
cisco Systems, Inc. makes a combination bridge router which supports SNMP.
The device can be configured to bridge IP and will still receive and reply
to SNMP queries as well as TCP/TELNET.

Feel free to drop a note to customer-service@cisco.com with any questions
about features or pricing.

Thanks,
Greg Satz
cisco
-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 90 17:47:49 GMT
From:      mcsun!sunic!tut!utu.fi!kontu.utu.fi!soini@uunet.uu.net
To:        tcp-ip@nic.ddn.mil
Subject:   Re: VAX/VMS TCP/IP/X.25 support
In article <2451*kvittem@sintef.no>, kvittem@sintef.no (Olav Kvittem) writes:
> In UNINETT, the Norwegian academic network, there are several
> sites that have VAX/VMS machines that are connected to a X.25
> service. They want to connect to the Internet (UNINETT).
> A nice solution for them would be a TCP/IP-package
> than could run on top of X.25. Does anyone know of software packages
> that can do that ?
> 
> Olav Kvittem

We are running TGV Multinet TCP/IP software, and TGV claims that one should
be able to use X.25 as datalink layer with their product.

For more information, contact: 	

Desiree M Champagne
Technology Commercialization Assistant/
Software Licensing Specialist
SRI International
333 Rawenswood Ave.
Menlo Park, CA 94025
U.S.A.

Internet: Desiree@warbucks.ai.sri.com

-- 
Juhani Soini, the Sauron of Mordor  ! Dept. of Physical Sciences
sauron@mordor.utu.fi                ! University of Turku, Finland
soini@utu.fi  	                    ! 
soini@firien.bitnet                 ! phone: +358-21-633 5866
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 90 19:59:32 GMT
From:      cs.utexas.edu!samsung!aplcen!haven!grebyn!schultz@tut.cis.ohio-state.edu  (Ronald)
To:        tcp-ip@nic.ddn.mil
Subject:   IBM to PC FTP

Please HELP !!!!

I currently have 60 PCs connected an an IBM mainframe running
SIM3278 and SIMPC.  The PCs connect to an X.25 PDN using 2400
baud asynch modems.  On the IBM side is an IBM 3745 running NPSI
and SIM3278.  The only reason I have this setup is to upload and
download files.

IBM 3090 -- 3745 -- PAD -- X.25 PDN -- Asynch PAD -- PC
SIM3278     NPSI                                    SIMPC

I wish to change to FTP for upload and downloads because the
SIMWARE upload and download requires me to initiate TSO seesion,
which are eating me out of house and CPU.  

Does anyone have any suggestions on how I can do this ?


Ron Schultz
schultz@grebyn.com

614 - 841-1110
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 90 20:12:18 GMT
From:      shelby!portia!jessica!morgan@eos.arc.nasa.gov  (RL "Bob" Morgan)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  tcp port numbers

Terry asks:

> Personally, I don't see why the existing registration procedures can't
> be applied to all port numbers.  Are there any significant problems in
> doing this?

As various other postings about inconsistent use of port numbers on
different systems should make clear, we have got to the point where
maintaining a universal static list mapping service names to port
numbers is as unappealing and difficult as maintaining a universal
static list mapping host names to IP addresses.  It's an inevitable
consequence of the growth in size and diversity of the Internet.  The
Numbers Czars seem to have stated their limited interest in
maintaining such a list by limiting the "official" range to 0-256.
(Maybe they're thinking of expanding this?)

Clearly, what's needed is a standard mechanism for hosts to access
services on other hosts without knowing in advance what ports those
services are on.  One such mechanism is proposed in RFC-1078, TCPMUX,
but unfortunately it only applies to TCP-based services.  Sun's
portmapper provides this function for services using their RPC
protocol.  My impression of Hesiod, MIT-Athena's extension to domain
name service, is that it performs this function among others.  I
imagine that such a mechanism could be based on ISO Directory services
whenever they become widely available.  In the meantime, we'll suffer
along as usual.

 - RL "Bob" Morgan
   Networking Systems
   Stanford
-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      17 Jan 90 22:39:25 GMT
From:      ucsdhub!hp-sdd!ncr-sd!ncrlnk!ncrcce!cavanaug@ucsd.edu  (John David Cavanaugh)
To:        tcp-ip@nic.ddn.mil
Subject:   Interior Gateway Protocol Summary
I tried to post this the other day, but didn't see it here.  My
apologies if this is a duplicate.

A short time ago, I posted a query to comp.protocols.tcp-ip asking
which interior gateway protocols people actually use.  I got 16 replies
to my query, which doesn't make for a statistically meaningful sample,
but most people who responded were interested in the results, so I
thought I'd post them.

The usage stacks up this way:

    RIP         11
    IGRP         7
    Hello        1
    OSPF         1
    ANSI IS-IS   1

Many respondents said that they were using more than one protocol, so
the total usage reported is greater than the number of respondents.

Of the people using RIP, which is currently most popular, 5 said they
would be changing to OSPF as soon as it was available.

Some pertinent comments:

    "We are limping along using RIP and Hello ..."

    "The Cisco access-list filtering on IP and DECNET routing is
    ESSENTIAL for us to get it functioning." 

    "So you will have your choice between OSPF and ODV (IGRP) in
    the near future."

    "Think firewalling, not OSPF versus ODV."

    "... we don't have to worry about brain-dead hosts broadcasting
    bogus RIP packets."

My thanks to all who responded.

-- 
John Cavanaugh                       John.Cavanaugh@StPaul.NCR.COM
NCR Comten, Inc.                     (612) 638-2822
2700 Snelling Ave. N
St. Paul, MN  55113                  Standard disclaimer.
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Jan 90 14:31:18 -0800
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        tcp-ip.list:;
Subject:   ISODE 6.0 announcement
(for some reason this didn't go through, so I am reposting...)

			  A N N O U N C E M E N T


    The next release of the "ISO Development Environment" will be
    available on 24 January 1990.  This release is called

				   ISODE 6.0

    This software supports the development of certain kinds of OSI protocols
    and applications.  Here are the details: 

  - The ISODE is not proprietary, but it is not in the public domain.  This was
    necessary to include a "hold harmless" clause in the release.  The upshot
    of all this is that anyone can get a copy of the release and do anything
    they want with it, but no one takes any responsibility whatsoever for any
    (mis)use.

  - The ISODE runs on native Berkeley (4.2, 4.3) and AT&T (SVR2, SVR3) systems,
    in addition to various other UNIX-like operating systems.  No kernel
    modifications are required.

  - Current modules include:
	OSI transport service (TP0 on top of TCP and X.25; TP4 for SunLink OSI)
	OSI session, presentation, and association control services
	ASN.1 abstract syntax/transfer notation tools, including:
	    remote operations stub-generator (front-end for remote operations)
	    structure-generator (ASN.1 to C)
	    element-parser (basic encoding rules)
	OSI reliable transfer and remote operations services
	OSI file transfer, access and management
	FTAM/FTP gateway
	OSI directory services
	OSI virtual terminal (basic class, TELNET profile)

  - ISODE 6.0 consists of final "IS" level implementations with a few
    exceptions: ROSE and RTSE are current to the last circulated drafts
    (March, 1988); VT is a DIS implementation.  The ISODE also contains
    implementations of the 1984 X.400 versions of ROS and RTS.  ISODE is
    aligned with the U.S. Government OSI Profile (GOSIP).

  - Modules planned for future releases include:
	OSI message handling system
	MHS/SMTP gateway

  - Although the ISODE is not "supported" per se, it does have a problem
    reporting address, Bug-ISODE@NISC.NYSER.NET.  Bug reports (and fixes) are
    welcome by the way. 

  - The discussion group ISODE@NIC.DDN.MIL is used as an open forum on ISODE.
    Contact ISODE-Request@NIC.DDN.MIL to be added to this list.

  - The primary documentation for this release consists of a five volume
    User's Manual (approx. 1000 pages) and a set of UNIX manual pages.  The
    sources to the User's Manual are in LaTeX format.  In addition, there are
    a number of notes, papers, and presentations included in the documentation
    set, again in either LaTeX or SLiTeX format.  If you do not have LaTeX, you
    should probably get a hardcopy from one of the distribution sites below.


    For more information, contact:

	PSI, Inc.
	PSI California Office
	Attn: Marshall T. Rose
        420 Whisman Court
        Mountain View, CA  94043-2112
	USA

        +1-415-961-3380


    DISTRIBUTION SITES

 1. FTP
    If you can FTP to the Internet, then use anonymous FTP to nisc.nyser.net
    [192.33.4.10] to retrieve the file isode-6.tar.Z in BINARY mode from the
    pub/isode/ directory.  This file is the tar image after being run through
    the compress program and is approximately 4.5MB in size.

 2. NIFTP
    If you run NIFTP over the public X.25 or over JANET, and are registered in
    the NRS at Salford, you can use NIFTP with username "guest" and your own
    name as password, to access UK.AC.UCL.CS to retrieve the file
    <SRC>isode-6.tar.  This is a 14MB tar image.  The file <SRC>isode-6.tar.Z
    is the tar image after being run through the compress program (4.5MB).

 3. NORTH AMERICA
    For mailings in NORTH AMERICA, send a check for 375 US Dollars to:

	University of Pennsylvania
	Department of Computer and Information Science
	Moore School
	Attn: David J. Farber (ISODE Distribution)
	200 South 33rd Street
	Philadelphia, PA 19104-6314
	USA

        +1-215-898-8560

    The tape will be written in tar format at 1600bpi, and returned with a
    documentation set.  Do not send tapes or envelopes.  Documentation only is
    the same price.

 4. EUROPE (tape and documentation)
    For mailings in EUROPE, send a cheque or bankers draft and a purchase order
    for 200 Pounds Sterling to:

        Department of Computer Science
        Attn: Natalie May/Dawn Bailey
        University College London
        Gower Street
        London, WC1E 6BT
        UK


  Page 2

    For information only:
	Telephone:	+44-1-380-7214
	Fax:		+44-1-387-1397
	Telex:		28722
	Internet:	natalie@cs.ucl.ac.uk, dawn@cs.ucl.ac.uk

    Specify either (a) 1600bpi 1/2-inch tape, or (b) Sun 1/4-inch
    cartridge tape.  The tape will be written in tar format and returned
    with a documentation set.  Do not send tapes or envelopes.
    Documentation only is the same price.

 6. EUROPE (tape only)
    Tapes without hardcopy documentation can be obtained via the European
    UNIX User Group (EUUG). The ISODE 6.0 distribution is called EUUGD14.
    
          EUUG Distributions
          c/o Frank Kuiper
          Centrum voor Wiskunde en Informatica
          Kruislaan 413
          1098 SJ  Amsterdam
          The Netherlands

    For information only:
          Telephone:	+31-20-5924121 (or: +31-20-5929333)
          Telex:	12571 mactr nl
	  Telefax:	+31-20-5924199
          Internet:	euug-tapes@cwi.nl

    Specify one of:
	- 1600bpi 1/2-inch tape:			130 Dutch Guilders
	- 800bpi 1/2-inch tape:				130 Dutch Guilders
	- Sun 1/4-inch cartridge tape (QIC-24 format):	190 Dutch Guilders
	- 1/4-inch cartridge tape (QIC-11 format):	190 Dutch Guilders

    If you require DHL this is possible and will be billed through.  Note that
    if you are not a member of EUUG, then there is an additional handling fee
    of 300 Dutch Guilders (please enclose a copy of your membership or
    contribution payment form when ordering).  Do not send money, cheques,
    tapes or envelopes, you will be invoiced.

 7. AUSTRALIA and NEW ZEALAND
    For mailings in AUSTRALIA and NEW ZEALAND, send a cheque for 250 dollars
    Australian to:  

	CSIRO DIT
	Attn: Andrew Waugh (ISODE DISTRIBUTION)
	55 Barry St
	Carlton, 3053
	Australia

    For information only:
	Telephone:	+61-3-347-8644
	Fax:		+61-3-347-8987
	Internet:	ajw@ditmela.oz.au


  Page 3


    Please specify the media you desire: (a) 1/2-inch tape at 1600bpi,
    3200bpi, or 6250bpi; or (b) Sun 1/4-inch cartridge tape in either
    QIC-11 or QIC-24 format. The tape will be written in tar format and
    returned with a documentation set.  Do not send tapes or envelopes.
    Documentation only is the same price.

 8. FTAM on the JANET or PSS
    The sources are available by FTAM at the UCL over X.25 using JANET
    (00000511160013) or PSS (23421920030013) with TSEL "259" (ascii encoding).
    Use the "anon" user-identity and retrieve the file <SRC>isode-6.tar.  This
    is a 14MB tar image.  The file <SRC>isode-6.tar.Z is the tar image after
    being run through the compress program (4.5MB).

 9. FTAM on the Internet
    The sources are available by FTAM over the Internet at host osi.nyser.net
    [192.33.4.20] (TCP port 102 selects the OSI transport service) with TSEL
    259 (numeric encoding).  Use the "anon" user-identity, supply any password,
    and retrieve the file isode-6.tar.Z from the pub/isode/ directory.  This
    file is the tar image after being run through the compress program and is
    approximately 4.5MB in size.

    For distributions via FTAM, the file service is provided by the FTAM 
    implementation in ISODE 5.0 or later (IS FTAM).

    For distributions via either FTAM or FTP, there is an additional file
    available for retrieval, called isode-ps.tar.Z which is a compressed tar
    image (7MB) containing the entire documentation set in PostScript format.


    SUPPORT

    A UK company has been set up to provide support for the ISODE and
    associated packages - X-Tel Services Ltd.  This company provides an update
    service, general assistance and site specific support.  Although inclusion
    of this information should not be considered an endorsement, it should be
    noted that one of the primary ISODE developers now works at X-Tel Services
    Ltd.

	X-Tel Services Ltd.
	13-03 Tower Block
	Nottingham University
	Nottingham, NG7 2RD
        UK

	Telephone:	+44-602-412648
	Fax:		+44-602-588138
	Telex:		37346
	Internet:	xtel@cs.nott.ac.uk

    If other organizations offering formal support for the ISODE wish to be
    included in future announcements, a suitable index will be organized.




  Page 4

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 90 05:12:15 GMT
From:      uhccux!munnari.oz.au!murtoa.cs.mu.oz.au!murdu!ucsvc!u8551027@ames.arc.nasa.gov
To:        tcp-ip@nic.ddn.mil
Subject:   network rje
Has anyone ever come across a unix based netrje server,client system? There is
an rfc (rfc 725) describing a network rje. Also it has a port allocated in
/etc/services, but I've never heard of the program. 

Thanks

Paul Woosnam (University of Melbourne)
-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Jan 90 13:18 MST
From:      Paul Charette <EE5990038@rvax.ccit.arizona.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Ethernet to Sytek LAN (SLIP) IP-level gateway

Greetings ...

	I am trying to implement an IP-level gateway between an Ethernet and
a Sytek LAN.  For those who aren't familiar with Sytek, it is a
connection-oriented LAN which a PC can be connected to via it's serial port -
most of the "intelligence" is in a box (PCU - peripherial controller unit)
which goes between the PC and the actual LAN medium and contains network 
layers from the Session layer, down to the Data Link.

	I currently have the NCSA Telnet Version 2.2tn working fine over an
Ethernet card from my PC.  I am using the the Ethernet packet driver for a
3C503 card.  It seems like I could get NCSA Telnet working between two PCs on
the Sytek LAN by writing a packet driver for Sytek (which should be very 
similiar to the SLIP8250 driver).  The next step would be to implement the 
gateway using these two packet drivers.

	My question, then, is this:  Can the current NCSA Telnet code be 
hacked/tweaked/configured to act as IP-level gateway software?  Would KA9Q
be a better bet?  Does using the packet driver complicate things?  Any
answers, comments or further questions are greatly appreciated.

	Thanks in advance.

Regards,
Paul Charette
Department of Computer Engineering
University of Arizona
Tucson, Arizona

"Violence is the last refuge of the incompetent"
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 90 06:57:18 GMT
From:      barmar@think.com  (Barry Margolin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: socket -> UID
I've redirected followups to comp.protocols.tcp-ip, since this discussion
is no longer Unix-specific.
In article <20784@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes:
>In article <1990Jan15.053647.24388@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes:
>>   This can't be done.  An Internet domain socket doesn't have any UID or GID
>> information associated with it;
>It should. The Internet inherited that administrative flaw from the Arpanet.

No, it shouldn't.  UID's and GID's are inherently OS-specific; some systems
use numbers, some use character strings, and some may use arbitrarily
complex data structures.  Additionally, some protocols are not used between
user processes, but between systems in general (what UID should be
associated with ICMP datagrams?  what's the UID on a terminal
concentrator?).

The primary purpose of transport protocols such as TCP is to make a single
physical link appear to be multiple links (i.e. multiplexing).  Since
simple links don't pass user identity along, multiplexed links don't need
to, either.  Application protocols should be independent of the mechanism
used to establish the link; if they need to know user identities, then
they'll need to pass it themselves when used over simple links, so it would
be redundant to have the multiplexing protocol pass it as well.

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Jan 90 12:26:00 EST
From:      stev@vax.ftp.com
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Novell Networks
*  In article <863@umabco.UUCP> lwilson@umabco.UUCP (Lowell G. Wilson) writes:
*  >
*  >Does anyone know of a Novell LAN-based mail package that will talk SMTP?
*  >We are in the [seemingly never-ending] process of completing
*  >installation of a campus backbone that will connect all of our Novell
*  >LANs (among other systems) and it would be nice if our users could send
*  >and receive their Internet mail from the comfort of their own file
*  >server.  We have mail systems in place that will allow our users to send
*  >mail out to Internet addresses now, but that requires another login and
*  >I'd like to see the extra authentication avoided.  Any hints?
*  >
*  
*  From: ucsdhub!hp-sdd!ncr-sd!ncrcae!secola!krupczak@ucsd.edu  (Bobby Krupczak)
*  
*  Hi!
*  
*  Novell is working on "Portable" Netware.  This product is written to run
*  on Unix as well as VMS machines.  NCR is one company that will offer
*  "Portable" Netware on its Unix boxes.  Having a Netware file server on
*  a Unix box (presumably with TCP/IP), mail could be sent from a client on
*  a pc out to the Internet. I dont know of any commercial based products that
*  are available yet for "Portable" NetWare, they arent too far down the line
*  Im sure -- or you could write one yourself.
*  
*  Bobby


i assume that you mean the either novell or NCR intends to make a integrated
novell/SMTP mail gateway for use by the clients then? as i understand the
portable netware project, there is no tcpip functionality included, since it
was intended to run on arbitrary machines (like DECNET only machines as well
as TCP/IP only machines.). just having netware on your TOWER or VAXEN does
not mean you will be able to send DECNET mail or SMTP mail, or even log into
the host in the "telnet" or "LAT" sense of the term.


stev knowles
stev@ftp.com

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 90 07:32:47 GMT
From:      fox!portal!cup.portal.com!John_Robert_Breeden@apple.com
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Novell Networks
>
>Does anyone know of a Novell LAN-based mail package that will talk SMTP?

AT&T markets a mail package (STARmail) that runs on a Novell network, the
server side can reside on the Netware server and talks Unix mail format,
should be easy from there to connect to SMTP. (They have special educational
pricing - contact the Data Systems Group).
-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 90 08:22:15 GMT
From:      satz@CISCO.COM (Greg Satz)
To:        comp.protocols.tcp-ip
Subject:   Re: Whose bridges support SNMP?

cisco Systems, Inc. makes a combination bridge router which supports SNMP.
The device can be configured to bridge IP and will still receive and reply
to SNMP queries as well as TCP/TELNET.

Feel free to drop a note to customer-service@cisco.com with any questions
about features or pricing.

Thanks,
Greg Satz
cisco

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Jan 90 13:27:29 EST
From:      "Bruce A. Kulback" (IMD-TB) <bkulback@PICA.ARMY.MIL>
To:        tcp-ip@nic.ddn.mil
Cc:        bkulback@PICA.ARMY.MIL
Subject:   R programs
Dear Sirs:

I am the network administrator for the Control Data NOS/VE hosts at 
Picatinny Arsenal, New Jersey.  We are interested in devising a TCP/IP
NOS/VE "rlogin" program to communicate with the existing routines
currently available on unix.  Could you please send me any RFC information
regarding "rlogin" or tell me how to find such information. 

Thanks in advance-

  Bruce Kulback 

  (201) 724-3577
  USAISC - Dover
  ASQNC-APT_OT Bldg. 350N
  Picatinny Arsenal, N.J. 07806-5000

  email: bkulback@pica.army.mil 
-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 90 08:30:40 GMT
From:      mcsun!hp4nl!philapd!ssp15!jos@uunet.uu.net  (Jos Vos)
To:        tcp-ip@nic.ddn.mil
Subject:   List of all well-known port numbers for TCP/UDP
Can anybody give me a reference to a list of all well-known port numbers
for TCP/UDP? In RFC1010 only the port numbers <= 255 are listed, and I'm
looking for a list that also includes others, e.g. port numbers for uucpd,
NNTP, RFS (AT&T), NFS (SUN) etc. etc.

-- 
-- ######   Jos Vos   ######   Internet   jos@idca.tds.philips.nl   ######
-- ######             ######   UUCP         ...!mcvax!philapd!jos   ######
-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Jan 90 13:42:00 EST
From:      Ian (I.) Easson <EASSON@BNR.CA>
To:        <tcp-ip@nic.ddn.mil>
Subject:   Unsubscribe
Please unsubscribe me.
-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Thu, 18 Jan 90 18:33:16 EST
From:      Yogesh Shah <419333%UOTTAWA.bitnet@ugw.utcs.utoronto.ca>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Upcoming seminars?
Does anybody know of upcoming tutorials, conferences or seminars
on advanced internetworking issues such as dynamic routing protocols?

Any help is very much appreciated.

Yogesh Shah
Phone: 613-763-8748
-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 90 14:14:51 GMT
From:      bii!dple@uunet.uu.net  (david levine)
To:        tcp-ip@nic.ddn.mil
Subject:   Pascal Sources for TCP/IP
Recently I posted a request for information about TCP/IP under MSDOS.
Many thanks to the people that responded. Now I would like to make
another query that I'm quite sure will have a much smaller response.

Does anyone have any information about TCP/IP sources under MSDOS
written in Pascal? (for sale or public domain) I'm doing a cost and
time estimate for porting TCP/IP to a proprietary platform that 
does not have a C compiler. 

Please mail responses to me directly and I will summarize the results
in a later posting.

David Levine

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

	
     ...         ...
    .    .     .    .	David Levine
    .     *   .     .	Software Engineer
     .      .      .
      .   .   .   .	Bruker Instruments Inc. USA
       . BRUKER .	Billerica, MA. 01821
      .   .   .  .
     .      .     .	
    .     *  .     .	dple@bii.bruker.com		Internet
     ...        ...     ...!{uunet,ulowell}!bii!dple	UUCP

=================================================================
-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      18 Jan 90 18:56:02 GMT
From:      gauss.llnl.gov!casey@lll-winken.llnl.gov  (Casey Leedom)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  tcp port numbers
| From: stev@VAX.FTP.COM
| 
| Personally, I liked the idea of charging back for the packets:)

  Don't forget to charge the broadcast storm packets too.  And the CPU
time stolen from all the machines that were uselessly interrupted.
-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Jan 90 11:22:52 CST
From:      Buster Hale <CCBUSTER%UMSVM.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP <tcp-ip%nic.ddn.mil@cunyvm.cuny.edu>
Subject:   TCP/IP for 3B2
Could someone provide me with the names and telephone numbers of TCP/IP
for 3B2 vendors?  We just received a 3B2/1000 RUNNING System V 3.2.1 that
I want to put on our ethernet campus backbone.  Thanks in advance.

E.F. ("Buster") Hale, III, LL.M.  BITNET:   ccbuster@umsvm
Manager, Computing Services       INTERNET: ccbuster@vm.cc.olemiss.edu
The University of Mississippi     PHONE:    (601) 232-7206
Powers Hall #322                  FAX:      (601) 232-7180
University, MS.  38677
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 90 13:07:15 GMT
From:      cs.utexas.edu!uwm.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!ssw@tut.cis.ohio-state.edu  (Steve Wallace)
To:        tcp-ip@nic.ddn.mil
Subject:   Novell <==> SMTP gateway (free)
We make some modification to Phil Karn's KA9Q code an produced a
working Novell <==> SMTP gateway for our Novell networks.  The
modification allow Novell's directory based security to work and
provide notification of new mail via Novell's send command.
We're also using a slightly modified version of BM for the end
user interface.

There is basically no documentation on the modification we did
and we offer NO support, but if you are interested drop me a note
and I'll arrange to get the code to you.


Steven Wallace
Indiana University
ssw@lavanix.bacs.indiana.edu
-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Fri, 19 Jan 90 14:19:42 SET
From:      David Stafford <ESC1814%ESOC.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Novell Networks
Hi,

Micom do a TCP/IP gateway for Novell systems. This is an ethernet card you
can put in the server. You then just attach to the gateway, and can send
and receive SMTP mail, do telnet, FTP etc. This seems to work pretty
well most of the time, although we have had a couple of workstations hang
up a few times when exiting a telnet session.

In general though the Micim-Interlan product seems to be ok. You may have to be
careful about your Novell version, check with the micom people.

Dave Stafford
European Space Operations Centre
Darmstadt, W. Germany.
tel : (49) 6151 886 907
fax :   same        908
-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 90 17:19:04 GMT
From:      buit13!kwe@CS.BU.EDU  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Interior Gateway Protocol Summary
In article <1847@ncrcce.StPaul.NCR.COM> John.Cavanaugh@StPaul.NCR.COM
 (John Cavanaugh) writes:
>A short time ago, I posted a query to comp.protocols.tcp-ip asking
>which interior gateway protocols people actually use.  I got 16 replies
>to my query, which doesn't make for a statistically meaningful sample,
>but most people who responded were interested in the results, so I
>thought I'd post them.
> ...
>Some pertinent comments:
>
>    "We are limping along using RIP and Hello ..."
>
>    "The Cisco access-list filtering on IP and DECNET routing is
>    ESSENTIAL for us to get it functioning." 
>
...
>
>    "Think firewalling, not OSPF versus ODV."
>
>    "... we don't have to worry about brain-dead hosts broadcasting
>    bogus RIP packets."
>

	If I may be so bold as to extract a common thread from these
comments:

	Seems to me that the "authentication" of incoming IGP data (or
firewalling) is as important, if not more important, than the actual
IGP protocol.  (I don't want to start any link-state versus distance
vector flame wars here.)  Ironically, this is not usually considered
part of an IGP standard.  The biggest improvement I see in OSPF and
ODV(IGRP) is the ability to shield the router from accepting bogus
data.  In the case of OSPF it is protection by authentication, but any
good OSPF implementation would have filters on data accepted via RIP
(which falls outside the OSPF spec).  IGRP has the admin distance
feature (which may or may not make it into an ODV RFC) and filters on
inter-protocol exchanges as well.  Gated has all kinds of filters.
Routed does not have any (nor does Proteon RIP) and we all suffer
greatly because of this.

	I wonder if filtering and firewalling capabilities should be
an explicit part of the new Router Requirements RFC?  I'll have to
send in a comment to the new working group.

	I should say that one of the above comments ("Think
firewalling,...) is mine, but I was surprised to see that all the
comments I extracted have to do, in one way or another, with routing
data "authentication" or firewalling.  Seems like a common theme to
me.

	Kent England
-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 90 17:22:52 GMT
From:      CCBUSTER@UMSVM.BITNET (Buster Hale)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP for 3B2

Could someone provide me with the names and telephone numbers of TCP/IP
for 3B2 vendors?  We just received a 3B2/1000 RUNNING System V 3.2.1 that
I want to put on our ethernet campus backbone.  Thanks in advance.

E.F. ("Buster") Hale, III, LL.M.  BITNET:   ccbuster@umsvm
Manager, Computing Services       INTERNET: ccbuster@vm.cc.olemiss.edu
The University of Mississippi     PHONE:    (601) 232-7206
Powers Hall #322                  FAX:      (601) 232-7180
University, MS.  38677

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 90 15:45:55+0100
From:      Fritz Buetikofer <btkfr@id.unibe.ch>
To:        <TCP-IP@NIC.DDN.MIL>
Subject:   Another TCP/IP printing protocol
Hello TCP/IP print fellows,
  my name is Fritz Buetikofer and I am working at the university of Berne
(Switzerland). For almost two years now I am developping, in a joint project
with a computer manufacturer, a distributed print service using the TCP/IP
protocol. Our intention is to be able to print from all networked stations
- standalone or connected to institute (and central) hosts - on any printer
connected to our university network. On the printer side we would like to
offer POSTSCRIPT facilities.

So here is the story of our project so far ...

-- History --

When I started in mid 1988 I just had a PC/AT with an Ungermann/Bass 
ethernet card and TCP/IP software. The next step was setting up a PC Print-
Server which consists of a PC connected to a laserprinter, running DesqView.
Under DesqView I run simultaneously an FTP-Server task and a print-spool
task which takes print-jobs from a spool-directory and prints it on the 
attached printer (this may be even a LQ-matrix printer).

I know that there are products out (for PCs, VAXes and others) which implement
the well known LPR command from bsd-UNIX. But had no access to software
which included this LPR command, and I had no TCP/IP development software 
to port LPR to some systems. So I decided to implement another way to do it !!

-- Actual Implemetation --

One program which is always available for TCP/IP attached hosts or PCs is FTP.
So I implemented three new commands for distributed printing, which use FTP
(in the future even DECNET-COPY, for those VAXes having no TCP/IP):

  *  RPRINT  - Send one or multiple print-files, each with an according 
               description file to a central station. Automatic filetype 
               detection and page-orientation included.
  *  RSTATUS - Show up the status of all available printers and all print-jobs
               initiated from one account.
  *  RCANCEL - Cancel a print-job.

As you see under the RPRINT-command I set up a central dispatch station, 
which handles all conversion tasks (DVI -> PS, or ASCII -> PS) and which 
accesses all host-printers using either the LPR way or SunlinkDNI's way to
print on DECNET printers.
    My first attempt for this central station was an IBM 9370 running VM.
But it was not possible to have multiple FTP sessions to the same account
with WRITE access. After some time waiting for AIX for the 9370 machine,
I moved on to a SUN386 under SunOS4, which is the actual state.

With the following simple drawing I would like to clarify the actual
situation as I set it up at our campus network:

  +----------+  +----------+   +----------+  +-----------+  +----------+
  | IBM MVS  |  | DEC/VAX  |   | any UNIX |  | AppleTalk |  | PC Print-|
  |K200/KNET |  |TCP&DECNET|   | System   |  | Network   |  | Server   |
  +----------+  +----------+   +----------+  +-----------+  +----------+
    |      |      |     |        |    |        |   |          |    |
    |  +------+   |  +-------+   | +-------+   | +-------+    |  +-------+
    |  | 3800 |   |  | Laser |   | | Laser |   | | Laser |    |  | Laser |
    |  +------+   |  +-------+   | +-------+   | +-------+    |  +-------+
    |             |              |             |              |
    A RJE via     A lpr or       A lpr         A lpr using    A ftp          
    |  FTP        | DECNET-Print |             | TOPS         |
    |             |  Sunlink DNI |             |              |
    +----------+  |              |             |   +----------+
               |  |              |             |   |
         +-----------------------------------------------+
  SUN386 |   Central dispatch system with the following  |
         |   options:                                    |
         |    * Conversion to PS from ASCII,DVI,BIN,HPGL |
         |    * Central tables: PRINTER-List & JOB-List  |
         |    * Demons which update the upper lists.     |
         |    * No authorizing needed for all users,     |
         |      as needed for all LPR implementations !  |
         |    * Expansion to multi-university environment|
         |      actually in preparation.                 |
         +-----------------------------------------------+
           A                          A
           | FTP                      | FTP or DECNET-COPY
      +----------+           +------------------+
      |Standalone|           | Institute or     |
      |   PC     |           | central hosts    |
      +----------+           |  - IBM VM or MVS |
  +--------------+           |  - DEC VAX       |
  |     --- ---  |           |  - any UNIX syst.|
  +--------------+           +------------------+

Of course each implementation on the various systems includes features
as piping (DOS & UNIX), wildcards (many), concatenation: file1+file2 and
preallocated data sets (IBM MVS).

To support National Language Support for the printers (only for filetypes 
ASCII or EBCDIC), I have several PostScript-Include-Files which reencode
the whole character set to the originating system. Especially for PC senders
I had to redefine the Courier-Font (now call PC-Courier) to enable all
characters, including accented and drawing characters. Before printing ASCII
jobs, these Include-Files are put in front of the job.

Well for the moment I think this is enough information on our distributed
printing system. If you have questions or suggestions to our concept,
feel free to contact me under my e-mail address.

Fritz Buetikofer                  INTERNET: btkfr@id.unibe.ch
University Berne                  BITNET:   U02F@CBEBDA3T
Informatikdienste
CH-3012 Bern (Switzerland) 

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 90 19:08:30 GMT
From:      ucsdhub!hp-sdd!ncr-sd!ncrcae!wingo@ucsd.edu  (Dave Wingo)
To:        tcp-ip@nic.ddn.mil
Subject:   lance on micro-channel

 I am interested in knowing if there are any micro-channel adapters available 
which utilize the AMD LANCE chip???? Additionally, which micro-channel ethernet
card is considered the best performing adapter????  I know that transport
implementations will effect performance so please indicate how you tested 
performance.........

Thanks in advance
wingo@Columbia.NCR.COM
-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 90 20:34:30 GMT
From:      .sunysb.edu!root@sbcs.sunysb.edu  (Systems Staff)
To:        tcp-ip@nic.ddn.mil
Subject:   Duplicate ICMP packets out of Internet

The following typescripts documents a problem we're seeing
today as we look towards rutgers.edu from sbcs.sunysb.edu.
Out of curiousity, does anyone know the cause of ICMP packet 
thats seems to occur on occasion in the Internet?

				Rick Spanbauer
				State U of NY/Stony Brook

-----------------------------------------------
Script started on Fri Jan 19 15:26:56 1990
sbcs.1 ping -s rutgers.edu
PING rutgers.edu: 56 data bytes
64 bytes from 128.6.4.7: icmp_seq=10. time=140. ms
64 bytes from 128.6.4.7: icmp_seq=11. time=360. ms
64 bytes from 128.6.4.7: icmp_seq=11. time=380. ms
64 bytes from 128.6.4.7: icmp_seq=12. time=160. ms
64 bytes from 128.6.4.7: icmp_seq=13. time=140. ms
64 bytes from 128.6.4.7: icmp_seq=14. time=160. ms
64 bytes from 128.6.4.7: icmp_seq=15. time=460. ms
64 bytes from 128.6.4.7: icmp_seq=16. time=180. ms
64 bytes from 128.6.4.7: icmp_seq=17. time=180. ms
64 bytes from 128.6.4.7: icmp_seq=18. time=160. ms
64 bytes from 128.6.4.7: icmp_seq=19. time=160. ms
64 bytes from 128.6.4.7: icmp_seq=20. time=180. ms
64 bytes from 128.6.4.7: icmp_seq=21. time=160. ms
64 bytes from 128.6.4.7: icmp_seq=21. time=200. ms
64 bytes from 128.6.4.7: icmp_seq=22. time=160. ms
64 bytes from 128.6.4.7: icmp_seq=23. time=160. ms
64 bytes from 128.6.4.7: icmp_seq=25. time=160. ms
64 bytes from 128.6.4.7: icmp_seq=26. time=160. ms
64 bytes from 128.6.4.7: icmp_seq=27. time=160. ms
64 bytes from 128.6.4.7: icmp_seq=28. time=160. ms
64 bytes from 128.6.4.7: icmp_seq=29. time=200. ms
^C
----rutgers.edu PING Statistics----
30 packets transmitted, 21 packets received, 30% packet loss
round-trip (ms)  min/avg/max = 140/199/460

PING rutgers.edu: 56 data bytes
64 bytes from 128.6.4.7: icmp_seq=0. time=439. ms
64 bytes from 128.6.4.7: icmp_seq=27. time=200. ms
^C
----rutgers.edu PING Statistics----
28 packets transmitted, 28 packets received, 0% packet loss
round-trip (ms)  min/avg/max = 160/258/1060
sbcs.3 !!
ping -s rutgers.edu
PING rutgers.edu: 56 data bytes
64 bytes from 128.6.4.7: icmp_seq=0. time=299. ms
64 bytes from 128.6.4.7: icmp_seq=0. time=320. ms
64 bytes from 128.6.4.7: icmp_seq=1. time=1160. ms
64 bytes from 128.6.4.7: icmp_seq=2. time=320. ms
64 bytes from 128.6.4.7: icmp_seq=2. time=580. ms
64 bytes from 128.6.4.7: icmp_seq=2. time=580. ms
64 bytes from 128.6.4.7: icmp_seq=3. time=220. ms
64 bytes from 128.6.4.7: icmp_seq=4. time=180. ms
64 bytes from 128.6.4.7: icmp_seq=5. time=260. ms
64 bytes from 128.6.4.7: icmp_seq=6. time=200. ms
64 bytes from 128.6.4.7: icmp_seq=7. time=200. ms
^C
----rutgers.edu PING Statistics----
8 packets transmitted, 11 packets received, -37% packet loss
round-trip (ms)  min/avg/max = 180/392/1160
sbcs.4 traceroute rutgers.edu
traceroute to rutgers.edu (128.6.4.7), 30 hops max, 38 byte packets
 1  proteon.sunysb.edu (129.49.2.1)  20 ms  40 ms  20 ms
 2  columbia-stonybrook.nyser.net (128.145.175.1)  40 ms  60 ms  40 ms
 3  cornell-columbia.nyser.net (128.145.30.1)  60 ms  120 ms  60 ms
 4  NSS.TN.CORNELL.EDU (192.35.82.100)  60 ms  60 ms  60 ms
 5  Pittsburgh.PA.NSS.NSF.NET (129.140.69.10)  100 ms  80 ms  80 ms
 6  Princeton.NJ.NSS.NSF.NET (129.140.72.5)  120 ms  120 ms  120 ms
 7  zaphod-gateway.jvnc.net (128.121.54.72)  140 ms  140 ms  140 ms
 8  zarniwoop-gateway.jvnc.net (130.94.0.77)  160 ms  140 ms  160 ms
 9  capital2-gateway.jvnc.net (130.94.3.9)  380 ms  160 ms  160 ms
10  airport1-gateway.jvnc.net (130.94.3.249)  140 ms  160 ms  160 ms
11  airport2-gateway.jvnc.net (130.94.8.2)  180 ms  160 ms  180 ms
12  rutgers-gateway.jvnc.net (130.94.9.10)  160 ms  180 ms  160 ms
13  dcs-gw.rutgers.edu (128.6.21.3)  140 ms  140 ms  200 ms
14  * * *
15  *^Csbcs.5 
sbcs.5 exit
sbcs.6 
script done on Fri Jan 19 15:28:52 1990
-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      19 Jan 90 22:30:44 GMT
From:      van-bc!ubc-cs!alberta!mts.ucs.UAlberta.CA!ualtavm!DKRUGER@ucbvax.Berkeley.EDU  (Dwight Kruger)
To:        tcp-ip@nic.ddn.mil
Subject:   Packet drivers
I wish to run NCSA telnet 2.2TN on my IBM PC's and PS/2's using packet
drivers.  Where can I find freeware or public domain packet drivers
for Western Digital WD8003 and Ungermann-Bass PC/NIC cards?
-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 90 03:48:13 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!rpi!image.soe.clarkson.edu!news@ucsd.edu  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Packet drivers

   I wish to run NCSA telnet 2.2TN on my IBM PC's and PS/2's using packet
   drivers.  Where can I find freeware or public domain packet drivers
   for Western Digital WD8003 and Ungermann-Bass PC/NIC cards?

There are no freely copyable packet drivers for the UB PC/NIC.  I know
someone who was going to write one, but he couldn't get the documentation
from Ungermann-Bass.  Oh well.

Why do hardware manufacturers make it so difficult for people to write
software for their hardware?  I had to sign a multiple-sheet
nondisclosure agreement for the documentation for the Racal-Interlan
NI9210.  Fortunately, they just handed me the driver development kit
for the NI6510.  Unfortunately, it lacked crucial information on the
LANCE chip.  Fortunately, a friend FAXed it to me.

This is a typical experience.

Jeepers, what a hassle!

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problems
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 90 04:34:54 GMT
From:      venus!leichter@CS.YALE.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Ethernet Type assignment
In article <8912241243.AA26846@ucbvax.Berkeley.EDU>, VSBENZI@WEIZMANN.BITNET
(Benzi mizrahi) writes:
> Hello all,
> 
>  anyone knows what authority assigns Ethernet Type numbers?
> 
>  Thanx, Benzi
> 
> Computing Center,
> Weizmann Institute of Science,
> Rehovot,
> Israel

By an interesting coincidence, I needed to run down exactly this information
not long ago.  It took a little searching, but here's the story.

Xerox assigns these numbers for the IEEE.  The current "registrar" for these
numbers is Fonda Pallone, who can be reached at (408) 737 4652.  She is very
friendly and helpful.  If you just want to go ahead and reserve a number,
send a letter on a corporate letterhead - presumably a university letterhead
will do - to her at:

		Xerox Systems Institute
		475 Oakmead Parkway
		Sunnyvale CA 94086
		Attn:  Fonda Pallone

In your letter, you must specify the name of the person at your company who
will serve as contact for information concerning the protocol type.  You must
also enclose a check or purchase order for US$300.  For this price, you can
request any number of protocol types.

Within a couple of weeks, you'll receive your numbers and some forms to fill
out.  You can specify whether you want your company name and the protocol to
be publicly known or kept private.

Ms. Pallone was surprised when I told her that people spend a lot of time
tracking down protocol assignments; she will provide a list to anyone getting
a protocol, and presumably would be willing to work something out with anyone
who just wanted a list.  The private protocols are not, of course, included
but I gather that most protocols are "published".
							-- Jerry
-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Sat, 20 Jan 90 14:43:53 EST
From:      Rob Austein <sra@lcs.mit.edu>
To:        TCP-IP@nic.ddn.mil
Subject:   Resolver implementation
We took a somewhat different path in the CHIVES resolver (TOPS-20).
The RESOLV.CONFIG file allows one to specify an ordered list of
suffixes to be appended to a name that does not end with a dot (there
is also a way for programs to disable the search path mechanism).  A
suffix of "." is legal, and denotes that the name should be tried as
specified at this point in the search path specified by this list of
sufixes.  We also implemented negative response caching, of course.

This mechanism allows for a lot of tuning.  The configuration that
most sites seemed to settle on was: (1) look for local abbreviations
which you consider reasonable, then (2) try assuming that the name was
meant as specified, then (3) try looking for abbreviations which you
do not consider reasonable but are willing to forgive, then (4) give
up.  Step (2) is the "." suffix.  Step (3) used to include things like
the "ARPA." suffix, but can include any name suffix that you think is
less likely to occur than a fully specified name.

As a side note: step (3) is also the place to put a "local" suffix
that will cause excessive network traffic due to nameservers that do
not give SOA RRs in the Authority section of an authoritative negative
response, since negative responses from such nameservers cannot be
cached.  This should only be done as a last resort, since it is fairly
anti-social.

--Rob Austein
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 90 16:29:45 GMT
From:      david@g.ms.uky.edu  (David Herron -- a slipped disk)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PEP and SL/IP
In article <224@tw-rnd.SanDiego.NCR.COM> jml@tw-rnd.SanDiego.NCR.COM (Michael Lodman) writes:
>Problem: I can get SL/IP running in the V.32 mode of the modems, at 9600bps
>interface speed. When I try to run at 19200bps PEP, SL/IP will not work.
>
>Is this a problem with the Sun serial ports, PEP, or SL/IP? 

Well, I've heard things that imply the Sun serial ports are silly,
except for the "CPU port" (I suppose that's a serial port that's directly
on the CPU board..?).  I get this information from people over in
comp.mail.uucp who have interfaced trailblazers to Sun-3's.  For all
I know later Sun designs have fixed the serial port problem.

But there's gonna be problems coming in because of SLIP itself.  SLIP
isn't a half duplex protocol, whereas PEP *is* half duplex.  PEP looks
to be bi-directional because it turns itself around and also has an
interactive mode where the packets are very small but turn around
quickly.  Besides, SLIP occasionally sends large packets around,
which'll keep the T2500 & PEP protocol from slipping into the
interactive mode.

You have it working with V.32 (shouldn't be too hard since it's a
full duplex protocol..) so why go farther?  You say you want the
19.2 kbaud?  Sorry...
-- 
<- David Herron; an MMDF guy                              <david@ms.uky.edu>
<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<- 
<- New official address:  attmail!sparsdev!dsh
-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 90 17:31:07 GMT
From:      david@g.ms.uky.edu  (David Herron -- a slipped disk)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Looking for distributed name service
Here's two suggestions:

1: Use existing DNS name service.  Set aside a sub domain, "serves.what.ever"
say.  In services.what.ever the names map to A records (multiple) which
are for hosts which provide that service.  (eg, rlogin.services.what.ever
lists the hosts which can provide rlogin service).  Applications needing
access to a service query for the appropriate A record to find the host.
Next, probably, the portmapper protocol is appropriate to find which
socket to talk to.

As hosts which provide a service come and go you must tell a central
authority about the transition.  The central authority will then
rebuild its SOA file for the services domain and tell its named to
reload the file.  This also means the TTL for the zone has to be pretty
low -- depending on the frequency of hosts being added and removed.

There may be a way to make the central authority be a distributed
central authority.   I can think of one way but it involves having
more than one physical machine answering to the same name using only
IP addresses to distinguish between them.  (Each physical machine
would also have a true name it answers to..)


2: A variant of arp .. make a broadcast saying "who-services rlogin".
From there you use portmapper..

3: (Extra special possibility offered as a one-time deal only) a
variant of the portmapper protocol.  You do a broadcast, once, asking
for the hosts which have a service mapper running.  When a host needs a
service it consults its list of service mappers asking one (all?) of
them for recommendations.  As a host goes up/down it should also enroll
itself with the service mappers..  As service mappers go up and down
they should tell the network of this.



-- 
<- David Herron; an MMDF guy                              <david@ms.uky.edu>
<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<- 
<- New official address:  attmail!sparsdev!dsh
-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 90 18:15:48 GMT
From:      mcsun!sunic!draken!perand@uunet.uu.net  (Per Andersson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Novell Networks
In article <470@secola.Columbia.NCR.COM> krupczak@secola.UUCP (Bobby Krupczak) writes:
>In article <863@umabco.UUCP> lwilson@umabco.UUCP (Lowell G. Wilson) writes:
>>
>>Does anyone know of a Novell LAN-based mail package that will talk SMTP?
>
>Novell is working on "Portable" Netware.  This product is written to run
>on Unix as well as VMS machines.  NCR is one company that will offer
>"Portable" Netware on its Unix boxes. 

Actually Novells Portable netware is just some sourcecode. Prime is
porting this to their and others 386 Unix machines, contracted by
Novell I think. If there is an easy way to transport mail because of
this I don't know.

One university in Sweden is working on a system with a dedicated client
on the Novell network running KA9Q+some driver for finding spoolfiles
and a screenoriented client software for sending and receiving mail.

If one doesn't have to have security on messages, and the user-friendly
inteface one might be able to use one of the existing PC SMTP mailers
for KA9Q on the clients. Some hacking would be needed though.

Per
-- 
---
Per Andersson
Royal Institute of Technology, Stockholm, Sweden
perand@admin.kth.se, @nada.kth.se 
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      20 Jan 90 20:37:33 GMT
From:      polygen!bill@CS.BU.EDU  (Bill Poitras)
To:        tcp-ip@nic.ddn.mil
Subject:   KA9Q with direct connection to Intenet

	I have just recently hooked up a PC w/ a 3C501 card to a CISCO router 
which has a Internet connection.  I haven't talked to the network people at our
installation yet, but I have a few questions that they probably won't be able
to answer anyway.  How do set up net so I can ftp/telnet/etc... out?  My
network mask (I pretty sure) is 137.103.255.255.  This information I got from
the NIC.  What route entrys do I need to set up?  Arp entries? Rip entrys.
Is it necessary for me to know the IP address of the CISCO router?  I'm sure
I will get some of this answered by my people (I work on weekends, they don't
so communication is difficult), but any help anyone can give would be greatly
appreciated.  


+-----------------+---------------------------+-----------------------------+
| Bill Poitras    | Polygen Corporation       | {princeton mit-eddie        |
|     (bill)      | Waltham, MA USA           |  bu sunne}!polygen!bill     |
|                 |                           | bill@polygen.com            |
+-----------------+---------------------------+-----------------------------+
-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 90 00:03:20 GMT
From:      stealth.acf.nyu.edu!brnstnd@nyu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   why IP should pass UID information
Welcome to the real world. If the Internet were economically sound, each
packet would carry enough user information to let costs be sensibly
distributed. Instead, it's impossible to trace expenses further than
to a single machine. This problem has other effects: it is the only
security hole above TCP. Doesn't anybody care about mail forgery?

> UID's and GID's are inherently OS-specific

So? The encoding of the user information is irrelevant; two-byte integers
just happen to be a compact, portable standard. What matters is that the
information be passed along.

> Additionally, some protocols are not used between
> user processes, but between systems in general (what UID should be
> associated with ICMP datagrams?  what's the UID on a terminal
> concentrator?).

Who pays for the janitor? Who do you charge for use of the building
water fountain? Obviously the system is shared, and some costs can't be
directly allocated to a single user. In these cases the UID is 0. The
same applies to your Macintosh or PC: who pays for your house?

(By the way, leaving a terminal concentrator open to foreign connections
is like moving some water fountains outside for the public. If you give
away your water, be prepared to pay for it.)

> The primary purpose of transport protocols such as TCP is to make a single
> physical link appear to be multiple links (i.e. multiplexing).  Since
> simple links don't pass user identity along, multiplexed links don't need
> to, either.

Arguments based on the status quo (it doesn't, therefore it shouldn't)
are very shaky. Anyway, single TCP connections (and single UDP packets)
usually correspond to single users, so the appropriate place is probably
in each TCP packet. If it's easier for IP to carry the information, then
let IP carry the information.

> Application protocols should be independent of the mechanism
> used to establish the link; if they need to know user identities, then
> they'll need to pass it themselves when used over simple links, so it would
> be redundant to have the multiplexing protocol pass it as well.

Let me repeat that with a few words changed.

  Application protocols should be independent of the mechanism used to
  establish the link; if they need to know the connecting host name,
  then they'll need to pass it themselves when used over simple links,
  so it would be redundant to have lower layers pass it as well.

Hence packets shouldn't include source host information, and BSD
shouldn't have a getpeername() call? Don't be ridiculous.

---Dan
-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Jan 90 11:51:31 PST
From:      gww@EBay.Sun.COM (Gary Winiger)
To:        comp.protocols.tcp-ip
Subject:   Re: R programs
In article <9001181327.aa20258@COR3.PICA.ARMY.MIL> bkulback@PICA.ARMY.MIL ("Bruce A. Kulback", IMD-TB) writes:
>currently available on unix.  Could you please send me any RFC information
>regarding "rlogin" or tell me how to find such information. 

	This question has been asked in the past and I recall always appears
with the same answer.  The experimental Berkeley clients and servers supporting
the R commands have not been formally defined in an RFC, I don't have my
copy of McKusick, Karels, et al handy, but I don't believe they are in there 
either.  The only place I've seen them documented is in the code that implements
them.  The comments in rlogind that describe the protocol are:
	/*
	 * remote login server:
	 *      remuser\0
	 *      locuser\0
	 *      terminal info\0
	 *      data
	 */
The comments in rshd that describe the protocol are:
	/*
	 * remote shell server:
	 *      remuser\0
	 *      locuser\0
	 *      command\0
	 *      data
	 */

	I'd say your best bet is to get a copy of the code and disect it.  You
might then ask for permission publish the protocols so future requesters will
have a place to read about them.

Gary..
-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 90 04:01:17 GMT
From:      aramis.rutgers.edu!geneva.rutgers.edu!hedrick@rutgers.edu  (Charles Hedrick)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Interior Gateway Protocol Summary
As chairman of the IETF Open Distance Vector task force, let me point
out that comments about "ODV(IGRP)" imply something that isn't true:
that ODV would be based on IGRP.  My current guess is that ODV won't
happen at all, since messages to the mailing list asking whether
people really have time to do anything about it have not gotten any
response.  But the initial plans were for ODV to be based on Jose
Garcia-Luna's work, which is quite different from IGRP.  It was to be
a completely new protocol.

cisco has indicated some interest in making IGRP an industry standard.
However IETF'ers were not interested in working on a standard that had
a patent claim attached.  I'm not sure this is a realistic attitude,
but that's the way it was.  I have done some work on IGRP recently,
with the goal of making it behave reasonably in the face of an
interface that is flapping.  I've eliminated holddowns, and made a few
associated changes.  (This is strictly work for Rutgers.  Although
I've given it to cisco, I don't know what plans they have.  Certainly
any elimination of holddowns would be a configuration option, with the
default behavior being to do holddowns.)  As far as I can tell, I'm the
only person currently working on IGRP.
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      Sun, 21 Jan 1990 22:24:37 PST
From:      Rob Liebschutz <oc.uucp!rob@orc.olivetti.com>
To:        tcp-ip@nic.ddn.mil
Subject:   program to maintain database of host addresses
I have a vague recollection of a discussion several months ago about
software to maintain a database of host addresses.  I now have need
for such a program.  In one sense, it would be ideal for such a
program to be integrated with the zone file, though we also have
requirements to store addresses for protocols other than IP.

Does anyone know of any software (either free or for sale) to do this?

Rob
-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 90 18:28:08 GMT
From:      zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!ssw@tut.cis.ohio-state.edu  (Steve Wallace)
To:        tcp-ip@nic.ddn.mil
Subject:   Novell <==> SMTP (where to get the code)
We have about a dozen Novell (2.15) servers inter-connected via
our broadband ethernet.  Everything is econfiged, for telnet
access we use NCSA telnet and tn3270.  Currently, one department
on campus is using the mail gateway.  About 20 users for the last
3 months.  So far, its routed over 5000 mail messages.  We have
one 4.77 Mhz IBM PC with a floppy drive running the ka9q code
acting as the SMTP gateway.  The user mail boxes are located on
the computing services server.  The department using the gateway
has their own server, but we thought it would be easier to have a
central mail server.  The project could be scaled up to handle
all the Novell connected PC's by adding disk space to the central
server.
 
The source for ka9q and bm are available via a guest account on
lavanix.bacs.indiana.edu [129.79.16.190] for a limited time.  The
sources are in lavanix:~guest/mail_gateway/.  YOU CANNOT
ANONYMOUSLY FTP TO LAVANIX.  YOU MOST LOGIN AS guest (NO
PASSWORD) AND START LAVANIX'S CLIENT FTP SERVER!!!!  The files
are in zip format (ver 1.02).  I used Turbo C version 2.0 to make
the binarys.
 
Changes to Ka9q code.
 
     If the environment variable "KA9Q" exists, all file names
     are prefixed with it. (See function prefix_paths() in
     files.c)
 
     The mail boxes are now located in
     mailspool/username/username.txt.  This allows Novell's
     directory level security to be used.  (See function mailit()
     in smtpserv.c)
 
     If the file mailspool/username.dat exists, each line is read
     and executed by the shell command (this happens every time
     username gets new mail).  This is used to notify the user of
     new mail.  Our files look something like this.
 
          attach servername/guest
          send "You have new mail" to username
          logoff servername
 
     (See functions mailit() and notify_users() in smtpserv.c)
 
     If mailspool/username doesn't exist, the smtpserver responds
     with a bad address error.  (See validate_address() and
     docommand() in smtpserv.c)
 
     
 
Changes to BM code.
 
     If the environment variable "BMFILES" exists, mailspool and
     mailqdir are prefixed with it. (See function prefix_paths()
     in files.c)
 
     We have batch files that look something like this.
 
     set BMFILES m:\iumail\
     attach mailserver/username
     map m:=mailserver/sys:
     bm
     logoff mailserver
-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 90 19:24:42 GMT
From:      ESC1814@ESOC.BITNET (David Stafford)
To:        comp.protocols.tcp-ip
Subject:   Re: Novell Networks

Hi,

Micom do a TCP/IP gateway for Novell systems. This is an ethernet card you
can put in the server. You then just attach to the gateway, and can send
and receive SMTP mail, do telnet, FTP etc. This seems to work pretty
well most of the time, although we have had a couple of workstations hang
up a few times when exiting a telnet session.

In general though the Micim-Interlan product seems to be ok. You may have to be
careful about your Novell version, check with the micom people.

Dave Stafford
European Space Operations Centre
Darmstadt, W. Germany.
tel : (49) 6151 886 907
fax :   same        908

-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      21 Jan 90 19:33:59 GMT
From:      sundc!newstop!grapevine!koreth%panarthea.ebay.sun.com@seismo.css.gov  (Steven Grimm)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: why IP should pass UID information
In article <29288@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes:
>  Application protocols should be independent of the mechanism used to
>  establish the link; if they need to know the connecting host name,
>  then they'll need to pass it themselves when used over simple links,
>  so it would be redundant to have lower layers pass it as well.

Cute, but there's one problem: how does, say, TCP figure out where to send a
reply packet if it doesn't have foreign host information?  It can route
perfectly well without foreign user information.  So the two are in no way
equivalent; one is necessary for proper operation of the protocol, while the
other is not.

---
"                                                  !" - Marcel Marceau
Steven Grimm		Moderator, comp.{sources,binaries}.atari.st
koreth@ebay.sun.com	...!sun!ebay!koreth
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 90 00:00:02 GMT
From:      zaphod.mps.ohio-state.edu!wuarchive!texbell!petro!swrinde!dpmizar!csoftec!root@tut.cis.ohio-state.edu  (Cliff Manis (cmanis@csoftec))
To:        tcp-ip@nic.ddn.mil
Subject:   Registration of FTP site ?

     ---->    FTP Information Wanted     (registration & cost)   <---- 

 I would appreciate any info about:

     a.  How one gets an application to have a registered FTP number ?

     b.  What is required for a connection to another site for its use ?

     c.  Approximately how much does it cost per month, is this pro-rated
             by use and distance of communications contact ?

 I am very interested in having FTP and/or TCP available at this site.

 Please send info to me or answer here on the net, and Thanks 2 all...

    cliff
_  
  Cliff Manis       K4ZTF 
  INTERNET: cmanis@csoftec.csf.com    UUCP: {swrinde|texbell}!csoftec!cmanis
                 Unix & Xenix today for a better tomorrow 
-
-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      Mon Jan 22 7:37:46 CST 1990
From:      mef@tel3b2.telecom.lsu.edu
To:        tcp-ip@sri-nic.arpa
Subject:   Re:
To whoever was asking about TCP/IP on 3B2/1000.
(I cut of the mail header and forgot who it was)

TCP/IP is available from AT&T.  They resell Wollongong's version.  While it
has problems, I have personally weeded out many with AT&T and Wollongong
support people and have been able to make great progress with their support
people.  The current version is 3.0.1.  Make sure you get the 3.0.1 sendmail
patch (If you decide on this particular product, feel free to call me and I
can discuss the details with you.)  For the 3B2/600, the cost is about $5K.
Documentation is sketchy but that's par for the course.  For your info, we are
running UNIX 3.2.1 on a 3B2/600 (interested in upgrading to a /1000).  How do
you like your machine?

Michael E. Fox
Assistant Director
LSU Telecommunications
203 David Boyd Hall
Baton Rouge, LA 70803
(504) 388-5295
mef@tel3b2.telecom.lsu.edu


-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jan 90 10:07:25 PST
From:      braden@venera.isi.edu
To:        buit13!kwe@cs.bu.edu, tcp-ip@nic.ddn.mil
Cc:        braden@venera.isi.edu
Subject:   Re: Interior Gateway Protocol Summary

		I wonder if filtering and firewalling capabilities should be
	an explicit part of the new Router Requirements RFC?  I'll have to
	send in a comment to the new working group.

Kent,

Yes.  It is already an explicit part of RFC-1009 (Section 4.4, for
example), but needs to be made much more complete and specific.  [The
IAB asked 1.5 years ago for an IETF WG in this area, but for some
reason (I seem to recall something about vendor disinterest) the WG
never happened.  It is certainly an important issue.]

   Bob Braden
   

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jan 90 11:56:28 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   billing for use

    It seems to me the easiest way to bill for IP services is by link.
I.e. company A rents a link of a certain speed from MIDCENTRAL Net.
The monthly rental covers link costs plus the cost of the traffic
that link can put on the network.  MIDCENTRAL Net, can, in turn,
(if desired) pay the NSFNET backbone for its link.
    
    The advantage of this system is that cost recovery is simple,
the bills are predictable (and most people like predictable bills),
and related to usage (people will buy the link speed they need, and
pay for what they use).

    Accounting for packets is a pain.  They can get lost, duplicated,
etc.  So far reports from people who've talked with accountants suggest
the accountants will want refunds for lost packets, and probably don't even
understand the notion of being billed twice (legally) for the same data.

Craig
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jan 90 10:15:07 EST
From:      mac@proteon.com (Michael A. Curtis)
To:        att!cbnewsm!matthews@ucbvax.berkeley.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Twisted Pair Ethernet Feedback
Hi John!

      Would you be interested in a newer technology like 16Mbit Unshielded
Twisted Pair?

Mike C.

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 90 06:17:19 GMT
From:      intercon!news@uunet.uu.net  (Amanda Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: why IP should pass UID information
In article <29288@stealth.acf.nyu.edu>, brnstnd@stealth.acf.nyu.edu writes:
> Arguments based on the status quo (it doesn't, therefore it shouldn't)
> are very shaky. Anyway, single TCP connections (and single UDP packets)
> usually correspond to single users, so the appropriate place is probably
> in each TCP packet. If it's easier for IP to carry the information, then
> let IP carry the information.

A significant amount of traffic is *not* associated with single users: DNS,
(in particular) NNTP, EGP, RIP.  Arguments based on the status quo may be
shaky, but argument by assertion doesn't work much better :-).

Billing and authentication are aspects of the same problem.  Sure, you could
put in a new IP option, but I'd argue it would be more effective and simpler
to do authentication out of band with something like Kerberos and then have
the Kerberos authority tell the gateway what's going on, once again out of
band.  Any gateway that is gathering billing information is going to have
be reasonably smart anyway--it might as well do something like this.

Another approach would be to have the hosts do sub-billing.  They get a bill
from the gateway for the total traffic coming from the host, and they
distribute this to users.  You could put packet accounting in the kernel,
or the user-level programs, or wherever it makes sense to.  This way the
"infrastructure" traffic (routing, DNS, etc.) would automatically be absorbed
by the host/site itself, and user-generated traffic could be billed to the
users in whatever terms are approriate for that site (user, group, project,
whatever).  All this without having to re-engineer the Internet, too.

Amanda Walker
InterCon Systems Corporation
--
-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 90 07:23:30 GMT
From:      mcsun!sunic!tut!santra!kaira.hut.fi!s31786w@uunet.uu.net  (Koivisto)
To:        tcp-ip@nic.ddn.mil
Subject:   Operating system independent TCP/IP

Our company is going to implement a TCP/IP protocol stack in its products.
However, the problem is that our products have an operating system of our
own. So, we can't just go and buy a stack for it.

Because we don't want to invent a wheel again, we are looking for a stack
that we can use. If you have any idea where we could find a portable or
operating system independent TCP/IP-software please let me know.

-- Matti

***********************************************************************
      Matti Koivisto     email: s31786w@kaira.hut.fi
***********************************************************************

     
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jan 90 13:03:40 EST
From:      Doug Nelson <08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu>
To:        "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>
Subject:   Re:  tcp port numbers
From: Casey Leedom

>  Don't forget to charge the broadcast storm packets too.  And the CPU
>time stolen from all the machines that were uselessly interrupted.

Systems that participate in broadcast storms are broken.  They should be
billed for their own noise.  Just bill broadcasts at <packet rate> times
<number of nodes>.  That would discourage needless broadcasts, if it weren't
for the fact that few nets have a packet charge at all.  Personally, I find
that the PC-NFS nuisance packets are much less of a problem than other
noise on the net.

Doug Nelson
Michigan State University
-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 90 11:38:29 GMT
From:      linus!nixbur!nixpbe!gla@think.com  (gla)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Bridges slow down over time.
donegan@stanton.UUCP (Steven P. Donegan) writes:

>The things to look for are re-transmits
>on the link side(probably not your problem here) and multilink q's filling up
>(which probably is your problem). 9600 baud is really slow for what you are
>attempting to do - I always spec a 56k/64k DDS type link for this type of
>connection.

We had bad experience too with serial bridges and file transfers;
these were acceptable since we use 2x160kBd lines.
The problems result from the implementation on the sending machine:
The source machine sends a bulk of data blocks to the net.
In normal operation, all these are received by the target machine,
and the last one is acknowledged.
Over the bridge, the blocks have a delay between two, so they are
each acknowledged.
The TCP/IP implemtation, upon receipt of an acknowledge, assumes all further
data lost and retransmits these. As the data and acknowledges are still on
the way, we received a "retransmission strom".

Rainer Glaschick
Nixdorf Computer AG, Paderborn, Germany
-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jan 90 19:03:00 EST
From:      Frank Solensky <solensky%interlan.interlan.com@RELAY.CS.NET>
To:        sms@WLV.IMSD.CONTEL.COM, tcp-ip@NIC.DDN.MIL
Subject:   Re: TCP Close re 2MSL
In <9001152335.AA11290@WLV.IMSD.CONTEL.COM>,
	sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) asks:
	 
>	would it be a "good idea" to set the length of time a connection
>	stays in the TIME_WAIT state to a (small) multiple of the smoothed
>	round trip time accumulated during the connection's lifetime rather
>	than a fixed (larger than necessary almost all of the time) constant?
>	i find it hard to believe that the TIME_WAIT interval needs to be
>	as large (default is 75 seconds i believe) on an ethernet as it
>	does on a WAN from one coast to the other.

    I don't believe this would work as reliably since the RTT measured on the
TIME_WAIT side of the connection (your side) indicates only how long it takes
for the data that you had sent to be acknowledged.  You can't really take your
RTT as an reliable estimate for the other side's RTT -- for example, network
conditions could have drastically changed since your last RTT measurement
(when your FIN had been ACKed).
					Frank Solensky
					Racal InterLan

PS: The BSD code I just looked (4.3) at uses a MSL timer of 15 seconds (so
2MSL == 30 seconds).

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 90 14:59:40 GMT
From:      mailrus!umich!samsung!zaphod.mps.ohio-state.edu!wuarchive!texbell!attctc!convex!datri@tut.cis.ohio-state.edu  (Anthony A. Datri)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PEP and SL/IP
>Well, I've heard things that imply the Sun serial ports are silly,
>except for the "CPU port" (I suppose that's a serial port that's directly

Ports of a Systech MTI (aka alm) in a Sun are less than wonderful.
The CPU board has two on-board ports run from a zilog chip that are better.
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 90 15:01:41 GMT
From:      hp-sdd!ncr-sd!ncrcae!wingo@hplabs.hpl.hp.com  (Dave Wingo)
To:        tcp-ip@nic.ddn.mil
Subject:   tcp/ip for 386 UNIX

 I am looking for a 386 UNIX tcp/ip package and ethernet board combination.
Can anyone suggest a stable package for a 5.3 UNIX???? Any help on this matter
will be greatly appreciated.....

Regards
wingo@Columbia.NCR.Com
-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      Mon, 22 Jan 90 23:28:40 PST
From:      estrin@usc.edu (Deborah Estrin)
To:        craig@NNSC.NSF.NET
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
Sounds good...but what do you do when you replace one of those links
with an SMDS connection that has usage sensitive billing?
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 90 15:30:25 GMT
From:      buit13!kwe@CS.BU.EDU  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: why IP should pass UID information
In article <29288@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu
 (Dan Bernstein) writes:
>... If the Internet were economically sound, each
>packet would carry enough user information to let costs be sensibly
>distributed. Instead, it's impossible to trace expenses further than
>to a single machine. This problem has other effects: it is the only
>security hole above TCP. Doesn't anybody care about mail forgery?
>...
>The encoding of the user information is irrelevant; two-byte integers
>just happen to be a compact, portable standard. What matters is that the
>information be passed along.
>...
>Who pays for the janitor? Who do you charge for use of the building
>water fountain? Obviously the system is shared, and some costs can't be
>directly allocated to a single user. In these cases the UID is 0. The
>same applies to your Macintosh or PC: who pays for your house?
>
	"IP" the internet protocol, is a protocol for hosts and
routers to get datagrams hither and yon.  User IDs have nothing to do
with that.

	Now, if you want to talk about mail security, see the excellent
recent RFCs on a standard for authenticated, secure mail.  (These do
not require UIDs in IP.) RFC 1114, et al.

	If you want to talk about cost accounting (which does involve
IP), then let's talk about how internetworks are going to model such
cost recovery.  Dave Clark has made some tentative steps in this
direction with an excellent RFC on the subject (#1102).  Again, no
need for UIDs in IP.

	What *is* needed is some way to translate accounting on Unix
machines (UIDs) to accounting for internets (some "type-of-service"
code and authorization "ticket").  But don't say that UIDs therefore
need to go in IP.  Let's keep the Internet maintainable using the
widely accepted and understood concept of "layering".  :-)

	Have a look at these RFCs and see how others have attacked the
problems that you raise.

	Kent England, Boston University
-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 90 16:56:28 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   billing for use


    It seems to me the easiest way to bill for IP services is by link.
I.e. company A rents a link of a certain speed from MIDCENTRAL Net.
The monthly rental covers link costs plus the cost of the traffic
that link can put on the network.  MIDCENTRAL Net, can, in turn,
(if desired) pay the NSFNET backbone for its link.
    
    The advantage of this system is that cost recovery is simple,
the bills are predictable (and most people like predictable bills),
and related to usage (people will buy the link speed they need, and
pay for what they use).

    Accounting for packets is a pain.  They can get lost, duplicated,
etc.  So far reports from people who've talked with accountants suggest
the accountants will want refunds for lost packets, and probably don't even
understand the notion of being billed twice (legally) for the same data.

Craig

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 90 18:03:40 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re:  tcp port numbers

From: Casey Leedom

>  Don't forget to charge the broadcast storm packets too.  And the CPU
>time stolen from all the machines that were uselessly interrupted.

Systems that participate in broadcast storms are broken.  They should be
billed for their own noise.  Just bill broadcasts at <packet rate> times
<number of nodes>.  That would discourage needless broadcasts, if it weren't
for the fact that few nets have a packet charge at all.  Personally, I find
that the PC-NFS nuisance packets are much less of a problem than other
noise on the net.

Doug Nelson
Michigan State University

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 90 18:21:48 GMT
From:      nsc!pyramid!infmx!kwang@hplabs.hpl.hp.com  (Kwang Sung)
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for a bridge between "pure" OSI product and RFC 1085 based product
Hi... there,

	Does anyone have a bridge between "pure" OSI product and RFC 1085
based product (on top of TCP/IP) ???  Thanx.


					Kwang Sung
					Informix Software, Inc.
					4100 Bohannon Dr.
					Menlo Park, CA 94025
					415 / 926 - 6758 (O)
					UUCP: ...!uunet!infmx!kwang
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      22 Jan 90 20:02:24 GMT
From:      zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!jpl-devvax!mike@tut.cis.ohio-state.edu  (Mike Tankenson)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP experience on Goulds/Ethernet & MPX
We're interested in hearing from anyone supporting a TCP/IP package on
Gould machines running the MPX operating system over Ethernet.  Our local
sales rep tells us that there are several, so if you're out there (or if
you know of any second-hand), please drop me a note so I can contact them.

A problem is arising with one source saying that Gould/Ethernet packages
are only available for their UNIX OS, and not MPX.  Another source is
saying that an Ethernet package *is* available for MPX.

I doubt that anybody else is interested in this, so make the responses
email.  Thanks much in advance.

-- 
Mike Tankenson                      Telos/Jet Propulsion Laboratory/NASA
4800 Oak Grove Drive, Pasadena, CA.  91109           Mail Stop: 301-260a
Phone: (818) 354-1439
ARPA: mike@jpl-devvax.JPL.NASA.GOV  UUCP: seismo!cit-vax!jpl-devvax!mike
-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 00:27:25 GMT
From:      jim@lsuc.on.ca (Jim Mercer)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   networking over X.25


Please excuse the crossposting.  I wanted to gather interest from the
appropriate groups.
Followups to comp.protocols.misc

I am not a networking guru and don't follow these groups (although I will
now).

At our site, we have a 3B2/500 running SysV 3.2.
We have remote users who access us over X.25 using terminals plugged into
a PAD at 9600 baud.  The X.25 parameters currently forward packets on CR.

I would like these users to be able to run full screen (ie. curses)
applications, but the X.25 has too much buffering and won't allow (easily)
single keys to get through.

I was wondering, if I laid a 386 unix box down at the remote location and
connected it to the 3B2 via 9600 baud X.25, could the users run full screen,
"single key action" programs using rlogin over RFS, NFS, TCP/IP or something
like that?  The users would still be running their applications on the
3B2, all that would be sent back and forth would be screen I/O.

I spoke to someone about this and he said something about removing the PAD's
and plugging the syncronous modem into the unix machines and letting the
network software packetize and depacketize.  I'm not sure this is possible
as the X.25 connections are over DATAPAC (Canada's public X.25 network,
similar to TYMNET or TELENET in the US).

It would seem to me, that lumping all the user's I/O would optimize the
use of the X.25 connection, even if we had to send plenty of smaller packets
from the remote side (for "single key action").

The purpose of this exercise is not to save packets (ie $$), but to give the
remote users an environment similar to the local users.  If it costs more,
it'll be worth it, although, with the line-oriented applications they use now,
I can see a possible savings.


thanx in advance.

-- 
[ Jim Mercer  jim@lsuc.On.Ca || ...!uunet!attcan!lsuc!jim    +1 416 947-5258 ]
[ System Facilitator - Law Society of Upper Canada, Toronto, Ontario, CANADA ]
[     The opinions expressed here may or may not be those of my employer     ]

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jan 90 08:59:10 PST
From:      Jim Forster <forster@cisco.com>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
Billing by link is certainly easy to implement and easy to understand, but it's
not as fair as other schemes.  If I were building a network that had to
recover its costs I'd want to use a different scheme.

We've given the problem some thought and we think that the combination of
packet accounting in the routers by source-destination address pairs and
a data base application program to process the raw data can provide a
mechanism which will support a couple different pricing models.  In
particular, it can support a model that charges for packets by zone of
origin and destination (like the phone bills), and which only charges for
packets that reach a destination.  We've done the packet accounting in the
routers but haven't done the data base application program.


Jim Forster
cisco Systems
-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jan 90 09:54:00 -0500
From:      tmallory@BBN.COM
To:        Craig Partridge <craig@nnsc.nsf.net>
Cc:        tcp-ip@nic.ddn.mil, tmallory@BBN.COM
Subject:   Re: billing for use

[my context is: Should packets be independently billable?]
...
>    It seems to me the easiest way to bill for IP services is by link.
...
>    Accounting for packets is a pain.  They can get lost, duplicated,
...

The most obvious unit for billing is the connection.  The user is billed
locally for costs allocated to his connection.  The user's system is billed
for link costs by those systems providing transit services.  Individual
packets need not contain extra information.  If per-packet costs for link
usage must be assessed, the source and destination addresses in the packets
are probably sufficient to allocate the costs to the appropriate billing
authority(ies), which might be large organizations such as NYSERnet, or
individual hosts, or something in between.

The local connection management system could include accounting for bits,
bytes, packets, minutes, hops-to-destination, etc. from which the user could
be billed.

If per-packet billing is strictly required, then just byte[sic] the bullet and
build a global x.25 network out of the routers.  (Well, maybe connection IP
would suffice.)

Tracy
-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      Tue 23 Jan 90 09:52:02-PST
From:      David L. Kashtan <KASHTAN@IU.AI.SRI.COM>
To:        mailrus!b-tech!zeeff@tut.cis.ohio-state.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: PEP and SL/IP
We (here at TGV Inc) are running SLIP with Van's header compression over
PEP.  It is an absolute win -- it turned an IP link that was really only
good for bulk data transfer into one that handles interactive traffic
VERY nicely.

David
-------
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jan 90 09:24:07 CST
From:      Guy Almes <almes@rice.edu>
To:        buit13!kwe@cs.bu.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Interior Gateway Protocol Summary
Kent,
  Filters and firewalls will be a very important part of any new Router
Requirements RFC.
  It is less clear to me how they would fit into an IGP protocol standard.
During the last three years I've used cisco routers, I've seen lots of
improvements and (the main point) changes in their filter/firewall/
administrative distance/access list mechanisms, and yet IGRP (in the
narrow protocol sense) has not changed.  Thus, all those changes were
very important to configuring individual routers, and they are very
important to the global routing scheme for my autonomous system, but
I'm not sure I'd say they are part of the IGRP routing protocol.
  Thus, the firewall/... mechanisms are orthogonal to choice of routing
protocol, at least within the set of distance-vector protocols.  They
can be used in the same way for IGRP, RIP, Hello, or EGP, and that'sd
important to their utility.
  This is *not* to say that OSPF erred in including *authentication*
in then OSPF protocol.
  On the other hand, a firewall/... set of mechanisms cannot totally
be specified in the definition of a single IGP.  One reason is that some
of these mechanisms, notably cisco's administrative-distance mechanism,
relate necessarily to the use of multiple protocols within a single
router.
	-- Guy
-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 05:32:33 GMT
From:      sdcc6!ee299at@ucsd.edu  (Subhasis Chaudhuri)
To:        tcp-ip@nic.ddn.mil
Subject:   TYMNET/MCI MAIL
Hi
Is there access to TYMNET AND MCI MAIL through
Internet/Bitnet/UUnet

My apologies if this is not the right group
to post this query.
Email replies please

Thanks
PM
-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jan 90 10:45:39 EST
From:      Brad Clements <bkc@omnigate.clarkson.edu>
To:        Per Andersson <mcsun!sunic!draken!perand@uunet.uu.net>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Novell Networks
We have a Novell Print queue to Unix LPR gateway that shuttles print files
in both directions and provides userid access checking.

Its quite robust and can send and receive to/from printqueues/hosts simultaneously
(I think 32 TCP connections is the current limit).

We need to add multiple Novell Server support (currently only attaches to the
first server that answers) but it works well.

On the novell side its a standard Print Server, and we also have an LPQ, and LPRM
program (that will also allow a non-tcp PC to LPQ a remote unix queue via
the printer gateway).

We have also been working on a version of SOS (stans own server) which is a 
PC based NFS server. 

Both programs are based on NCSA libraries with some extra work (such
as multiple UDP ports and IP fragmentation (outgoing) we can see 250+Kb/sec
from PC to host via NFS).

However we've placed the PC NFS server on hold, as Netware 386 will
(someday) provide NFS service.


| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clutx.bitnet 
| Network Engineer       Clarkson University              (315)268-2292
-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 09:08:08 GMT
From:      mcsun!ukc!stl!stc!datlog!gjack@uunet.uu.net  ( Graham Jack )
To:        tcp-ip@nic.ddn.mil
Subject:   IPS Nomenclature
I am planning to write some stuff about the Internet protocols and I'm
looking for a guide to the accepted terms used in this area. Is there
an RFC or other document that defines this? If I were writing about ISO
protocols then there is an official standard terminology, for IPS the best
I have come up with so far is the rather short "glossary" sections in
the Host Requirements RFCs.

Thanks in advance for any ideas,

	    Graham Jack, Data Logic.
	    <gjack@datlog.co.uk>
-- 
Regards,
	    Graham Jack, Data Logic.
	    <gjack@datlog.co.uk>
-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 10:18:27 GMT
From:      bywater!acheron!archet!larouch!yozzo@uunet.uu.net  (Ralph Yozzo)
To:        tcp-ip@nic.ddn.mil
Subject:   Calling the NFSPROC_ 's in the Sun Network File System Protocol Specification

I am reading the Sun Network File System Protocol Specification 
Version 2 and I see a lot of calls such as NFSPROC_NULL()
NFSPROC_GETATTR()
NFSPROC_SETATTR()
...
NFSPROC_READ()
...

and it is not clear how I generate these calls.

Is there some header file or library that resolves these calls?

Could someone shed some light on this subject.


I'd appreciate any information or a pointer to a good place to look.

------------------------------------------------------------------------------
| Ralph E. Yozzo                     |                                       |
| Arpanet: yozzo@ibm.com             |                                       |
| Bitnet: yozzo@yktvmx.bitnet        \---------------------------------------|
| Home: ..!uunet!bywater!acheron!larouch!yozzo  | Phone: (914) 945-3634 work |
|                                               | Phone: (914) 564-4731 home |
------------------------------------------------------------------------------
-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jan 90 18:36 PST
From:      Denis DeLaRoca (213) 825-4580        <CSP1DWD@OAC.UCLA.EDU>
To:        David L. Kashtan <KASHTAN@IU.AI.SRI.COM>
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Re: PEP and SL/IP
What's sort of transfer rates are you observing with FTP both
with and without interactive traffic being present.

-- Denis

-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 19:07:06 PST (Tue)
From:      dab@asylum.sf.ca.us (Dave Bridgham)
To:        forster@cisco.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   billing for use
If you start considering packet count fees, you should also consider
how this will change how people use the network and whether these
changes are desirable.  In the past, others have pointed out that
anonymous ftp access is likely to disappear from many places.  I can
also see people disabling ICMP echo responses or the various
destination unreachable messages.  Much time will be spent by system
administrators worry about who NNTPs with whom and who starts it (if
packet size is also taken into account).  What about finger servers?
It's a small thing perhaps, but it does make the net a nicer place.
People would be even less willing than they are now to allow their
machines to be used as backup domain name servers for other domains.

These are only the effects that come to mind immediately; I'm sure if
per packet fees were actually instituted, the effects would be much
more widespread and unexpected ("nothing is ever simple in
networking").

					David Bridgham
					Epilogue Technology
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jan 90 11:35:35 +0000
From:      Zheng Wang (Ext: 3701) <Z.Wang@Cs.Ucl.AC.UK>
To:        Craig Partridge <craig@nnsc.nsf.net>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use

 >    It seems to me the easiest way to bill for IP services is by link.
 >I.e. company A rents a link of a certain speed from MIDCENTRAL Net.
 >The monthly rental covers link costs plus the cost of the traffic
 >that link can put on the network.  MIDCENTRAL Net, can, in turn,
 >(if desired) pay the NSFNET backbone for its link.

One possible problem is that during "rush hours" the actual
bandwidth could be effectively reduced due to congestion
control or "fair" queueing. Although there is little loss
of packets, you just can not send packets out. (ok, accountants
may not know that :-)

Another possible disadvantage is that it does not take into
account the QoS. Use of the network in the night should be
cheaper and higher priority traffic (or even with bandwidth
reservation) should pay more...

 Zheng
-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 13:08:09 GMT
From:      bbn.com!mckenzie@bbn.com  (Alex McKenzie)
To:        tcp-ip@nic.ddn.mil
Subject:   Robert Morris found guilty
Robert Morris was found guilty of computer tampering yesterday at 9:30pm
local time by a Syracuse, NY jury, in connection with the Internet worm
incident, according to today's Boston Globe.  He faces a maximum
possible penalty of 5 years in jail and/or a $250,000 fine.  No date has
been set for sentencing.
 
-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 13:36:09 GMT
From:      usenet.ins.cwru.edu!cwjcc!ncoast!sgtech!adnan@tut.cis.ohio-state.edu  (Adnan Yaqub)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Packet drivers
In article <826@ucs.UAlberta.CA> DKRUGER@ucs.UAlberta.CA (Dwight Kruger) writes:

   I wish to run NCSA telnet 2.2TN on my IBM PC's and PS/2's using packet
   drivers.  Where can I find freeware or public domain packet drivers
   for Western Digital WD8003 and Ungermann-Bass PC/NIC cards?

WD has a thing they call the "super disk" which comes with their
baords.  It contains a Streams (Sys V) based packet driver, and they
seem to be quite liberal with the source code for it.
--
Adnan Yaqub
Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860
...cwjcc!ncoast!sgtech!adnan ...uunet!abvax!sgtech!adnan
-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Tue, 23 Jan 90 12:06:24 SST
From:      Luther Chan <CCECHAN%NUSVM.BITNET@CUNYVM.CUNY.EDU>
To:        Vivian Neou <TCP-IP@SRI-NIC.ARPA>
Subject:   unsubscribe me
please unsubscribe me from this list from today until 1 Feb 1990. thank you
-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 14:30:05 GMT
From:      mailrus!b-tech!zeeff@tut.cis.ohio-state.edu  (Jon Zeeff)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PEP and SL/IP
Has anyone tried PEP and SL/IP with VanJacobson's header compression?
Supposedly it will allow the acks to fit in the reverse channel making
unidirectional transfers work well.

-- 
Jon Zeeff    	zeeff@b-tech.ann-arbor.mi.us  or b-tech!zeeff
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 14:54:00 GMT
From:      tmallory@BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: billing for use


[my context is: Should packets be independently billable?]
...
>    It seems to me the easiest way to bill for IP services is by link.
 ...
>    Accounting for packets is a pain.  They can get lost, duplicated,
...

The most obvious unit for billing is the connection.  The user is billed
locally for costs allocated to his connection.  The user's system is billed
for link costs by those systems providing transit services.  Individual
packets need not contain extra information.  If per-packet costs for link
usage must be assessed, the source and destination addresses in the packets
are probably sufficient to allocate the costs to the appropriate billing
authority(ies), which might be large organizations such as NYSERnet, or
individual hosts, or something in between.

The local connection management system could include accounting for bits,
bytes, packets, minutes, hops-to-destination, etc. from which the user could
be billed.

If per-packet billing is strictly required, then just byte[sic] the bullet and
build a global x.25 network out of the routers.  (Well, maybe connection IP
would suffice.)

Tracy

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 15:45:39 GMT
From:      bkc@OMNIGATE.CLARKSON.EDU (Brad Clements)
To:        comp.protocols.tcp-ip
Subject:   Re:  Novell Networks

We have a Novell Print queue to Unix LPR gateway that shuttles print files
in both directions and provides userid access checking.

Its quite robust and can send and receive to/from printqueues/hosts simultaneously
(I think 32 TCP connections is the current limit).

We need to add multiple Novell Server support (currently only attaches to the
first server that answers) but it works well.

On the novell side its a standard Print Server, and we also have an LPQ, and LPRM
program (that will also allow a non-tcp PC to LPQ a remote unix queue via
the printer gateway).

We have also been working on a version of SOS (stans own server) which is a 
PC based NFS server. 

Both programs are based on NCSA libraries with some extra work (such
as multiple UDP ports and IP fragmentation (outgoing) we can see 250+Kb/sec
from PC to host via NFS).

However we've placed the PC NFS server on hold, as Netware 386 will
(someday) provide NFS service.


| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clutx.bitnet 
| Network Engineer       Clarkson University              (315)268-2292

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 16:59:10 GMT
From:      forster@CISCO.COM (Jim Forster)
To:        comp.protocols.tcp-ip
Subject:   Re: billing for use

Billing by link is certainly easy to implement and easy to understand, but it's
not as fair as other schemes.  If I were building a network that had to
recover its costs I'd want to use a different scheme.

We've given the problem some thought and we think that the combination of
packet accounting in the routers by source-destination address pairs and
a data base application program to process the raw data can provide a
mechanism which will support a couple different pricing models.  In
particular, it can support a model that charges for packets by zone of
origin and destination (like the phone bills), and which only charges for
packets that reach a destination.  We've done the packet accounting in the
routers but haven't done the data base application program.


Jim Forster
cisco Systems

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 17:29:57 GMT
From:      auspex!guy@uunet.uu.net  (Guy Harris)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: why IP should pass UID information
>This problem has other effects: it is the only security hole above TCP.
>Doesn't anybody care about mail forgery?

Plenty of people do; they just don't necessarily think shoving user
identification into, say, IP datagrams, or TCP connection requests, is
the right way to solve it. 

>> UID's and GID's are inherently OS-specific
>
>So? The encoding of the user information is irrelevant; two-byte integers
>just happen to be a compact, portable standard. What matters is that the
>information be passed along.

In what form?  The form needs to be one that can represent the user
information on all systems, in such a way that system A, no matter what
OS (if any!) it's running, can understand what system B sent it, no
matter what OS it's running.  If the *only* use for this is accounting,
that may not be a problem, as system A can treat the user ID as opaque
data and send it back to system B in that form, but if you plan to use
it for, say, authentication, system A had better know what to do with
it....

(Note: 2-byte integers won't be portable to future UNIX System V
releases, nor to, I think, future BSD releases, as they will support
32-bit user IDs.  They may well not be portable to other OSes, either. 
2-byte integers don't cut it; try something else.)

>> Application protocols should be independent of the mechanism
>> used to establish the link; if they need to know user identities, then
>> they'll need to pass it themselves when used over simple links, so it would
>> be redundant to have the multiplexing protocol pass it as well.
>
>Let me repeat that with a few words changed.
>
>  Application protocols should be independent of the mechanism used to
>  establish the link; if they need to know the connecting host name,
>  then they'll need to pass it themselves when used over simple links,
>  so it would be redundant to have lower layers pass it as well.
>
>Hence packets shouldn't include source host information, and BSD
>shouldn't have a getpeername() call? Don't be ridiculous.

The source address is there for other reasons; there's not any point in
*not* providing a call to get it.  I wouldn't advocate adding user IDs
to IP datagrams or TCP segments solely for the benefit of applications
that want to know who's on the other end of the wire.  For one thing, if
they *really* want to know who's on the other end of the wire, they're
not going to trust whoever that is to tell them the truth, so they sure
wouldn't trust credentials consisting solely of a user ID (whether it be
a 2-byte integer, a 4-byte integer, a string, etc.).
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 18:07:42 GMT
From:      amdcad!pepsi.amd.com!remaker@ucbvax.Berkeley.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   TN3270 for a PC
We have a lot of PCNFS users in our organization that need IBM access.  Is
there any program available that will work over ethernet with TCP/IP on an
NFS platform on a PC?  We want something like TN3270 for an IBM PC (and
an Apple Macintosh for that matter!

Any help would be appreciated, I will send summaries on request (or post if
demand is sufficient.

(pref. PD over anonymous ftp, but vendor pointers are very welcome)
Phillip A. Remaker     remaker@amdcad.amd.com | "Making fun of Tiffany, Rick
Advanced Micro Devices, CAD Networking Support|  Astley and Debbie Gibson is 
901 Thompson Place, P.O. Box 3453, MS 167     |  what rock and roll is all 
Sunnyvale, CA 94088-3000   (408) 749-2552     |  about"  -Mojo Nixon
-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 19:52:38 GMT
From:      hp-sdd!ncr-sd!ncrlnk!ncrcce!mercer@hplabs.hpl.hp.com  (Dan Mercer)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP-IP to DECNet Gateway?
Does anyone know of a TCP-IP to DECNet Gateway.  We need to be able to 
send IBM 3270 Data Streams across it.


Please respond email as we have been having severe problems with our
news feed.

Thanks in advance,
-- 

Dan Mercer
Reply-To: mercer@ncrcce.StPaul.NCR.COM (Dan Mercer)
-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 20:25:19 GMT
From:      zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!news@tut.cis.ohio-state.edu  (Roy Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Routing on bisected networks

	What would happen if you had a network with two gateways to the
Internet and that network got bisected such that both gateways were still
connected to the Internet, but not to each other directly.  For example:


		Internet                             Internet
                   |                                    |
                   | 1.0.0.1                            | 2.0.0.1
                   |                                    |
                   |                                    |
                   | 1.0.0.2                            |
                   |                                    | 2.0.0.2
                 +---+                                +---+
                 | G1|                                | G2|
    host-a       +---+                                +---+        host-b
      |            |                                    |            |
      | 3.0.0.3    | 3.0.0.1                            | 3.0.0.2    | 3.0.0.4
      |            |              +-------------+       |            |
   ---+------------+--------------| etherbridge |-------+------------+------
                ethernet          +-------------+       ethernet


	Now, imagine that the etherbridge goes down.  Is there any way for
host-a to talk to host-b by some route into the Internet and out again?  What
happens to some machine on the Internet that is talking to host-b through G1.

	In another scenario, imagine the etherbridge is down and some host-c,
out in the Internet somewhere, wants to talk to both host-a and host-b.  Is
there any way for it to discover different routes to the two host, using
gateway G1 to talk to host-a and gateway G2 to talk to host-b, even though
host-a and host-b are on the same IP net?
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,philabs,cmcl2,rutgers,hombre}!phri!roy
"My karma ran over my dogma"
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 20:47:42 GMT
From:      pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!srcsip!nic.MR.NET!thor.acc.stolaf.edu!stolaf!towfiq@tut.cis.ohio-state.edu  (Mark Towfigh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip for 386 UNIX
In article <5645@ncrcae.Columbia.NCR.COM>
wingo@ncrcae.Columbia.NCR.COM (Dave Wingo) writes:

    I am looking for a 386 UNIX tcp/ip package and ethernet board
    combination. Can anyone suggest a stable package for a 5.3
    UNIX???? Any help on this matter will be greatly appreciated.....

Racal InterLan has just released the latest version of its NP622
product, a TCP/IP package for 386 Unix.  It contains the full suite of
TCP applications (telnet, ftp, mail, r-commands, etc.) as well as a
development library.  You can contact our company at 1-800-LAN-TALK.

Hope this helps,
Mark
--
Mark Towfigh, Racal Interlan, Inc.		   towfiq@interlan.Interlan.COM

  "The Earth is but One Country, and Mankind its Citizens" -- Baha'u'llah
-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 21:28:23 GMT
From:      tiamat!jim@uunet.uu.net  (Jim O'Connor)
To:        tcp-ip@nic.ddn.mil
Subject:   uucp over TCP/IP
I know I've seen discussion about this before, but I looked at all the
articles I still have in the posted groups and I couldn't find any info.

The basic question: can I make a "uucp" connectin over TCP/IP?

The reason for the question:  I normally use UUCP to transfer mail and news to
bahamut (the luggable) so that I can receive these while I'm on the road calling
in with a modem.  Also, on the few rare occasions when I have bahamut at the
office, if there are uucp jobs spooled up for it, I have to connect up a modem
and "call in".  Since I will be able to connect to our LAN now, I'd just as soon
make the uucp connection over the LAN and not have to unpack the modem (no, I
don't have an internal modem, but I do have a pocket-sized one, and with the LAN
card in, I'm out of slots).

The luggable (bahamut) is running SCO Xenix/386 2.3.2 and uses HDB UUCP.

If I get a solution through e-mail, I'll post it.
Thanks a bunch.
------------- 
James B. O'Connor			jim@tiamat.fsc.com
Ahlstrom Filtration, Inc.		615/821-4022 x. 651

*** Altos users unite! mail to "info-altos-request@tiamat.fsc.com" ***
-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      23 Jan 90 23:22:13 GMT
From:      elroy.jpl.nasa.gov!mahendo!wlbr!awds26!mh@ames.arc.nasa.gov  (Mike Hoegeman)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Calling the NFSPROC_ 's in the Sun Network File System Protocol Specification
In article <1990Jan23.101827.7788@larouch.uucp> yozzo@larouch.UUCP (Ralph Yozzo) writes:
>
>I am reading the Sun Network File System Protocol Specification 
>Version 2 and I see a lot of calls such as NFSPROC_NULL()
>NFSPROC_GETATTR()
>NFSPROC_SETATTR()
>...
>NFSPROC_READ()
>...
>
>and it is not clear how I generate these calls.
>

I'm not too sure why you would want to make such calls 
but here's how to find out how to do it

- first dig up the documentation on RPCL data definition language and
rpcgen program in the "networking w/ the sun workstation" section and
read thru that. this will tel you how to read nfs_prot.x

- then check out nfs_prot.x in /usr/include/rpcsvc

- then do a "man" for 

    clntudp_create 
    clnt_call 
    clnt_destroy
    clnt_freeres (?? not sure this is the exact name )

at this point it should be pretty clear what you have to do nfs remote
procedure calls. 

-mike
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Jan 90 08:00:33 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   more on accounting for packets

    One other point about charging on a per packet basis.  I don't think
it scales well.

    Consider, for example, a gigabit link.  Using our current day 1000 bit
average packet size, that means I have to store 1 million accounting
records per second.  Even if they are one byte each, an Eagle disk will
fill in ten minutes.  Collating all the data from all the recording
devices to generate a weekly bill would require terabytes of disk space...

    If one tries to avoid keeping records, then one needs some sort of
reliable counting device -- which someone has to certify and inspect
so that everyone is satisfied the carriers aren't fiddling with the meters.
Even so, I doubt we'll avoid gigabytes of data per week.

Craig
-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Jan 90 09:33:53 PST
From:      Dave Crocker <dcrocker@nsl.dec.com>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Novell Networks
A few technical items tend to be missed in discussions about the portable
version of Netware:

It is a user-level process.  Moving to the code into a kernel should
be highly non-trivial.

For file access, it is server only.  Applications on the machine which
want to use Netware's inter-process communication protocol may do so, so
that such systems/services may be clients, but the basic file service is
server only.
-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 90 01:50:45 GMT
From:      cs.utexas.edu!samsung!munnari.oz.au!cluster!metro!toshiba!rickg@tut.cis.ohio-state.edu  (Rick Gunderson)
To:        tcp-ip@nic.ddn.mil
Subject:   Request for TCP/IP s/w and Multibus II Ethernet h/w for RMX II
We are looking at connecting our Multibus II target systems to our SunOS
network.  This means that we need some Ethernet cards for Multibus II
platforms and some TCP/IP software for RMX II (Intel's Real-time
Multitasking eXecutive).

Can anyone out there point me in the proper direction(s)?

Thanks in advance.

Rick

============================================================================
= Rick Gunderson                              ACSnet: rickg@toshiba.tic.oz =
= Toshiba International Corp.                 Phone:  61-2-428-2077        =
= Sydney,  Australia                          Fax:    61-2-427-7405        =
============================================================================
-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 90 01:53:00 GMT
From:      tihor@nyu-acf4.arpa  (Stephen Tihor)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: why IP should pass UID information
FYI, I have been looking ingto various systems accounting systems for a
separate project.  It looks like (with reasonable encoding) a 256 bit per
host opaque object or a 512 bit global object are probably sufficient.
One could probably do better if it was limited to TCP/IP and could ignore ISO
interoperability and intercharability. or could rely on the gateway to handle
the crossbilling databases.
-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 90 02:21:40 GMT
From:      CCECHAN@NUSVM.BITNET (Luther Chan)
To:        comp.protocols.tcp-ip
Subject:   unsubscribe me

please unsubscribe me from this list from today until 1 Feb 1990. thank you

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Jan 90 10:32:53 PST
From:      Dave Crocker <dcrocker@nsl.dec.com>
To:        hp-sdd!ncr-sd!ncrlnk!ncrcce!mercer@hplabs.hpl.hp.com (Dan Mercer)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP-IP to DECNet Gateway?
Digital sells a product, called the IP Portal, which encapsulates
IP and sends it over DECNet.  Should be available through your
local sales office.

Was this the functionality you were looking for?

Dave
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 90 02:36:00 GMT
From:      CSP1DWD@OAC.UCLA.EDU (Denis DeLaRoca  825-4580, 213)
To:        comp.protocols.tcp-ip
Subject:   Re: Re: PEP and SL/IP

What's sort of transfer rates are you observing with FTP both
with and without interactive traffic being present.

-- Denis

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 90 03:55:53 GMT
From:      uhccux!munnari.oz.au!cluster!softway!gary@ames.arc.nasa.gov  (Gary Corby)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Novell Networks
krupczak@secola.Columbia.NCR.COM (Bobby Krupczak) writes:

>Novell is working on "Portable" Netware.  This product is written to run
>on Unix as well as VMS machines.  NCR is one company that will offer
>"Portable" Netware on its Unix boxes.

As I understand it, Novell is expecting everybody but themselves
to be working on "Portable" Netware.  Novell has merely defined 
the various hooks into their system.  Each vendor is supposed to 
supply the code for their own particular hardware.  Assuming all 
the hardware vendors are obliging in this regard, Novell will suddenly 
find themselves with a portable netware and make a large profit.

>I dont know of any commercial based products that
>are available yet for "Portable" NetWare, they arent too far down the line
>Im sure -- or you could write one yourself.

Yes.  Precisely.

"A Ginos home delivery pizza which never arrived," on the Sid and Nancy scale.


Disclaimer:  Needless to say, I take no responsibility for anything I utter.
-- 
Gary Corby  (Friend of Elvenkind)			Softway Pty Ltd
						ACSnet: gary@softway.oz
					UUCP: ...!uunet!softway.oz!gary
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Jan 90 15:52 MST
From:      Arnone@SYSTEM-M.PHX.BULL.COM
To:        tcp-ip@NIC.DDN.MIL
Subject:   Determining Features Supported by Various FTP Implementations
Organization:  Bull HN, Phoenix Arizona system-m.phx.bull.com

Help.  I am currently rewriting portions of the FTP application used on
Bull HN (formerly Honeywell Bull, Honeywell, GE) mainframes.  I would
like to test various FTP features/options with FTP applications written
for other hardware platforms.  How does one *easily* compile a list of
other FTP implementations which support feature "X"?  (In this
particular case Record Structure transfers for ASCII and Image modes.)

Jim Arnone Arnone Software Consulting, Inc
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Jan 90 20:27:11 PST
From:      Dave Crocker <dcrocker@nsl.dec.com>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
No only is Alex McKenzie right about the role of Policy (capital P)
in establishing price, but the policies and -- worse for the
development engineers -- the underlying mechanisms tend not to be
stable.

Business dynamics change.  Even if they didn't, management (supposedly)
learns more about existing business dynamics and then can (supposedly)
make more sophisticated assessment of the correct/desired policies.

The end effect is that requirements for accounting (recording of
information) and billing (use of some of the data to establish and
obtain price and revenue) change constantly.  You should expect all
of this to be LESS stable than "accepted" algorithms for implementing
well-behaved TCP engines.

This ain't from no text book, either.

Dave
-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 90 13:00:33 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   more on accounting for packets


    One other point about charging on a per packet basis.  I don't think
it scales well.

    Consider, for example, a gigabit link.  Using our current day 1000 bit
average packet size, that means I have to store 1 million accounting
records per second.  Even if they are one byte each, an Eagle disk will
fill in ten minutes.  Collating all the data from all the recording
devices to generate a weekly bill would require terabytes of disk space...

    If one tries to avoid keeping records, then one needs some sort of
reliable counting device -- which someone has to certify and inspect
so that everyone is satisfied the carriers aren't fiddling with the meters.
Even so, I doubt we'll avoid gigabytes of data per week.

Craig

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 90 14:18:30 GMT
From:      pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!uupsi!nyser!ldg@tut.cis.ohio-state.edu  (Leo Geoffrion)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
A per packet chargebackmechanism could be counter productive to the
large numbers of smaller instututions.

The "bean conters" who build budgets get very very nervous about 
unpredictable budget lines.  At the present time, we pay a fixed annual
fee for access to the Internet.  If this were changed to a pay per use
chargeback, I'd have a far harder time convincing accountants that 
the College should continue the service because it evokes fears that
we could be hit with large bills.  While I suspect that a pay for 
service billing would ultimately benefit small schools (we don't really
use the net as intensively as some large R & D institutions might), 
it could scare many of them off the net.

The NationalNet initiative is driving for universal connectivity.  
Personally, I think the present flat-rate arrangement is the easiest
to sell to institutions.  Broad discussion of per use systems makes 
me nervous...  I hope that the parties involved in network management
and national planning take a careful look at the long term political
and academic impacts before moving from what might be technically feasible
to what is best for the development of national networking.

Leo Geoffrion
Skidmore College
Saratoga Springs, NY
LDG@AMY.SKIDMORE.EDU
(LDG@NISC.NYSER.NET -- for Usenet News only )
-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 90 16:03:16 GMT
From:      bbn.com!mckenzie@bbn.com  (Alex McKenzie)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use

"Billing" is more than collecting data and sending out bills.  "billing"
is a concrete expression of a policy.  Each different approach to
billing will cause users to respond differently.  Do you want to hook
users when they are young? Offer an "educational discount".  Do you want
to encourage use?  Offer a flat fee (or a set of wide steps) for
service, or volume discounts.  Do you want to discourage "waste"?  Offer
a fee-per-use, or a volume surcharge.  Do you want to encourage
institutions to build their own services?  Have an element of charging
be a "per attachment" charge.  Do you want to discourage private
networks?  Have a flat fee for all attachments by a customer.  And so
on.  All of the polices mentioned above are in current use by providers
of some kinds of services, as are many other policies.  Before a
network, or internet, begins figuring out the technical means for
"billing", the organization ought to figure out what POLICIES it wants
to have regarding usage, and these will drive the way billing MUST be
done.

Alex McKenzie
 
-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Wed, 24 Jan 90 15:39:59 SET
From:      Dave Stafford <ESC1814%ESOC.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: TCP/IP experience on Goulds/Ethernet & MPX

 > TCP/IP for Gould running MPX

Yes, there is such a package, some of our people here are running it.

It's called Gould COM32 DoD, and is supplied by Gould (Encore). The ethernet
board is by Interlan (i think), but all is available as a package deal.

I'm not very up on this product, but you can try phoning a guy here about it.

He is : Steve Lane
        tele (49) 6151 886 361

Dave Stafford
European Space Operations Centre
Robert Bosch Str. 5
6100 Darmstadt.
W. Germany
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 90 16:41:28 GMT
From:      dialogic!drich@uunet.uu.net  (Dan Rich)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip for 386 UNIX

I would recomment either Interactive Systems 386/ix or SCO Unix with
their associated tcp/ip packages.  We have the ISC package running on
three of our machines here at Dialogic, and with the exception of one
or two minor bugs (such as stderr not being returned from an remote
shell), I have found no real problems with it.

We also have several machines running the Racal/Interlan tcp/ip, and
to tell you the truth, I wouldn't wish them on my worst enemy.  When
they are working, they are excellent cards, but when you have a
problem they are hopeless.  I know of at least one machine where the
card won't work (AST 386/25), and their tech support closed my case
twice without finding a solution to the problem.  The last time I
talked to them, they told me that if I found a solution, I should call
them and let me know how I fixed it.

Although I like the Interlan board, they provide no tech support
unless you purchase the product directly from them.  And, personally,
I have never been happy with the tech support they do provide.

I welcome comments from anyone at Interlan, or anyone else who has
experience with their products.  Maybe my problems have just been an
isolated case, but after dealing with 8+ tcp/ip boards, and their 
DOS <-> UNIX gateway, I don't think I am the only one finding bugs...
--
Dan Rich                    | ARPA: drich%dialogic@uunet.uu.net 
UNIX Systems Administrator  | UUCP: uunet!dialogic!drich
Dialogic Corporation        | - Time is an illusion.  Lunchtime, doubly so. -
(201) 334-1268 x213         |                           Douglas Adams
-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 90 17:18:59 GMT
From:      buit13!kwe@CS.BU.EDU  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
In article <9001232201.AA22726@ucbvax.Berkeley.EDU> 
forster@CISCO.COM (Jim Forster) writes:
>
>We've given the problem some thought and we think that the combination of
>packet accounting in the routers by source-destination address pairs and
>a data base application program to process the raw data can provide a
>mechanism which will support a couple different pricing models.  In
>particular, it can support a model that charges for packets by zone of
>origin and destination (like the phone bills), and which only charges for
>packets that reach a destination.  We've done the packet accounting in the
>routers but haven't done the data base application program.
>

	This is reasonable.  [Interested readers should have a look at
Dave Clark's Policy Model in RFC1102 for a larger context view.]

	However, I would like to point out on the behalf of the
"user", that we need a fully instrumented telnet to accompany this
change in cost accounting.  This telnet should be able to detect when
cost accounting is in effect and advise the user before completing the
connection.

	When the session is finished, I will expect to see some output
that tells me what my session performance was (how many
retransmissions, average delay and throughput) and an estimate of the
cost of the session based on my service provider's algorithm.

	And don't forget some accompanying tools for the network
managers to use in response to complaints from the instrumented telnet
users. 

	--Kent England, Boston University
-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 90 19:10:54 GMT
From:      ESC1814@ESOC.BITNET (Dave Stafford)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP experience on Goulds/Ethernet & MPX


 > TCP/IP for Gould running MPX

Yes, there is such a package, some of our people here are running it.

It's called Gould COM32 DoD, and is supplied by Gould (Encore). The ethernet
board is by Interlan (i think), but all is available as a package deal.

I'm not very up on this product, but you can try phoning a guy here about it.

He is : Steve Lane
        tele (49) 6151 886 361

Dave Stafford
European Space Operations Centre
Robert Bosch Str. 5
6100 Darmstadt.
W. Germany

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 90 21:17:50 GMT
From:      umabco!lwilson@cvl.umd.edu  (Lowell G. Wilson)
To:        tcp-ip@nic.ddn.mil
Subject:   Mac FTP

I could really use some suggestions here! Our department has always been
PC-only but we have recently bought a couple of Macs and everyone really
likes them.  We have had one of the Macs on our network for a while now
and have been using the NCSA telnet package to log into our mainframe,
etc.  Now we have two macs on the network and we would really like to be
able to send files between the two machines.  Unfortunately, it looks as
though the NCSA mac implementation does not contain FTP client software. 
I've known that for a while but it hasn't been a problem since NCSA
Telnet acts as an FTP host.  So, whenever I've wanted to transfer files
between our mac and the mainframe, I just telneted from the Mac to the
mainframe and then FTPed from the mainframe to the mac and everything
worked out okay.  I know that I could get files from the one mac to the
mainframe and then from the mainframe to the other mac, but I'd really
like a more direct approach if there is one available at the same price
as the NCSA product! Does anyone know of such a creature? If so, I could
use the information... 

Thanks...
-- 
Lowell Wilson : Sinecure III        University of Maryland at Baltimore    
                                    Information Resources Mgt Division     
                                    UUCP: ...cvl!umabco!lwilson            
                                    Internet: umabco!lwilson@cvl.umd.edu
-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 90 21:55:27 GMT
From:      snorkelwacker!usc!orion.oac.uci.edu!uci.edu!DHWalker@bloom-beacon.mit.edu  (David Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
In article <9001230751.AA24847@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET 
(Craig Partridge) writes:
>     It seems to me the easiest way to bill for IP services is by link.

This is how CERFnet prices its services.  As one of the people to devise 
CERFnetUs scheme, I whole-heartedly agree with Craig.

As has been stated, this is really a policy decision, rather than one of 
technology or even "fairness."  The pricing policy for a network 
connection should be based on two factors, 1) the cost born by the network 
provider to supply that service and 2) the value of the service as 
perceived by the person/organization using it.

The cost of providing network service is very little correlated to the 
number of packets transmitted.  Also, as has been mentioned a number of 
times in this discussion, the perceived value of the network is not in the 
packets.

The cost of providing network service is a combination of a relatively 
fixed overhead and the cost of acquiring sufficient bandwidth to provide 
an acceptable level of service to everyone in the network.  Charging 
different prices for different link speeds allows people to choose their 
"acceptable level of service," given their available budget.  It also 
gives network service providers much better information on how to 
configure the internal structure of their networks to ensure those levels 
of service.  Finally, I claim that the link speed is a reasonable 
approximation for perceived value.

What would really be nice is if acceptable level of service could be 
defined in a more extensible way than just link speed.  (Obviously, link 
speed will always be a constraint.)  Is anyone looking into policy-based 
routing that is based on providing levels of service, as opposed to 
determining whether itUs permissible to transmit certain packets through 
certain nets?

                                 David Walker
                                 Network Services Manager
                                 University of California, Irvine
-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 90 22:44:04 GMT
From:      phil.indiana.edu!jwd@iuvax.cs.indiana.edu  (Jon Dunn)
To:        tcp-ip@nic.ddn.mil
Subject:   Unix BBS's with network support
I am looking for a public domain or commercial bulletin
board system to run under UNIX on a Sun or microVAX.
I need a program can can support both dialup lines and connections
via a TCP/IP-based Ethernet.  It needs to be able to handle file
transfer over the network with a very simple user interface.
Does anyone know of a system which meets all or part of these
specifications?  Thanks!

Jon Dunn
jwd@phil.indiana.edu
-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      24 Jan 90 23:22:15 GMT
From:      pyramid!athertn!joshua@hplabs.hpl.hp.com  (Flame Bait)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
If we must have billing, then I'd make it just like paying for the national
road system.  Everyone who buys a network capable device gets taxed (like
the gas tax) and that money is used to pay for the Internet.  If you buy a
network capable device, and do not actually connected it, too bad.  You 
pay tax anyway.  There might be some 'toll' links that you have to pay
for specially, but most of the infra-structure would be payed for via the
tax.

The interstate road system works very well, I just hope that a national
computer network can work half as well.


Joshua Levy                          joshua@atherton.com  home:(415)968-3718
                        {decwrl|sun|hpda}!athertn!joshua  work:(408)734-9822 
-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      Thu 25 Jan 90 07:44:14-PST
From:      David L. Kashtan <KASHTAN@IU.AI.SRI.COM>
To:        CSP1DWD@OAC.UCLA.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Re: PEP and SL/IP
We typically see around 12Kbaud FTP transfer rates (interactive traffic
has little effect on the FTP rates -- unless a large chunk of output from
the interactive traffic is going over the slip line).  Also note that the
FTP transfer doesn't have much (subjective -- character echo time) effect
on the interactive session due to preferential queueing of the header
prediction code in SLIP.
David
-------
-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jan 90 15:33:06 -0800
From:      jqj@rt-jqj.Stanford.EDU (JQ Johnson)
To:        tcp-ip@sri-nic.arpa
Subject:   telnet -> X.25 PAD experience wanted
We are looking for sites with experience deploying telnet to X.3/X.29/...
gateways, where the PAD side is connected to a public X.25 network such
as Telenet, and where traffic is largely initiated on the IP side by
telnet clients talking to remote X.25 services.  We are interested in
integrated gateways, not in telnet "milking machines" hooked by asynch
connections to a normal PAD.

We currently have a Develcon switch that provides this functionality,
and are investigating the cisco "protocol translator" and Gandalf's
Starmaster X.25 software.  Both experience with these products and
recommendations for other vendors would be welcome.

Of particular concern to us are issues of user interface (e.g. "does
the gateway support X.3/X.121 profiles keyed to IP address?"), access
and resource control ("does the gateway permit specification of reverse
charging, and does it provide us with enough data to charge back the
cost of X.25 traffic?"), and reliability ("does it work?").

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
-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jan 90 08:22:00 EST
From:      <FILLMORE%EMRCAN.bitnet@ugw.utcs.utoronto.ca>
To:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Mac FTP
We recently started using Wollongong's MacPathway Access, which is based
on the NCSA code.  It has FTP client and server with a nice interface.
I have used it to transfer files between my Mac and another Mac, a Sun
workstation, and a CDC Cyber NOS/VE system.
There are a few little bugs which I reported to Wollongong and will be fixed
soon.
They will be coming out with an enhanced version in a few months which
supports SMTP mail.
I think it's worth a look.
________________________
Bob Fillmore, Systems Software & Communications     BITNET:  FILLMORE@EMRCAN
  Computer Services Centre,                         BIX:     bfillmore
  Energy, Mines, & Resources Canada                 Voice:   (613) 992-2832
  588 Booth St., Ottawa, Ontario, Canada  K1A 0E4   FAX:     (613) 996-2953
-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 90 03:37:25 GMT
From:      cs.utexas.edu!samsung!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!smart@tut.cis.ohio-state.edu  (Robert Smart)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
In article <9001230751.AA24847@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes:
>
>     Accounting for packets is a pain.  They can get lost, duplicated, etc. 

I agree that bandwidth pricing is much better because of the regularity
of the bills. However if you want to charge for, or just keep track of,
packet usage then you should charge for packets as they _leave_ the
network not as they enter it. Of course they may leave your network by
being inserted on an ethernet which may not get the packet to its destination
but that is out of your control. At least you don't charge the user for
packets that are dropped by the very service the user is paying for.

I would also add that a packet from A to B could be for the benefit of
A or B. The best way to charge for the packet is to charge both A and
B for the packet. This is not only fairer, it also increases your
revenue.

Suppose you want to set up a commercial TCP/IP service consisting of
a hub at Los Angeles, a hub at New York and a leased line in between.
How do you charge for this service? The leased line is your main
cost: I think you must try to distribute the cost so that those users
who want to use LA-NY link a lot are charged more than those who
rarely or never use it. Here's how I'd do it:

Users would be basically charged by the bandwidth of their link to
the hub. Each user would have to specify what % of that bandwidth 
would be for packets to/from the LA-NY link. They would be charged
extra for that specified bandwidth sufficiently so that the total
extra revenue will fund the LA-NY link with enough speed to handle
the total anticipated average demand. The actual use of the LA-NY 
link will be monitored (but using exiting packets not entering packets).
The link software will be clever enough to ensure that when the link
is fully utilized it distributes the usage in the proportions paid
for. Moreover if a user's long term usage of the link exceeds the
% they have specified (because they use spare bandwidth when it isn't
flat out or because the link has greater total capacity than is
needed) then the amount they get when the link is flat out is actually
adjusted downwards so that they tend to return to their specified
percentage (though this process will never cut them off completely).

Of course when you send the monthly bill you tell the user what % of
the LA-NY link they actually used. If they are using more than they
pay for then you point out the advantages of them specifying a more
realistic estimate of their LA-NY bandwidth. Perhaps after a while
you configure your link software so that their use of the LA-NY link
is throttled back even when there is no other traffic, just to
encourage them to pay their fair share.

Comments?

Bob Smart <smart@ditmela.oz.au> or <uunet!munnari!ditmela.oz!smart>
-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 90 04:16:58 GMT
From:      cs.utexas.edu!samsung!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!smart@tut.cis.ohio-state.edu  (Robert Smart)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
In article <1990Jan24.141830.12650@nisc.nyser.net> ldg@nisc.nyser.net.UUCP (Leo Geoffrion) writes:
>
> The "bean conters" who build budgets get very very nervous about 
> unpredictable budget lines.  At the present time, we pay a fixed annual
> fee for access to the Internet.  If this were changed to a pay per use
> chargeback, I'd have a far harder time convincing accountants that 
> the College should continue the service because it evokes fears that
> we could be hit with large bills.  

I know of 3 circumstances where large bills have been unexpectedly
generated on a pay-for-use network in Australia:

(1) Hackers doing overseas file transfers after breaking in.

(2) A mail routing loop through software that didn't notice :-(.

(3) A mail gateway carrying small amounts of traffic suddenly starts
    being used for file transfers (from things like mail archive servers).

Pay for use networking will give your network managers grey hairs,
and kill any chance of your site doing altruistic things. It is a
disaster and shouldn't be contemplated.

On the other hand keeping track of usage is useful (e.g. to detect
sudden loops, hackers, inappropriate use, ...). Such information
needs to break out by application (so that ICMP echo packets aren't
counted, etc.).

Bob Smart
-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jan 90 10:51:11 EST
From:      hsw@sparta.com (Howard Weiss)
To:        dialogic!drich@uunet.uu.net
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip for 386 UNIX
I too am running the ISC 386/IX tcp/ip package - but I have
some problems with connections not fully closing.  We have a
SUN as our main mail machine which in turn forwards mail to
the 386.  We see problems with smtp connections staying around
forever (in close_wait state on the 386 and in fin_wait_2 on the
SUN), and the smtp sendmail server no longer answers on the
386.  Looking at the BSD sendmail source, it looks like sendmail
fails on the accept call to accept the connection.  The only
way to get things rolling again is to kill sendmail on the 386
and then restart it.

Ever seen any behavior like this?  Anyone have any fixes?

Howard Weiss


-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jan 90 15:18:07 EST
From:      Bob Haring-Smith <RHH@brownvm.brown.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   tn3270 for Apollo or RT?
Does anyone know of a source for tn3270 for an Apollo Domain 3000 or 3500
or for an IBM RT running AIX 2.2.1?  I can download via anonymous ftp.
Please reply by mail to rhh@brownvm.brown.edu.  Thanks.
                                           --Bob
-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jan 90 15:30:47 EST
From:      mep@aqua.whoi.edu (Michael E. Pare)
To:        daemon@tut.cis.ohio-state.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Twisted pair Ethernet
My initial question is can you remove the termination from one of the legs
and have the partition light go on for that module in the Multiconnect
chassis?  If not then you are seeing a problem waiting to happen because your
machines will not properly respond to collisions.  You can get away with it
with a few machines running at the same time, but not once you start getting
traffic on your net.

You have 1200 foot runs including twisted pair.  The standard for thinnet
calls for a max length of 185m (606 ft), not including twisted pair. 
Depending on the construction of the twisted pair (ie. gauge, etc.) the
limitations on run lengths varies, with a best case of 406 ft using all
22awg twisted pair up to a max of 867 ft using all coax (and using 3COM
transceivers which are supposed to be designed to enable you to double
the network standard lengths since they are fine tuned to detect collisions
better).

The keys here are collision detection (timing restraint) and signal
attenuation which will cause more problems with larger packets and greater
traffic (you'll notice severe slowdowns caused by necessary packet
retransmits due to the 'bad' packets on the net).

You don't have to adhere to standards to make things run, but can you 
gaurantee they will keep running under all conditions!!
-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 90 11:56:11 GMT
From:      HANK@BARILVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Re: Billing for use

>"Billing" is more than collecting data and sending out bills.  "billing"
>is a concrete expression of a policy.  Each different approach to
>billing will cause users to respond differently.  Do you want to hook
>users when they are young? Offer an "educational discount".  Do you want
>to encourage use?  Offer a flat fee (or a set of wide steps) for
>service, or volume discounts.  Do you want to discourage "waste"?  Offer
>a fee-per-use, or a volume surcharge.  Do you want to encourage
>institutions to build their own services?  Have an element of charging
>be a "per attachment" charge.  Do you want to discourage private
>networks?  Have a flat fee for all attachments by a customer.  And so
>on.  All of the polices mentioned above are in current use by providers
>of some kinds of services, as are many other policies.  Before a
>network, or internet, begins figuring out the technical means for
>"billing", the organization ought to figure out what POLICIES it wants
>to have regarding usage, and these will drive the way billing MUST be
>done.
>
>Alex McKenzie

I couldn't agree more.  Collecting information such as total traffic
between two hosts may be a necessary exercise in order to determine
where line speed increases are necessary but for billing?  Imagine
you have a host XYZ that serves as a major hub for distribution
lists.  All sorts of lists are centered at this hub, ones like tcp-ip
among them.  People mail into them, get billed for sending n bytes
to this host, but then this host explodes the mail into hundreds and
sometimes thousands of copies.  Is it fair to bill the server
for vast quantities of mail (this could also be an anonymous FTP
database of many crucial files).  Ok,  say we agree that billing
the sender is not always best.

So we say, lets bill the person who sent the mail into the list that
got exploded into 600 copies.  If we look at snail mail systems for
an analogy, we can see that it is really this user who should be
billed.  But once again, technology supercedes what our ancient
perceptions lead us to believe is true.  Yes, this user sent in the
mail that got rebroadcasted, but this user was in actuality replying
to someone's question in the list on SNMP or SLIP. Someone asked a
15 line question about some arcane facet of SNMP and some expert
responded with a 120 line response.  So what we have accomplished
in billing this expert is to discourage him/her from replying to
questions in distribution lists.  If the person wishes to be a
good Samaritan, he/she will send a reply directly to the user who
posted the question (and be billed for it), but all the other people
in the list will never know the answer.

I believe that by introducing billing, all mass distribution lists
will become large "question" boards with no answers.  We will have
effectively killed off the vast amount of cooperation that goes on
daily over the Internet.

OK.  So we can't bill the sender.  How about the receipant paying?
How easy would it then be for some hostile user/host to send a couple
of gigabytes of information to your host, just so that you got billed
for it?

I don't believe we can bill by sender or by receiver.  Anyone who
tries it is just asking for trouble.  If one must recapture costs,
then use the example given by someone else in this list and impose
a yearly tax for Internet connection, whether you use it or not.

Hank Nussbacher
ILAN - Israeli Academic Network

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jan 90 18:50:09 EST
From:      Kim N. Anderson <kima@wsu-eng.eng.wayne.edu>
To:        tcp-ip@nic.ddn.mil
We have an Ethernet/tcp-ip based LAN consisting of approximately
80 pc's via PCNFS and 40 Sun workstations (Sun 3's, 4's and 386i's).

Currently, our users have accounts on different Sun workstations.
In order to send mail to any particular user within our LAN, the sender
is required to know both the recipient's login ID and machine name, i.e.

		"mail kima@trace".

The problem is that many of our users aren't able to remember which machine
the recipient desires his mail, which makes it difficult to encourage people to
use e-mail.

I have attempted to correct this problem by modifying the alias file on all
systems to indicate the machine name of each user within our LAN, i.e. 

		"kima:kima@trace".

This enabled users within the building to send mail to kima without having
to know the machine name.  The problems I have encountered include modifi-
cation of the alias file on all systems whenever we add a new user and users
enabling the .forward feature within their directories which redirects mail
to other systems causing "multiple hop" problems.

I am sure that many of you must have had a similar environments and have
resolved this problem.  Can anyone help?

P.S. I have also been asked to attempt to enable our pc users to send and
receive mail without having to first log into one of the Sun workstations.
I have reviewed Sun's Lifeline Mail application and find it unsuitable and
too expensive for our environment.  Is there any free domain software
capable of doing this?


Kim Anderson			|
5050 Anthony Wayne Drive	|
Wayne State University		|  email:  kima@wsu-eng.eng.wayne.edu
Detroit, MI  48201		|	
(313) 557-3824			|

"Be careful of reading health books, you might die of a misprint."
                -- Mark Twain
-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jan 90 22:54:25 -0500
From:      enger@sccgate.scc.com ( Robert M. Enger)
To:        tcp-ip@nic.ddn.mil, zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!nic.MR.NET!thor.acc.stolaf.edu!stolaf!towfiq@tut.cis.ohio-state.edu
Subject:   Re: Duplicate ICMP packets out of Internet
regarding the cause of duplicate packets:

Yes, the reason you SEE the duplicates is because there is no reliable
transport layer screening them out for you (ie, no TCP).

But, the CAUSE of the duplication is likely a bug in
the NSFnet's NSS (routers).  I am told that IBM is aware
of the problem, and will be fixing it.

Bob
-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 90 15:14:07 GMT
From:      daemon@tut.cis.ohio-state.edu  (Harvey)
To:        tcp-ip@nic.ddn.mil
Subject:   Twisted pair Ethernet

We installed an ethernet about 9 months ago using 3-com pairtamers,
a 3-com multiport repeater and transceivers, and Western Digital
WD8003 cards in a variety of PCs.  The installation covers 3 floors
of an 80,000 sq ft building.  The longest cable runs are approximately
1200 feet as I recall, and most include an initial run of 100 to 200
feet twisted pair, and then thin ethernet coax for the rest.  At the
moment the system has about 35 stations, and is not taxed.  In nine
months the only problems we've had were attributable to either broken
bnc connectors (usually due to the connector carelessly getting in
the way of moving furniture) or power glitches causing the repeater
or the bridge connecting it to the outside world to lock up.  There
hasn't been a single problem that I recall that can be traced to
the pairtamers, the WD8003, or any other equipment failure.

The 3COM pairtamer is said to be compatible with other equipment
than 3COM's, and a cable leg that includes a pairtamer can be
extended with thin coax and dropped to multiple stations.  That
capability saved us a great deal of time and money, because our
building was already wired with beaucoup twisted pair, but no
coax.  So we were able to get from the repeater chasis through
the physically difficult parts of the building using the pairtamers,
and then set up multiple adjacent rooms by extending the pairtamer
runs with thin coax.  The only drawback o the pairtamer is that
it costs some distance, because 1 foot of twisted pair counts the
same as 2-4 feet of thin coax in composing the approximately 1000'
maximum run for a cable leg.  The other limitation to be aware of
is that the twisted pair runs don't work well if they are interrupted
by telephone system type punch blocks.  Sometimes you can get away with
it, but the system works best when the pairtamer modules at each end
of a run are connected by an unbroken run of wire.

The advantage for us came about largely because our building already
had twisted pair in place.  If I were starting from scratch, It
is possible that running thin coax would be a competitive strategy.

Harvey Shulman
Department of Psychology
Ohio State University
-------
-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 90 16:05:33 GMT
From:      zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!nic.MR.NET!thor.acc.stolaf.edu!stolaf!towfiq@tut.cis.ohio-state.edu  (Mark Towfigh)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Duplicate ICMP packets out of Internet
In article <4508@sbcs.sunysb.edu> root@.sunysb.edu (Systems Staff) writes:

   Out of curiousity, does anyone know the cause of ICMP packet 
   thats seems to occur on occasion in the Internet?

   64 bytes from 128.6.4.7: icmp_seq=11. time=360. ms
   64 bytes from 128.6.4.7: icmp_seq=11. time=380. ms

   64 bytes from 128.6.4.7: icmp_seq=0. time=299. ms
   64 bytes from 128.6.4.7: icmp_seq=0. time=320. ms

   64 bytes from 128.6.4.7: icmp_seq=2. time=320. ms
   64 bytes from 128.6.4.7: icmp_seq=2. time=580. ms
   64 bytes from 128.6.4.7: icmp_seq=2. time=580. ms

   etc.

This is because ICMP, which operates under UDP, not TCP, is an
inherently unreliable protocol.  There is no checking done to see if
multiple packets are received, etc.

Mark
--
Mark Towfigh, Racal Interlan, Inc.		   towfiq@interlan.Interlan.COM

  "The Earth is but One Country, and Mankind its Citizens" -- Baha'u'llah
-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 90 16:50:26 GMT
From:      encore!pinocchio.encore.com@husc6.harvard.edu  (Jeff d'Arcy)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Duplicate ICMP packets out of Internet
towfiq@interlan.Interlan.COM (Mark Towfigh):
> This is because ICMP, which operates under UDP, not TCP, is an
> inherently unreliable protocol.  There is no checking done to see if
> multiple packets are received, etc.

ICMP does not operate under or over UDP.  They are peer protocols which
both run on top of IP.

Jeff d'Arcy     OS/Network Software Engineer     jdarcy@encore.com
  Encore has provided the medium, but the message remains my own
-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 90 17:24:08 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!samsung!umich!wsu-cs!egrunix!srodawa@ucsd.edu  (Ronald Srodawa)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
Paying a fee when purchasing a device with a network capability is like a
gas tax?  NO WAY!  A gas tax is typically a linear function of usage since
your vehicle consumes gas proportional to the miles driven.  Exact
parameters vary from driver to driver and vehicle to vehicle.  Your proposal
is just as bad as a "royalty fee" applied to every tape cassette purchase
becauase you might record a copyrighted work.  I agree with an earlier
statement that desired policy should determine the scheme.  Further, any
charges will radically change user behavior and availability of network
services.  If charging must be implemented (I hope it wouldn't be) then 
a scheme must be found which has low overhead compared to others.  Charging
by the packet doesn't fit the bill here.  Ron.

=============================================================================
| Ronald J. Srodawa               | Internet: srodawa@unix.secs.oakland.edu |
| School of Engineering and       | UUCP:     srodawa@egrunix.UUCP          |
|    Computer Science             |                                         |
| Oakland University              |                                         |
| Rochester, Michigan  48309-4401 |                                         |
| Phone: (313) 370-2247           |                                         |
=============================================================================
-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      Thu, 25 Jan 90 13:55:14 O
From:      Hank Nussbacher <HANK%BARILVM.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.ARPA
Subject:   RE: Billing for use
>"Billing" is more than collecting data and sending out bills.  "billing"
>is a concrete expression of a policy.  Each different approach to
>billing will cause users to respond differently.  Do you want to hook
>users when they are young? Offer an "educational discount".  Do you want
>to encourage use?  Offer a flat fee (or a set of wide steps) for
>service, or volume discounts.  Do you want to discourage "waste"?  Offer
>a fee-per-use, or a volume surcharge.  Do you want to encourage
>institutions to build their own services?  Have an element of charging
>be a "per attachment" charge.  Do you want to discourage private
>networks?  Have a flat fee for all attachments by a customer.  And so
>on.  All of the polices mentioned above are in current use by providers
>of some kinds of services, as are many other policies.  Before a
>network, or internet, begins figuring out the technical means for
>"billing", the organization ought to figure out what POLICIES it wants
>to have regarding usage, and these will drive the way billing MUST be
>done.
>
>Alex McKenzie

I couldn't agree more.  Collecting information such as total traffic
between two hosts may be a necessary exercise in order to determine
where line speed increases are necessary but for billing?  Imagine
you have a host XYZ that serves as a major hub for distribution
lists.  All sorts of lists are centered at this hub, ones like tcp-ip
among them.  People mail into them, get billed for sending n bytes
to this host, but then this host explodes the mail into hundreds and
sometimes thousands of copies.  Is it fair to bill the server
for vast quantities of mail (this could also be an anonymous FTP
database of many crucial files).  Ok,  say we agree that billing
the sender is not always best.

So we say, lets bill the person who sent the mail into the list that
got exploded into 600 copies.  If we look at snail mail systems for
an analogy, we can see that it is really this user who should be
billed.  But once again, technology supercedes what our ancient
perceptions lead us to believe is true.  Yes, this user sent in the
mail that got rebroadcasted, but this user was in actuality replying
to someone's question in the list on SNMP or SLIP. Someone asked a
15 line question about some arcane facet of SNMP and some expert
responded with a 120 line response.  So what we have accomplished
in billing this expert is to discourage him/her from replying to
questions in distribution lists.  If the person wishes to be a
good Samaritan, he/she will send a reply directly to the user who
posted the question (and be billed for it), but all the other people
in the list will never know the answer.

I believe that by introducing billing, all mass distribution lists
will become large "question" boards with no answers.  We will have
effectively killed off the vast amount of cooperation that goes on
daily over the Internet.

OK.  So we can't bill the sender.  How about the receipant paying?
How easy would it then be for some hostile user/host to send a couple
of gigabytes of information to your host, just so that you got billed
for it?

I don't believe we can bill by sender or by receiver.  Anyone who
tries it is just asking for trouble.  If one must recapture costs,
then use the example given by someone else in this list and impose
a yearly tax for Internet connection, whether you use it or not.

Hank Nussbacher
ILAN - Israeli Academic Network
-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 90 18:39:26 GMT
From:      root@sbcs.sunysb.edu  (Systems Staff)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Duplicate ICMP packets out of Internet
In article <TOWFIQ.90Jan25100533@interlan.Interlan.COM> towfiq@interlan.Interlan.COM (Mark Towfigh) writes:
>In article <4508@sbcs.sunysb.edu> root@.sunysb.edu (Systems Staff) writes:
>
>   Out of curiousity, does anyone know the cause of ICMP packet 
>   thats seems to occur on occasion in the Internet?
>This is because ICMP, which operates under UDP, not TCP, is an
		 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

	Yer wrong.  ICMP operates over IP.  And of course IP makes
	no guarantees of delivery.
	
>inherently unreliable protocol.  There is no checking done to see if
>multiple packets are received, etc.
>
>Mark Towfigh, Racal Interlan, Inc.		   towfiq@interlan.Interlan.COM

	I received one response to this posting which stated the
	problem was with IBM Token Ring drivers located in the NSS.
	The problem is apparently load dependent which seems to 
	explain why I only see this effect on occasion.

					Rick Spanbauer
					State U of NY/Stony Brook
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      25 Jan 90 20:18:07 GMT
From:      RHH@BROWNVM.BROWN.EDU (Bob Haring-Smith)
To:        comp.protocols.tcp-ip
Subject:   tn3270 for Apollo or RT?

Does anyone know of a source for tn3270 for an Apollo Domain 3000 or 3500
or for an IBM RT running AIX 2.2.1?  I can download via anonymous ftp.
Please reply by mail to rhh@brownvm.brown.edu.  Thanks.
                                           --Bob

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 90 00:29:40 GMT
From:      toro!nick@uunet.uu.net  (Nicholas Jacobs)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Whose bridges support SNMP?
Wellfleet's gateways also support SNMP. They have an X-based SNMP
monitoring package that runs on the SPARCstation 1, but I haven't
had a chance to check it out yet :-(.

Nicholas Jacobs
+-----------------------+----------------------------+----------------------+
| UUCP: uunet!toro!nick | Internet: nick@toro.uu.net | AT&T: (212) 236-3230 |
+-----------------------+----------------------------+----------------------+
"Disclaimer? The legal fees are probably more than my annual salary..."
-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Jan 90 07:39:48 CST
From:      "David W. Dearth, Director" <C0001@UMRVMB.UMR.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: tn3270 for Apollo or RT?
If you find anything for the Apollo, I would be interested in the
information. Thanks...
Acknowledge-To: <C0001@UMRVMB>
-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Jan 90 07:01:12 EST
From:      schulman@umd5.umd.edu (Leisure Suit Marty)
To:        tcp-ip@nic.ddn.mil
Subject:   Maximum Entropy Routing


About a month ago, some posts to this list mentioned "maximum entropy
routing".  Could someone please provide a pointer to on-line or off-line
references to this topic?  Thanks.

				Marty
-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 1990 08:10:34 EST
From:      COINS@A.ISI.EDU
To:        TCP-IP@NIC.DDN.MIL
Cc:        COINS@A.ISI.EDU
Subject:   SLIP PUBLIC DOMAIN
   DOES ANYONE KNOW WHERE I CAN OBTAIN PUBLIC DOMAIN SOURCE FOR SLIP,
FOR THE IBM PC (DOS)?

THANK YOU
LYNN
-------
-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Jan 90 9:36:25 EST
From:      Scott Ryburn <ryburn@granite.cr.bull.com>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PEP and SL/IP
As a new reader of the dialog in this forum, I have noticed several
references to SL/IP and Van or VanJacobsen's header compression
algorithm.  How can I find out more about this subject?  I am working
on ways to improve LAN performance for our products.

Thanks for your assistance.  Scott Ryburn  (ryburn@granite.bull.com)
-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Fri 26 Jan 90 13:28:22-PST
From:      Eric M. Berg <A.Eric@GSB-How.Stanford.EDU>
To:        Info-Cobol@MC.LCS.MIT.EDU, tcp-ip@NIC.DDN.MIL
Subject:   ComputerWorld discovers new use for Anonymous FTP
From coverage of the Robert Morris "Internet Worm" trial in the 1/15/90
issue of ComputerWorld (page 6):

    During the trial's first week, federal prosecutors repeatedly prodded
    witnesses, all of whom are computer science experts, to answer their
    queries in basic, non-technical terms.  The witnesses were interrupted
    often and asked to explain a wide variety of terms including "bug", 
    "crashing" and "running program".

    The defense was less diligent in asking witnesses to clarify certain
    terminology, perhaps in a maneuver to befuddle jurors and cause them to
    doubt the strength of the prosecution's case.  In cross-examination
    of Dean Krafft, a Cornell University computer scientist, for example,
    defense attorney Thomas Guidoboni closely questioned Krafft on the
    function of the "Anonymous FTP" utility without asking him to explain
    it first.  In follow-up questioning, however, prosecutor Mark Rasch
    pressed Krafft to tell jurors that the term describes a utility
    that enables a user to find out who else is logged on to the computer
    system.

Remember, you saw it here first!  :-}
-------
-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Fri, 26 Jan 90 16:42:20 EST
From:      barns@gateway.mitre.org
To:        tcp-ip@NIC.DDN.MIL
Subject:   billing for use; report announcement
I wrote a sizable paper on "enhanced" billing designs for the DDN,
as I mentioned the last time that the topic of network usage billing
came up here.  At that time it was not publicly available, but it
has since been released.  You can obtain it in the form of a PostScript
file (details below), and I have a small number of paper copies
which I can mail if someone wants it and doesn't have a PostScript
printer.  It is a large document (~114 pages) and many parts are
very DDN specific, but there is some treatment of general design
issues too.  Feel free to send me any comments if you so desire.

The report can be obtained by anonymous FTP from host aelred-3.ie.org
[192.48.115.36].  The uncompressed file is pub/billing.ps (710899 bytes)
and the compressed version is pub/billing.ps.Z (260701 bytes).  There
is no ASCII-only version (sorry, but the pictures and more importantly,
some tables that contain essential information, do not convert readily).

Here are some comments on the discussion to this point:

You may or may not need special identifiers at any or all layers for
billing purposes.  You don't know what you need until you have defined
your objectives.  Also, identification of a billable entity can be
explicit or implicit.  A charging system levies charges on one or more
types of chargeable events.  To do this, it must identify the
occurrence of the event, measure it in some dimension (typically but
not necessarily by simply counting it), and attribute it to some
billable entity.  If the chargeable event is a layer N event, then you
need attribution information visible at layer N that maps to a billable
entity.  So, if transmitting (or receiving) an IP datagram is a
chargeable event, you have to make the attribution information visible
to an IP entity.  Whether the normal basic IP header provides the
needed information depends on your notion of a billable entity.  If you
only care about billing IP sources or destinations, you have enough
EXPLICIT information in the IP header.  If you want to bill end users,
you have IMPLICIT information to do the attribution if and only if all
end users have separate IP addresses.  If you need to bill any
multi-user systems, you do not have IMPLICIT information and need
EXPLICIT information such as an IP option.

Billing doesn't necessarily imply authentication.  It implies attribution.
Authentication is a mechanism you might use to improve the chances of
explicit information used for attribution being "correct" relative to
some external standard.  A reasonable person might want this feature.
However, there is no magic here.  To authenticate the identification of
something still requires that the thing be identified.  In the IP DG
billing example, an IP router still needs to know which authenticated
billable entity identity goes with which DG.  This seems to involve
having some kind of recognizable element of the DG that maps to a
billable entity.  The form may be different (authentication token or
certificate of some kind) but it has to be there, and it has to map.

X.25 vs. Connectionless doesn't get at the real problems of cost
attribution.  Transport multiplexing on a Network connection is what
gets us in trouble with Network layer billing.  If you multiplex TP2 on
X.25 as Europe does (or talks about), the X.25 switch doesn't know
Fred's TP2 traffic from Frank's (or Fritz's from Franz's).  The X.25
call accounting will duly kick out its one call accounting record, but
that's no help to the system that originated the X.25 link if it has to
bill the users separately.  This is a Network/Transport mess, not a
CO/CL mess.

My typing time is up, for which you can all be grateful.

Bill Barns / MITRE-Washington / barns@gateway.mitre.org
-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 90 13:10:34 GMT
From:      COINS@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   SLIP PUBLIC DOMAIN


   DOES ANYONE KNOW WHERE I CAN OBTAIN PUBLIC DOMAIN SOURCE FOR SLIP,
FOR THE IBM PC (DOS)?

THANK YOU
LYNN
-------

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 90 13:39:48 GMT
From:      C0001@UMRVMB.UMR.EDU ("David W. Dearth, Director")
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 for Apollo or RT?

If you find anything for the Apollo, I would be interested in the
information. Thanks...
Acknowledge-To: <C0001@UMRVMB>

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 90 15:34:50 GMT
From:      bnrgate!bnr.ca!aruigrok@uunet.uu.net  (Adrian C Ruigrok)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mac FTP
In article <867@umabco.UUCP> lwilson@umabco.UUCP (Lowell G. Wilson) writes:
> I know that I could get files from the one mac to the
> mainframe and then from the mainframe to the other mac, but I'd really
> like a more direct approach if there is one available at the same price
> as the NCSA product! Does anyone know of such a creature? If so, I could
> use the information... 

There seems to a lot of people suddenly asking about this ability to ftp 
from a Mac to a Mac.  If Public Folder (an excellent solution for Mac to 
Mac file transfer) does not do what you are hoping for, then there is 
still hope.  Intercon, Wollengong, Kinetics, and others have Mac FTP 
client software built in to their commercial products.  Of course these 
packages are not free.

The FTP clients are quite nice, however, and it is a matter of deciding if 
they are worth the price.  They allow the user to use a Font/DA type 
interface to do the transfer.  It is similar to the HFX utility on A/UX if 
you have seen that.

Finally there is BYU's enhanced version of NCSA telnet.  It provides a 
fine text based client FTP.  I don't think it is completely clean yet, but 
it certainly gets the job done.  It is available by anonymous FTP from 
noc.byu.edu 128.187.7.2   uid=guest  pw=anonymous
Jim Logan puts up new versions from time to time that fix known problems.  
The price is right on this one; it is public domain.

Hope that helps.  If there are other solutions out there for FTP I would 
love to hear about them.  If I get more info, I will summerize it.  Please 
mail replies (as well as posting, if you wish).  By the time I return any 
replies will have scrolled off our server!
Later...
Adrian

Adrian C Ruigrok
Bell-Northern Research
bitnet: aruigrok@bnr.ca
-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 90 18:10:38 GMT
From:      zds-ux!bjstaff@uunet.uu.net  (Brad Staff)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: tcp/ip for 386 UNIX
In article <9001251551.AA03027@cheops.columbia.sparta.com>, hsw@SPARTA.COM (Howard Weiss) writes:
> I too am running the ISC 386/IX tcp/ip package - but I have
> some problems with connections not fully closing.  We have a
> SUN as our main mail machine which in turn forwards mail to
> the 386.  We see problems with smtp connections staying around
> forever (in close_wait state on the 386 and in fin_wait_2 on the
> SUN), and the smtp sendmail server no longer answers on the
> 386.  Looking at the BSD sendmail source, it looks like sendmail
> fails on the accept call to accept the connection.  The only
> way to get things rolling again is to kill sendmail on the 386
> and then restart it.

We are having problems at our site as well.  I don't know who is to blame
for our problems.  We are running a mixture of SCO Xenix, SCO UN*X, and
ISC 386/ix, all with TCP/IP software, all on Zenith 386 machines, all using
WD8003E ethernet cards.

We cannot "ftp" SCO-to-ISC/ISC-to-SCO reliably at all.  We don't seem to
have any problems SCO-to-SCO, nor ISC-to-ISC.  I am suspecting there is
some subtle incompatability in the "ftp" implementations.  The problem seems
most pronounced on large files.  Sometimes rebooting one or both boxes seems
to help for a while.  Usually I just resort to floppy-net :-(.

We also have observed some strange behavior when running rlogin/telnet between
ISC and SCO boxes.  In particular, rlogin connections sometimes lock up.  It's
usually possible to kill the rlogin process, but it usually doesn't work
reliably after that.  Generally, a reboot is necessary to get things working
again.  This happens just often enough to be annoying, not often enough to make
me want to go debug it :-).

Brad Staff
Systems Sofware Engineering
Zenith Data Systems
150 Hilltop Road
St. Joseph, MI 49085
616-982-5791
uunet!zds-ux!bjstaff
-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 90 18:15:12 GMT
From:      zephyr.ens.tek.com!orca.wv.tek.com!pogo!curtj@uunet.uu.net  (Curt Jutzi)
To:        tcp-ip@nic.ddn.mil
Subject:   Port Addresses for Applications (HELP!!!)

I am interested in knowing if there is a way of reserving a socket/port
address for a given application.  I am in the process of trying to build
an application that will listen on a given port, much like FTP or SMTP.  
However, I do not know of a way to reserve this port address for my given
application.  Is there a way to reserve this port address ?  If not, is there
a scheme for collision, or some standard mechanism for resolving where a given 
application resides?

-----------------------------------------------------------------------
    __  /|      Curt Jutzi (Jutz)                      Tektronix Inc.
    \'o.O`      tektronix!pogo.GPID.TEK.COM!curtj      Del. St. 63-356
    =(___)=     (503) 685-3723                         P.O. Box 1000 
       U                                               Wilsonville,OR 97070
   ACK! PHHT!       "Life's an adventure.. go for it"
-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 90 21:24:11 GMT
From:      orion.oac.uci.edu!uci.edu!DHWalker@ucsd.edu  (David Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
In article <17180@joshua.athertn.Atherton.COM> joshua@athertn.Atherton.COM 
(Flame Bait) writes:
> If we must have billing, then I'd make it just like paying for the 
national
> road system.  Everyone who buys a network capable device gets taxed (like
> the gas tax) and that money is used to pay for the Internet.  If you buy 
a
> network capable device, and do not actually connected it, too bad.  You 
> pay tax anyway.  There might be some 'toll' links that you have to pay
> for specially, but most of the infra-structure would be payed for via the
> tax.
> 
> The interstate road system works very well, I just hope that a national
> computer network can work half as well.

[I'm not so sure that the Interstates work that well.  I think there are 
very few of us in the LA area who believe that Interstate funding is able 
to keep up the demand for service.]

Joshua,

I guess I think the "tax" should be on a connection to the network, not on 
the connectable device, if I understand you correctly.  There should be a 
fixed base price that people should pay to be connected, but people who 
need more/better service than others should pay enough additional money to 
increase the network's capacity to provide that service.  Your gas tax 
analogy isn't bad, though, except that per-gallon comes too close to 
per-packet for my liking.

It occurs to me that my thoughts imply that care be taken to see that the 
desired level of service is actually delivered. I suppose that's probably 
one of the things wrong with the Interstates.

                                              David Walker
                                              Network Services Manager
                                              UC Irvine
                                                DHWalker@uci.edu
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      26 Jan 90 23:56:17 GMT
From:      kima@wsu-eng.eng.wayne.edu (Kim N. Anderson)
To:        comp.protocols.tcp-ip
Subject:   (none)

We have an Ethernet/tcp-ip based LAN consisting of approximately
80 pc's via PCNFS and 40 Sun workstations (Sun 3's, 4's and 386i's).

Currently, our users have accounts on different Sun workstations.
In order to send mail to any particular user within our LAN, the sender
is required to know both the recipient's login ID and machine name, i.e.

		"mail kima@trace".

The problem is that many of our users aren't able to remember which machine
the recipient desires his mail, which makes it difficult to encourage people to
use e-mail.

I have attempted to correct this problem by modifying the alias file on all
systems to indicate the machine name of each user within our LAN, i.e. 

		"kima:kima@trace".

This enabled users within the building to send mail to kima without having
to know the machine name.  The problems I have encountered include modifi-
cation of the alias file on all systems whenever we add a new user and users
enabling the .forward feature within their directories which redirects mail
to other systems causing "multiple hop" problems.

I am sure that many of you must have had a similar environments and have
resolved this problem.  Can anyone help?

P.S. I have also been asked to attempt to enable our pc users to send and
receive mail without having to first log into one of the Sun workstations.
I have reviewed Sun's Lifeline Mail application and find it unsuitable and
too expensive for our environment.  Is there any free domain software
capable of doing this?


Kim Anderson			|
5050 Anthony Wayne Drive	|
Wayne State University		|  email:  kima@wsu-eng.eng.wayne.edu
Detroit, MI  48201		|	
(313) 557-3824			|

"Be careful of reading health books, you might die of a misprint."
                -- Mark Twain

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Jan 90 12:19:00 EST
From:      perry@MCL.Unisys.COM (Dennis Perry)
To:        bbn.com!mckenzie@bbn.com, tcp-ip@nic.ddn.mil
Cc:        perry@mcl.unisys.com
Subject:   Re: billing for use
Ah, a voice crying in the wilderness! :-)

dennis
-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Jan 90 17:38:11 CST
From:      al322516@mtecv2.mty.itesm.mx (LOZANO A MARIA LUISA)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP Bibliography Requested
Hi There!!
 We are a group of students from Monterrey's Institute of Technology
at Monterrey, Mexico. 
 Actually we are doing an investigation about TCP/IP and later in the
semester we'll have to develop an operational system running on 
Ethernet using TCP/IP. 
  Can somebody please tell us where we can find literature that will
fit our needs (basic but not so basic) and if posible a server on
either Internet or BITNET with examples of programs.
  Thanks everybody.
Maria Luisa Lozano-Aranda-DiazAACCCCCCCCCCCCCCCCCCCCC??
BBBAACCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCIf you think the	
answer will be too elementary for this list you may e-mail to any of
the following accounts:
aInternet:  
al3225166@mtecv2.mty.itesm.mx
al296641@mtecv2.mty.itesm.mx (Antonio Quesada-Duarte)
BITNET:
AL296641@TECMTYVM.BITNET (Antonio Quesada-Duarte)
ABBDD
Thanks everybody!!!!!!!
Maria Luisa Lozano-Aranda-Diaz
-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      Sat, 27 Jan 90 20:31:14 EST
From:      bzs@world.std.com (Barry Shein)
To:        tcp-ip@nic.ddn.mil
Subject:   why IP should pass UID information

I will say what I said last time "how to create a billing system for
the internet" came up (or was it the time before last?)

Creating any sort of accounting system for something as large as the
internet is an immensely complicated endeavor and probably very few
(if any) of the people discussing this here have the requisite skills
beyond adding specific advice on what is technologically feasible and
perhaps a few other wise comments (but not a complete picture.)

Everything from ensuring the network doesn't collapse under the added
weight of accounting to what laws, regulations and other legislative
conundra define the boundaries must be taken into account.

After those hundred or so considerations are carefully laid out an
economic model would have to be cast and at least informally studied
to see if, at the end of it all, one can even pay for the system so
specified (or at least the cost of creating the economic model.)

And it probably would not be a bad idea to research whether past
behavior is even a valid predictor of future behavior once one has
thrown some billing mechanism into the soup.

What might work within a relatively autocratic organization will
simply not extrapolate to thousands of different organzations, so
politically most any anecdote is probably close to useless other than
as background material (as in "on our campus we charge for...")

Then again, some brave souls are pushing forward and doing this sort
of thing anyhow simply to make connectivity possible. However naive
their models they at least will themselves live or die by them (rather
than merely face the prospect of disbanding some committee in shame
and blame.)

Perhaps all we should bill for is discussions of highly speculative
billing models, that might just solve the problem at hand.

        -Barry Shein

Software Tool & Die    | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 90 19:03:52 GMT
From:      david@g.ms.uky.edu  (David Herron -- a slipped disk)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: why IP should pass UID information
Don't telephone networks only cut an accounting record at the beginning
and ending of a call?

Are you trying to suggest cutting accounting rrecords at every packet?  Sounds
like a very high amout of overhead to meee...

-- 
<- David Herron; an MMDF guy                              <david@ms.uky.edu>
<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<- Coming to a nameserver near you --SOON--: david@davids.mmdf.com
<- 	(until then, david%davids.mmdf.com@rutgers.edu will work)
-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 90 19:13:09 GMT
From:      david@g.ms.uky.edu  (David Herron -- a slipped disk)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
In article <9001232201.AA22726@ucbvax.Berkeley.EDU> forster@CISCO.COM (Jim Forster) writes:
>Billing by link is certainly easy to implement and easy to understand, but it's
>not as fair as other schemes.  If I were building a network that had to
>recover its costs I'd want to use a different scheme.

I only want to get my bits through your network.  Why should I care or worry
about how you get them through your network?  If you inneficient about
it why should I pay extra?

From your end it makes sense to charge by packet.  That's how much work
you put out.

From my end it makes sense for you to charge by byte -- that's how much
work I get out of you.
-- 
<- David Herron; an MMDF guy                              <david@ms.uky.edu>
<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<- Coming to a nameserver near you --SOON--: david@davids.mmdf.com
<- 	(until then, david%davids.mmdf.com@rutgers.edu will work)
-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 90 19:29:44 GMT
From:      zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!km@tut.cis.ohio-state.edu  (Ken Mandelberg)
To:        tcp-ip@nic.ddn.mil
Subject:   Unix version of ka9q?
I may be dreaming, but at one time I though I read that someone was
rewriting ka9q to provide an tcp implementation better adapted to Unix.
I presume this meant a socket style interface for independent network
programs, instead of the monolithic approach in the pc derived
version.

Was I dreaming?
-- 
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
-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      27 Jan 90 22:28:42 GMT
From:      ka9q.bellcore.com!karn@bellcore.com  (Phil Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Unix version of ka9q?
In article <4921@emory.mathcs.emory.edu> km@mathcs.emory.edu (Ken Mandelberg) writes:
>I may be dreaming, but at one time I though I read that someone was
>rewriting ka9q to provide an tcp implementation better adapted to Unix.
>I presume this meant a socket style interface for independent network
>programs, instead of the monolithic approach in the pc derived
>version.

You're probably referring to the "NOS" version of my code, which is
currently up and running in quite a few sites but is still being enhanced.

This version uses a small and very simple "network operating system" as the
base for the network tasks and applications. The applications do use a
programming interface very close to (but not identical to) Berkeley sockets.
The differences are a result of my using the standard Turbo-C I/O library.
For example, socket descriptors and file descriptors occupy a separate
space, and you can't issue read() and write() calls on sockets.

Phil
-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Jan 90 12:39:01 -0800
From:      gary@salt.acc.com (Gary Krall)
To:        tcp-ip@nic.ddn.mil
Subject:   Protocol differences

Has anyone done any comparisons on the protocol differences between 
IBM PC TCP/IP implementations?  Specifically the differences between those
companies supporting the MIT implementation versus the Univ of MD extensions
used by IBM?

Thanks,

Gary.
-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 90 02:05:56 GMT
From:      stealth.acf.nyu.edu!brnstnd@nyu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Port Addresses for Applications
In article <8446@pogo.WV.TEK.COM> curtj@pogo.WV.TEK.COM (Curt Jutzi) writes:
> I am interested in knowing if there is a way of reserving a socket/port
> address for a given application.  I am in the process of trying to build
> an application that will listen on a given port, much like FTP or SMTP.  

The IETF assigns standard TCP ports between 0 and 255. Eventually that
range will be full and they'll start assigning higher numbers. If your
application is sufficiently useful, mature, and documented, ask for a
number.

Ports 50000 and up are generally reserved for experimental servers.

The story is a lot more complicated but that'll get you started.

---Dan
-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 90 04:07:41 GMT
From:      stjohns@umd5.umd.edu  (Mike St. Johns)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Port Addresses for Applications
In article <23260@stealth.acf.nyu.edu> brnstnd@stealth.acf.nyu.edu (Dan Bernstein) writes:
>
>The IETF assigns standard TCP ports between 0 and 255. Eventually that
>range will be full and they'll start assigning higher numbers. If your
>application is sufficiently useful, mature, and documented, ask for a
>number.
>
>Ports 50000 and up are generally reserved for experimental servers.
>

Close - the IAB in the person of the Internet Numbers Czar, Jon Postel
(postel@venera.isi.edu) gives out standard TCP ports.  Jon generally
allocates them if and only if he has in his possession an RFC
documenting the protocol you want to register.

As an alternative, you might want to use the tcp multiplexer service
which uses port 1 to switch between several protocols.

Mike
-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Jan 90 18:41:21 PST
From:      cire|eric <cire@cisco.com>
To:        zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!news@tut.cis.oh, edu@io-state
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Routing on bisected networks

>> From: zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!news@tut.cis.ohio-state.edu  (Roy Smith)
>> Organization: Public Health Research Institute, New York City
>> Subject: Routing on bisected networks
>> 
>> 	What would happen if you had a network with two gateways to the
>> Internet and that network got bisected such that both gateways were still
>> connected to the Internet, but not to each other directly.  For example:
>> 
>> 	Now, imagine that the etherbridge goes down.  Is there any way for
>> host-a to talk to host-b by some route into the Internet and out again?
>> What happens to some machine on the Internet that is talking to host-b
>> through G1.

Nope.  Won't work.  Because your ether has to have the same network number,
both gateways think they are connected to the same cable.  Both Gateways
think this anyway so when you try to communicate across the break (A to B)
neither gateway will respond.

If there is a conversation in progress that traverses the etherbridge it
will abort.  No possible recovery.

>> 	In another scenario, imagine the etherbridge is down and some host-c,
>> out in the Internet somewhere, wants to talk to both host-a and host-b.  Is
>> there any way for it to discover different routes to the two host, using
>> gateway G1 to talk to host-a and gateway G2 to talk to host-b, even though
>> host-a and host-b are on the same IP net?

This situation is even worse.  It may or may not work.  It depends on which
gateway it gets.  There is no way for the gateways to know the network
has partitioned and who is connected to their part.  Think of the implications
on the ARP cache and such.

In other words, this an inferior way to build a network.  *DONT DO IT*  You
won't like it when things go wrong.

We do both routers and bridges.  We also like for folks to avoid problems.

-c
cisco systems
-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Sun, 28 Jan 90 20:35:49 PST
From:      cire|eric <cire@cisco.com>
To:        zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!news@tut.cis.ohio-state
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Routing on bisected networks


>> From: zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!news@tut.cis.ohio-state.edu  (Roy Smith)
>> Organization: Public Health Research Institute, New York City
>> Subject: Routing on bisected networks
>> 
>> 	What would happen if you had a network with two gateways to the
>> Internet and that network got bisected such that both gateways were still
>> connected to the Internet, but not to each other directly.  For example:
>> 
>> 	Now, imagine that the etherbridge goes down.  Is there any way for
>> host-a to talk to host-b by some route into the Internet and out again?
>> What happens to some machine on the Internet that is talking to host-b
>> through G1.

Nope.  Won't work.  Because your ether has to have the same network number,
both gateways think they are connected to the same cable.  Both Gateways
think this anyway so when you try to communicate across the break (A to B)
neither gateway will respond.

If there is a conversation in progress that traverses the etherbridge it
will abort.  No possible recovery.

>> 	In another scenario, imagine the etherbridge is down and some host-c,
>> out in the Internet somewhere, wants to talk to both host-a and host-b.  Is
>> there any way for it to discover different routes to the two host, using
>> gateway G1 to talk to host-a and gateway G2 to talk to host-b, even though
>> host-a and host-b are on the same IP net?

This situation is even worse.  It may or may not work.  It depends on which
gateway it gets.  There is no way for the gateways to know the network
has partitioned and who is connected to their part.  Think of the implications
on the ARP cache and such.

In other words, this an inferior way to build a network.  *DONT DO IT*  You
won't like it when things go wrong.

We do both routers and bridges.  We also like for folks to avoid problems.

-c
cisco systems
-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 90 15:33:31 GMT
From:      Gary_Edmunds_Miller@cup.portal.com
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: networking over X.25

Jim Mercer  writes:
>At our site, we have a 3B2/500 running SysV 3.2.
>We have remote users who access us over X.25 using terminals plugged into
>a PAD at 9600 baud.  The X.25 parameters currently forward packets on CR.
>
>I would like these users to be able to run full screen (ie. curses)
>applications, but the X.25 has too much buffering and won't allow (easily)
>single keys to get through.
>

You should be able to program the PAD to forward single character packets
or on a short timeout.  This may be a bt tricky depending upon whether
your PAD supports the X.28 parameter setting standard.  Worse the X.28
is not exactly user friendly :-(

RGDS
GARY

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jan 90 09:08:48 -0800
From:      "Jim Gillogly" <rand!jim%blaise@isaak.org>
To:        zuse!virus@relay.EU.net
Subject:   Did Morris try to stop the worm?
Geof Cooper said:
> One thing that makes me wonder: A newspaper article claims that Morris
> wanted to stop the worm when it started to get out of control, and
> decided that he wasn't able to.  When the Internet group started to
> try and control it, why didn't he offer to help?

The following message was sent the morning after the network worm started.
My understanding is that it was sent by a friend of Morris.  Checking the
"Received" times suggests that it it didn't arrive in time to do any good.

      Jim Gillogly

 --------- Forwarded message -------------
Received: from SRI-NIC.ARPA by rand.org; Sat, 5 Nov 88 03:20:10 PST
Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Fri, 4 Nov 88 23:23:24 PS
T
Received: from cs.brown.edu by RELAY.CS.NET id aa05627; 3 Nov 88 3:47 EST
Received: from iris.brown.edu (iris.ARPA) by cs.brown.edu (1.2/1.00)
      id AA12595; Thu, 3 Nov 88 03:47:19 est
Received: from  (128.103.1.92) with SMTP via tcp/ip
	by iris.brown.edu on Thu, 3 Nov 88 03:34:46 EST
Message-Id: <8811030834.AA10454@iris.brown.edu>
Date: Thu, 3 Nov 88 03:34:13 EST
From: foo%bar.arpa@RELAY.CS.NET
To: tcp-ip@SRI-NIC.ARPA

A Possible virus report:

There may be a virus loose on the internet.

Here is the gist of a message Igot:

I'm sorry.

Here are some steps to prevent further transmission:

1) don't run fingerd, or fix it to not overrun its stack when reading
arguments.

2) recompile sendmail w/o DEBUG defined

3) don't run rexecd

Hope this helps, but more, I hope it is a hoax.
qui
-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      28 Jan 90 20:26:39 GMT
From:      pacbell!osc!rp@ames.arc.nasa.gov  (Rich Patterson)
To:        tcp-ip@nic.ddn.mil
Subject:   Who are the TCP/IP "port number police" ??
Hi,
	I am trying to find out who to contact to officially register TCP/IP
port numbers.  I would also like to get a current list of port numbers and
their respective owners.  Who or what company would I contact for this
information.  Please e-mail to me directly. Thanks!

Rich Patterson
rp@osc.com
{pacbell,amdcad}!osc!rp		[usenet/uucp]
osc!rp@pacbell.com		[usally works for arpanet]
-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jan 90 10:02:02 -0800
From:      jqj@rt-jqj.Stanford.EDU
To:        cire|eric <cire@cisco.com>
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Routing on bisected networks
Eric Cire replies:
>> 	What would happen if you had a network with two gateways to the
>> Internet and that network got bisected such that both gateways were still
>> connected to the Internet, but not to each other directly.  For example:
>> ... [with an internal] etherbridge [that] goes down.
>>
>Nope.  Won't work.  Because your ether has to have the same network number,
>both gateways think they are connected to the same cable.

Now, however, suppose that instead of an internal Etherbridge you have an
internal router connecting 2 subnets, each of which is connected to the same
regional network in the outside world.  Using traditional IGPs it still won't
work, because the subnet structure of the partitioned network is invisible
outside the network.  But suppose you are using OSPF to route inside your own
network, and also on the regional network.  OSPF can be configured to make
your subnets visible to limited pieces of the routing world outside your own
network, and hence can be configured to allow roundabout routing between
subnets if the internal router fails.

Is this a good idea?  It makes network management and configuration more
difficult, and routing in the regional network somewhat harder to understand
and debug.  It forces the local network to abdicate some control over its own
routing destiny.  But it does provide greater redundancy in some topologies.

I would be very curious to hear what OSPF proponents believe to be "good
engineering practice" given a tool that allows advertisement of arbitrary
subnet routes.  Comments?

JQ Johnson                              voice: 415-723-3078
Manager, Special Projects               Internet: jqj@jessica.stanford.edu
Networking and Communications Systems
Stanford University



-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jan 90 11:15:01 -0800
From:      "Philip Almquist" <almquist@jessica.Stanford.EDU>
To:        pacbell!osc!rp@ames.arc.nasa.gov (Rich Patterson)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Who are the TCP/IP "port number police" ??
Rich,
> I am trying to find out who to contact to officially register TCP/IP
> port numbers.  I would also like to get a current list of port numbers
> and their respective owners...

	You want to read RFC1010, "Assigned Numbers".  It lists all
officially assigned port numbers and also gives the procedure for
obtaining port number assignments.

	Some commonly used protocols do not use officially-assigned port
numbers for various reasons.  Hans-Werner Braun of NSFNET recently
attempted to make a list of these unofficial port numbers.  I seem to
recall it's available via anonymous FTP from MERIT.EDU.

						Philip
-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jan 90 07:47:16 -0500
From:      vcerf@NRI.Reston.VA.US
To:        Dave Bridgham <dab@asylum.sf.ca.us>
Cc:        forster@cisco.com, tcp-ip@nic.ddn.mil, vcerf@NRI.Reston.VA.US
Subject:   Re: billing for use
David,

I expect you are right that behavioral changes would not all be
anticipated. For instance, when the UK was faced with paying for
TCP/IP traffic on X.25 IPSS service, they quickly re-wrote their
email application to do a file transfer rather then using SMTP
because the SMTP took up a lot more packet exchanges than FTP!

Still, I think we need some way to provide feedback on costs
to the users - otherwise we wind up with the tragedy of the commons
problem.

Vint
-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 90 00:18:18 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Re: why IP should pass UID information


The telephone network uses the circuit switched model.  This model has
the advantage as far as accounting is concerned of needing only a beginning
record and ending record to do its accounting.  This is great but note
that the customer pays for the circuit from establishment until the end
regardless of usage.

A packet switched network doesn't have circuits so this model doesn't
appear to work.  A different model is needed.  It must be based on a
packet.  Note this has the advantage to the customer of only accounting
for flows where real work is being done.  Idle time isn't paid for
because there isn't any such thing.  This applies to IP.

If session accounting is desired it would have to be implemented at
the TCP layer.  But I don't see what this would by you as it only has
significance at the end points.  The underlying IP network only sees
datagrams (packets).

-c
cisco

-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 90 02:41:21 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing on bisected networks


>> From: zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!news@tut.cis.ohio-state.edu  (Roy Smith)
>> Organization: Public Health Research Institute, New York City
>> Subject: Routing on bisected networks
>> 
>> 	What would happen if you had a network with two gateways to the
>> Internet and that network got bisected such that both gateways were still
>> connected to the Internet, but not to each other directly.  For example:
>> 
>> 	Now, imagine that the etherbridge goes down.  Is there any way for
>> host-a to talk to host-b by some route into the Internet and out again?
>> What happens to some machine on the Internet that is talking to host-b
>> through G1.

Nope.  Won't work.  Because your ether has to have the same network number,
both gateways think they are connected to the same cable.  Both Gateways
think this anyway so when you try to communicate across the break (A to B)
neither gateway will respond.

If there is a conversation in progress that traverses the etherbridge it
will abort.  No possible recovery.

>> 	In another scenario, imagine the etherbridge is down and some host-c,
>> out in the Internet somewhere, wants to talk to both host-a and host-b.  Is
>> there any way for it to discover different routes to the two host, using
>> gateway G1 to talk to host-a and gateway G2 to talk to host-b, even though
>> host-a and host-b are on the same IP net?

This situation is even worse.  It may or may not work.  It depends on which
gateway it gets.  There is no way for the gateways to know the network
has partitioned and who is connected to their part.  Think of the implications
on the ARP cache and such.

In other words, this an inferior way to build a network.  *DONT DO IT*  You
won't like it when things go wrong.

We do both routers and bridges.  We also like for folks to avoid problems.

-c
cisco systems

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 90 04:35:49 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Re: Routing on bisected networks



>> From: zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!news@tut.cis.ohio-state.edu  (Roy Smith)
>> Organization: Public Health Research Institute, New York City
>> Subject: Routing on bisected networks
>> 
>> 	What would happen if you had a network with two gateways to the
>> Internet and that network got bisected such that both gateways were still
>> connected to the Internet, but not to each other directly.  For example:
>> 
>> 	Now, imagine that the etherbridge goes down.  Is there any way for
>> host-a to talk to host-b by some route into the Internet and out again?
>> What happens to some machine on the Internet that is talking to host-b
>> through G1.

Nope.  Won't work.  Because your ether has to have the same network number,
both gateways think they are connected to the same cable.  Both Gateways
think this anyway so when you try to communicate across the break (A to B)
neither gateway will respond.

If there is a conversation in progress that traverses the etherbridge it
will abort.  No possible recovery.

>> 	In another scenario, imagine the etherbridge is down and some host-c,
>> out in the Internet somewhere, wants to talk to both host-a and host-b.  Is
>> there any way for it to discover different routes to the two host, using
>> gateway G1 to talk to host-a and gateway G2 to talk to host-b, even though
>> host-a and host-b are on the same IP net?

This situation is even worse.  It may or may not work.  It depends on which
gateway it gets.  There is no way for the gateways to know the network
has partitioned and who is connected to their part.  Think of the implications
on the ARP cache and such.

In other words, this an inferior way to build a network.  *DONT DO IT*  You
won't like it when things go wrong.

We do both routers and bridges.  We also like for folks to avoid problems.

-c
cisco systems

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jan 90 12:40:07 PST
From:      ho@la.tis.com (Hilarie K. Orman)
To:        tcp-ip@nic.ddn.mil
Subject:   Racal Interlan TCP/IP for 386 Unix
Recently Mark Towfigh of Racal Interlan posted information about
a TCP/IP product for 386 Unix.  The 800 number he mentioned seems
to open onto an automated message system that captures customer
information and returns nothing, and I have received mailer failure
messages from attempts to contact towfiq@interlan.Interlan.COM.
Has anyone successfully contacted this company?

Hilarie Orman
Trusted Information Systems, Inc.
213-477-5828
-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jan 90 14:48:47 -0500
From:      Dan FitzPatrick <dkf@iec.ufl.edu>
To:        TCP-IP%SRI-NIC.ARPA@nervm.nerdc.ufl.edu
Subject:   Re:  tn3270
Dave,

ucbarpa.berkeley.edu worked.  tn3270 seems to be up and going with
no effort.  Thanks again.

Dan

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jan 90 11:29:35 EST
From:      Avri Doria <avri%interlan.interlan.com@RELAY.CS.NET>
To:        pollux!ccruss@UCDAVIS.UCDAVIS.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   TCP/IP printing protocol
I would be interested in participating in working on an printing svcs
protocol. 

Avri Doria                          avri@interlan.com
Racal InterLan                      interlan!avri@uunet.uu.net 
Boxborough MA, 01719                {sun,ima,mit-eddie}!interlan!avri
TEL: (508) 263-9929                 FAX: (508) 263-8655 or 263-0856


-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jan 90 18:25:12 PST
From:      postel@venera.isi.edu
To:        pacbell!osc!rp@ames.arc.nasa.gov
Cc:        JKRey@venera.isi.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Who are the TCP/IP "port number police" ??

Rich:

To get an assigned port number please contact Joyce Reynolds at JKREY@ISI.EDU.

--jon.
-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jan 90 18:44:21 PST
From:      the terminal of Geoff Goodfellow <geoff@fernwood.mpk.ca.us>
To:        tcp-ip@NIC.DDN.MIL, ietf@isi.edu
Subject:   FYI-- Press Release-FARNet Position Paper & Acceptable Use Guidelines
January 23, 1990 
		
			FOR IMMEDIATE RELEASE			


FOR MORE INFORMATION:
Richard Mandelbaum
(716) 275-2916

San Diego, CA, January 9, 1990 - In a move towards the establishment of a more
coordinated national research and education network environment, the Federation
of American Research Networks (FARNet) has adopted the first in a series of
guidelines, or FARNet Position Papers (FPP). The two documents approved at the
just-concluded San Diego conference address the following: FPP Development and
Approval Process (FPP #1) and Guidelines on Acceptable Use and Connection (FPP
#2). 

	FARNet is an organization currently consisting of twenty-five regional
and state networks, who provide access from local networks to the national
research and education network community (the Internet). The purpose of the
Federation is the advancement of science and education through the aiding of
communication among research and educational organizations. The Federation
endorses the coordination and interconnection of regional and backbone networks
to encourage the formation of a unified network environment, thus providing
enhanced access to scientific and educational resources, both nationally and
internationally. 

	During the past three years, networks serving the needs of research,
education, and science have experienced explosive growth. The growth has
occurred at the campus, local, regional, national, and international levels.
Technical and financial investments by both the public and private sectors have
been considerable. Utilization of these networks has become essential to large
segments of the American research and academic communities, and continues to
grow at a startling rate, over 500% in the last 18 months! Guidelines for the
orderly development and interconnection of these varied facilities are
essential for the integrity of the networks and continued provision of high
quality services to educators, researchers, scholars, and administrators. For
this reason, the FARNet Guidelines on Acceptable Use and Connection were
unanimously approved. 

	In summary, the Guidelines govern inter-regional traffic and recommend
that traffic between the FARnet-Member networks be restricted to research or
academic purposes, or to direct administrative support of such efforts.
(Intra-regional traffic is governed by the guidelines set by each regional.)
The position was adopted because the networks represented by the members of
FARNet are, in many instances, at least partially funded by grants from state
or federal agencies. Activities that are beyond the scope of research or
academia are not considered acceptable. For example, Richard Mandelbaum,
FARNet's Chairperson, summarizes from the Guidelines, "It is not acceptable to
send invoices between two commercial entities on different regional networks
across a national backbone." 

	Future FARNet Position Papers are to include such issues as network
design and engineering, international interaction, commercialization of
services, network management models, value-added services, and methods of more
accurately addressing the information movement needs of researchers, scholars
and educators. (For further information, contact  Richard Mandelbaum (716)
275-2916.) 


-------


FARnet Position Paper #2:



FARNET GUIDELINES ON ACCEPTABLE USE 
AND CONNECTION



1.0 Introduction

During the past three years national regional and local networks have
experienced exponential growth.  The technical and financial commitments
made by the private and public sectors have been varied and
considerable.  Use of these networks is now considered essential by
large segments of the American research and academic communities.  

Mechanisms for management have been ad hoc and inconsistent.  Currently
there are no published guidelines nor an associated method of
adjudication addressing the use of network resources.  Furthermore,
inconsistencies exist among regionals about what is considered
acceptable use of national networks.  Without effective management of
the use of the network, there exists potential for severe economic and
political problems.  Regional networks and the national backbones
receive a considerable amount of federal funding.  This subsidy requires
accountability, a means to demonstrate that the federal funds are being
properly applied.  Given the strategic importance that the networks have
assumed for national research and development, it is vital that the
integrity of the resource be maintained.  


2.0 Intent

The intent of this document is to suggest policies and mechanisms for
determining appropriate use of and connection to networking resources.
The networking environment model is assumed to be a three-tiered
hierarchy consisting of a set of national backbone nets (such as NSFnet
and NSN), campus and corporate networks (such as a campus-wide
university network or a corporate site LAN) and, connecting these
components, mid-level networks that offer sites in states or geographic
regions access to national nets.  It should be noted that mid-level
networks may in turn be made up of several layers of state and regional
networks.  

This document specifically addresses traffic that is exchanged among
mid-level networks that are members of FARnet, whether across a national
backbone or on a publicly subsidized direct regional connection.  It
does not preclude additional requirements that a national backbone might
establish.  This document may also serve as a basis for acceptable use
policies within a mid-level network.  


3.0 Definition of Terms

Appropriate use refers to whether the use of the network is consistent
with the guidelines for each network that the traffic traverses.  This
applies both to standard applications (e.g., electronic mail, file
transfers, and remote login) and nonstandard uses (chat, experimental
protocols, etc) Acceptable connection refers to the specific authority
and terms by which a user accesses the network.  Issues that are
addressed here include restrictions on access (for security purposes),
resale of connectivity, etc.  Acceptable use and acceptable connection,
while related, are separate issues.  It is possible for acceptable
connections to be used for unacceptable use, and for acceptable use to
be performed on an unacceptable connection.  


4.0 Acceptable Use Policy

Given both the volatile nature of the technology employed and the demand
that users make of the network, determining acceptable use is a dynamic
and iterative process.  In evaluating whether a particular use of the
network is appropriate, several factors should be considered:  

   Traffic between mid-levels should be restricted to research or
   academic purposes, or to direct administrative support of such
   efforts.  Organizations whose connection to the internet is sponsored
   by a FRICC agency can use the network in support of the sponsored
   activities.  Traffic whose content is solely commercial is not
   acceptable.  Malicious use is not acceptable.  Use should be
   consistent with guiding ethical statements and accepted community
   standards.  Use of the internet in a manner that precludes or
   significantly hampers the use by others should not be allowed.

Each mid-level network should establish a regional acceptable use policy
that permits, at a minimum, the transit of any traffic that is
acceptable to an attached national backbone.  Mid-level networks may
establish additional requirements as are appropriate to the regional
mission.  

FARnet recommends that each regional accept traffic from other regionals
if the use was determined to be acceptable under these guidelines by the
originating network.  

Decisions made by mid-level networks or backbone providers regarding
specific instances of acceptable and unacceptable use should be widely
circulated to encourage consistency.  FARnet can and will act as a
vehicle for the distribution and maintenance of such information.  Each
mid-level network should designate an individual to participate in the
exchange of this information.  

5.0 Acceptable connection

Mid-level networks should insure that the connections made to them are
consistent with the effective use and protection of a shared resource.
The mid-levels should know what networks are connected and what use is
being made of the network.  Mid-level networks should instruct members
on current guidelines for acceptable use.  Access to the internet should
be protected through the use of prudent security measures.  Unauthorized
connections to the internet should not be permitted.  "Third party"
connections (such as internet access being provided by research parks or
through resale by a mid-level subscriber) should be done only with the
approval of the mid-level networks.  Connections which create routing
patterns that are inconsistent with the effective and shared use of the
network should not be established.  


6.0 Adjudication

Mid-level networks should distribute this statement to member
institutions and request members to inform their communities about these
issues.  

Responsibility for the determination of whether a proposed use of the
network is acceptable begins with the initiating user.  If the user is
uncertain, the associated connecting authority or mid-level should be
contacted.  

Mid-level networks should consult with backbone providers and FARnet as
needed to determine if an intended use of a backbone is consistent with
the policies of the provider.  The results of these deliberations should
be distributed among the mid-level networks to encourage consistent
policy.  FARnet should be active in implementing this process.  

If disagreements arise among mid-level networks concerning their direct
connections, FARnet should attempt to act as a reconciliatory agent.  


7.0 Enforcement

In instances where particular traffic is determined to be an abuse, the
mid-level network that originated the traffic will be held responsible
for both admonishing the perpetrator and preventing further abuse.  It
is assumed that the mid- level network will, in turn, place similar
responsibilities upon its members.  

Mid-level networks should make a good faith effort to enforce the
decisions that emerge from the adjudication process undertaken by
FARnet.  

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      Mon, 29 Jan 90 19:26:04 CST
From:      al322516@mtecv2.mty.itesm.mx (LOZANO A MARIA LUISA)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP Bibliography requested

Hi There!!
 We are a group of students from Monterrey's Institute of Technology
at Monterrey, Mexico.
 Actually we are doing an investigation about TCP/IP and later in the
semester we'll have to develop an operational system running on
Ethernet using TCP/IP.
  Can somebody please tell us where we can find literature that will
fit our needs (basic but not so basic) and if posible a server on
either Internet or BITNET with examples of programs.
  Thanks everybody.
Maria Luisa Lozano-Aranda-Diaz
                                       If you think the
answer will be too elementary for this list you may e-mail to any of
the following accounts:
 Internet:
al322516@mtecv2.mty.itesm.mx (Myself)
al296641@mtecv2.mty.itesm.mx (Antonio Quesada-Duarte)
BITNET:
AL296641@TECMTYVM.BITNET (Antonio Quesada-Duarte)

Thanks everybody!!!!!!!
Maria Luisa Lozano-Aranda-Diaz

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 90 15:38:24 GMT
From:      zaphod.mps.ohio-state.edu!usc!sdsu!ncr-sd!babel!ward@tut.cis.ohio-state.edu  (Ed Ward 2337)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)


I'm looking for some information comparing the Ethernet throughput of the 
AMD lance, Seeq 8005, and Intel 82??? controller chips.  I seem to remember
an article posted quite a while ago by Steven Bellovin, AT&T Bell Labs, 
Murray Hill, in which he posted the results of Van Jacobson's test of the
AMD to Intel throughput.  Unfortunately, I don't have their e-mail addresses
so I was hoping someone in net-land could help me out.  Does anyone have
any data or ideas?? Please e-mail replies or post if the path below
bounces.  Thanx.

 


-------------------------------------------------------------------------------
Ed Ward - GO BUFFS!!                         My Company could care less about
NCR Corporation,  16550 W. Bernardo Dr.      my opinion!!
San Diego, CA 92127 (619) 485-2337           {att,ucsd,hp-sdd}!ncr-sd!babel!ward                           
-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 90 17:19:02 GMT
From:      snorkelwacker!usc!cs.utexas.edu!wuarchive!wupost!dranet!sean@bloom-beacon.mit.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Who is working on NISO/ANSI Z39.50, Search and Retrieval
A few months ago I sent out this message to the tcp-ip list.

> Anyone have the Z39.50 protocol running on top of TCP/IP?
> 
> I'm working on this protocol for a few other network protocol stacks, and 
> and be very interested in how people are going about ensuring interoperability
> when running Z39.50 over TCP/IP.
> 
> Z39.50 is a NISO/ANSI standard for Search and Retrieval (OSI application
> layer) for (mostly?) the library world.

Along with several responses, I received several requests for a summary.

So a summary in my own words:

    Everyone seems to be planning a OSI protocol stack implementation of
Z39.50, but several are also planning on using ISODE from NYSERnet so they
can use the existing TCP/IP Internet.  Asking whether they plan to implement
the protocol over TCP/IP apparently is not the appropriate question.  This
decision seems to be made by other than those implementing the Z39.50
application protocols.  Some are going to use TCP/IP and ISODE because that
is what is available at their institution.  Others are using the full OSI
stack because that is what the grant or the government has said.  Data Research
(the company for which I work) implemented Z39.50 over DECnet (because that is
what our current network is), and is working on OSI (because that is what we
said we would do).  I haven't seen ISODE, so I don't know how easy it would be
to take an OSI application and use ISODE to run it over TCP/IP.

The larger projects I am aware of include work at CMU with Project Mercury
(CMU, OCLC, DEC), and a joint project between University of California, Penn
State, along with Virginia Tech, California State.

Here is a list of institutions that I believe are actively doing IMPLEMENTATION
of the Z39.50 protocol over some type of network.

    California State University
    Carnegie-Mellon University
    Data Research Associates, Inc
    Florida State University
    Library of Congress
    NYSERnet
    OCLC, Inc
    Pennsylvania State University
    RLG
    Thinking Machines Corp
    University of California, Berkeley
    Virginia Polytechnic Institute

I'm sure that there are several others, but I haven't heard about them.
Then again, I may have said that someone was working on it, when in fact
they are not.  For example, I received several messages saying that NYSERnet
was working on Z39.50, but I was unable to confirm this with anyone at NYSERnet.

NOTE:

    If you are working on an IMPLEMENTATION of the Z39.50 protocol I would
strongly suggest that let either Clifford Lynch at University of California,
Division of Library Automation or Patricia Harris, Executive Director of NISO
at the National Institute of Standards and Technology know about you.
If they don't know that you're working on it, they won't be able to let
you know about upcoming plans/events/changes with Z39.50.

Or let me know, and I'll pass your name along to them.
--
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
Domain: sean@dranet.dra.com, Voice: (Work) +1 314-432-1100

  Affiliation given for purposes of identification, not representation
-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 90 18:00:01 GMT
From:      oliveb!orc!oli-stl!asylum!karl@apple.com  (Karl Auerbach)
To:        tcp-ip@nic.ddn.mil
Subject:   I lack the requisite skills?: Was Re: why IP should pass UID information
In article <9001280131.AA25571@world.std.com> bzs@world.std.com (Barry Shein) writes:
>Creating any sort of accounting system for something as large as the
>internet is an immensely complicated endeavor and probably very few
>(if any) of the people discussing this here have the requisite skills
>beyond adding specific advice on what is technologically feasible and
>perhaps a few other wise comments (but not a complete picture.)

Really?  Who was the last person reputed to know everything? Leonardo
Da Vinci?  Roger Bacon?

It seems to me that you are suggesting that one can not go forward
until one knows everything and can propose a perfect solution.  In
other words, the OSI method.

I've spent a good deal of time dealing with some of the matters to
which you allude -- transnational data flow, rights to privacy, etc (I
used to specialize in these matters in my other career as an
attorney.)  But these issues are not insurmountable.  Even anononymous
accounting information can be of enourmous use for network
administrators who need to do capacity planning.

The fact that the telephone companies manage to do this sort of thing
is, to my mind, an existance proof that reasonable, and legal, methods
of accounting and billing are possible.  This leaves the basic
technical matter of gathering the raw data in the first place and
making sure that it is held and transferred with the appropriate level
of security to ensure privacy and auditability.

Of course the accountants and lawyers need to get involved --
eventually (the sooner the better.)  But we, the technologists, are in
a position to take the first steps.  I am not afraid to deal with a
problem simply because I cannot forsee the solution or that the
solution will eventually require the cooperation of people with skills
I lack.

				--karl--
-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      29 Jan 90 23:12:48 GMT
From:      ndsuvm1.bitnet!nu021172@cunyvm.cuny.edu  (Marty Hoag)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Who are the TCP/IP "port number police" ??
In article <1955@osc.COM>, rp@osc.COM (Rich Patterson) says:
>...
>	I am trying to find out who to contact to officially register TCP/IP
>port numbers.  I would also like to get a current list of port numbers and
>their respective owners.  Who or what company would I contact for this
>information.  Please e-mail to me directly. Thanks!
>...

   Here is the first part of RFC1010 which contains the port numbers.
This is a bit old now so there may be an updated version...
RFCs are avialable via anonymous FTP or a mail server from NIC.DDN.MIL
(SRI-NIC.ARPA).  Following the intro is some information on that server.


                            ASSIGNED NUMBERS


Status of this Memo

   This memo is an official status report on the numbers used in
   protocols in the Internet community.  Distribution of this memo is
   unlimited.

Introduction

   This Network Working Group Request for Comments documents the
   currently assigned values from several series of numbers used in
   network protocol implementations.  This RFC will be updated
   periodically, and in any case current information can be obtained
   from Joyce Reynolds.  If you are developing a protocol or application
   that will require the use of a link, socket, port, protocol, etc.,
   please contact Joyce to receive a number assignment.

      Joyce K. Reynolds
      USC - Information Sciences Institute
      4676 Admiralty Way
      Marina del Rey, California  90292-6695

      Phone: (213) 822-1511

      Electronic mail: JKREYNOLDS@ISI.EDU

   ...

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

NIC Mail Services

   This is an automated service provided by the DDN Network Information
Center.  It allows access to NIC documents and information via ordinary
electronic mail.  This is especially useful for people who do not have
access to the NIC via a direct Internet link, such as BITNET, CSNET
and UUCP sites.

   To use the mail service, send a mail message to SERVICE@SRI-NIC.ARPA.
In the SUBJECT field, request the type of service you wish followed by
any needed arguments.  The message body is normally ignored.  Large files
will be broken into smaller separate messages.  The information you
request will be sent back to you as soon as possible.

The following services are currently available:

HELP        This message; a list of current services.
RFC nnn        nnn is the RFC number or the word INDEX.
...
-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Jan 90 16:09:38 -0800
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
To:        jqj@rt-jqj.Stanford.EDU
Cc:        cire|eric <cire@cisco.com>, tcp-ip@NIC.DDN.MIL
Subject:   Re: Routing on bisected networks

JQ, this behavior falls out of the way OSPF implements variable length
subnet support.  It could have restricted this, but that would have 
been restricting something potentially useful.  First off, by proper 
configuration (and this is the default way it works I believe) of
areas, you can ensure all the pieces of a subnet must remain in that
area, as when you cross an area boundary, you would normally collapse all
the subnet routes to network routes.  Note that if this was all that
was supported by OSPF, people who had large Class A networks would
not be able to use multiple areas.  So OSPF allows you to collapse that
subnet information to some mask that isn't the natural mask of the 
network number in use.  So you could form 'class B'ish' clusters of
subnets in areas, and still be able to use the Class A net to wire it
all together.

I should point out that any regional use of this feature could be set up
in a way that would prevent external paths outside an area healing the 
partition.  Just use a seperate area for the campus, and don't allow
an non-natural mask collapse to occur.  OSPF however does not allow 
subnet information to come inside from external to the AS, so a regionals
subnet partition won't be healed from outside the system, though of course
the usual things to reconstitute network reachability could work.  

Also note that OSPF has a trust model built in to it.  Intra-area routes
can never be overridden by inter-area routes, which in turn cannot be overridden
by external routes.  Thus if a subnet is reachable by some internal 
path, there is no way for someone outside the area to override it.  So
it's not quite as bad as you think.

Also note that there is no reason why the campus and the regional should
HAVE to run a common IGP.  It has it's advantages and it's disadvantages.
I certainly don't see a reason why a campus shouldn't be it's own area.
It can run it's own authentication scheme, seperate from what
authentication scheme the backbone supports.  Remember that OSPF supports
authentication too, and most people will want to use this capability.

I should point out that people have been screaming for a routing
protocol that supports variable length masks for some time.  A common
case is a site with a large bridged backbone with lots of hosts on it,
and several small subnets hung off of it supporting office automation
groups, clusters of workstations, appletalk nonsense, etc...  So the
IETF built a protocol that did!  We do listen you know!

BTW, I don't think it's really a network management issue, it's just that
us oldtimers don't normally think about things like this working.  All
it takes is some people adjustment.  :-)  It's been my experience 
that most people love having new capabilities, even if they have to
go find some nails to try them out on...  

					Thanks,
					   Milo

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 90 03:03:17 GMT
From:      ogicse!caesar.cs.montana.edu!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!asuvax!anasaz!duane@decwrl.dec.com  (Duane Morse)
To:        tcp-ip@nic.ddn.mil
Subject:   rsh vs remsh -- how does one handle the name conflict?
Our Release 3 of Unix for System V on the Tower 32/600 doesn't come with a
TCP/IP 'rsh' -- NCR already used the name for their restricted shell. Instead,
the remote shell is called remsh. This causes problems, as you might
imagine, when one tries to do a remote shell command on a non-NCR
machine with the NCR Tower as the target. Is there a way to handle
this cleanly? Do remote shells care what they are called (i.e., will
renaming remsh on the Tower and getting rid of the existing rsh or
renaming it be likely to work)?
-- 

Duane Morse	e-mail: duane@anasaz (or ... asuvax!anasaz!duane)
(602) 861-7609
-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 90 03:41:29 GMT
From:      stealth.acf.nyu.edu!brnstnd@nyu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Maximum Entropy Routing
In article <9001261201.AA05997@umd5.UMD.EDU> schulman@UMD5.UMD.EDU (Leisure Suit Marty) writes:
> About a month ago, some posts to this list mentioned "maximum entropy
> routing".  Could someone please provide a pointer to on-line or off-line
> references to this topic?  Thanks.

That was me... Try NYU CSD Technical Report 371: ``Some Comments on
Highly Dynamic Network Routing,'' by Herbert J. Bernstein, May 1988.
(Yes, there's a relation.)

---Dan
-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Jan 90 10:17:21 EST
From:      "Virus Discussion List" <isaak!VIRUS-L%LEHIIBM1@relay.EU.net>, "The Moderator Kenneth R. van Wyk" <krvw%SEI@isaak.CMU.EDU>
To:        Ullwer%ds0iff5.bitnet@relay.EU.net (Christof Ullwer)
Subject:   VIRUS-L Digest V3 #25
VIRUS-L Digest   Tuesday, 30 Jan 1990    Volume 3 : Issue 25

Today's Topics:

PC Magazine Free Utility: PCDATA (PC)
ADAPSO Virus Book
Security and Internet Worms (Source Code)
Article on Cliff Stoll
Did Morris try to stop the worm?
Yet Another WDEF Infection (Mac)
VAX Virus request and UMNEWS (general)
Yankee Doodle Virus
Prophylactic anti-viral suggestion
Possible new virus?? NUCLEUR WAR.
Universal virus detectors
Re: Virus request
Re: Virus request
Re: WDEF at University of Rochester (Mac)
re: 'Virus request' from Taiwan
WDEF Infection (Mac)

VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed.  Contributions should be relevant, concise,
polite, etc., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's
LEHIIBM1.BITNET for BITNET folks).  Information on accessing
anti-virus, document, and back-issue archives is distributed
periodically on the list.  Administrative mail (comments, suggestions,
and so forth) should be sent to me at: krvw@SEI.CMU.EDU.
 - Ken van Wyk

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

Date:    25 Jan 90 11:53:00 -0500
From:    "zmudzinski, thomas" <zmudzinskit@imo-uvax.arpa>
Subject: PC Magazine Free Utility: PCDATA (PC)

PC Magazine, Vol 9 No 3, February 13, 1990, pp. 263-283, contains an
article by Wolfgang Stiller, "Protect Your Data with PCDATA, the Data
Integrity Toolkit".  Stiller has put together an impressive array of
eight (8) programs and nineteen (19) BAT files designed "to detect and
recover from all data integrity threats, including viruses".  This
toolkit is available "free" (i.e. no-fee bannerware) from "PC MagNet"
on CompuServe.  (Buy the magazine to get the documentation.)

Would one or more of our virus gurus please download these utilities
and try them out?  I'm sure we'd all like to know how these stand up
to various viruses.

/s/ Tom Zmudzinski                      Standard Disclaimer:
    DCS Data Systems                   "Shill for these people?
    McLean, Virginia                    Heck, I don't even know them!"

TomZ @ IMO-UVAX.DCA.MIL

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

Date:    Mon, 29 Jan 90 10:58:50 -0500
From:    Gene Spafford <spaf@cs.purdue.edu>
Subject: ADAPSO Virus Book

"Computer Viruses: Dealing with Electronic Vandalism and Programmed
Threats" by Eugene Spafford, Kathleen Heaphy, and David Ferbrache.
1989, 109 pages.  Published by ADAPSO.

The book has been written to be an accessible resource guide for
computer users and managers (PC and mainframe).  It presents a
high-level discussion of computer viruses, explaining how they work,
who writes them, and what they do.  It is not intended to serve as a
technical reference on viruses, both because the audience for such a
work would be limited, and because such a reference might serve to aid
potential virus authors.

The goal of the book is to dispell some common myths about viruses
(and worms, trojan horses, et. al.), and provide simple, effective
suggestions for how to protect computer systems against these threats.
It furthermore stresses that most systems face greater threats from
other areas, so the proper attitude to take is to strengthen overall
security; concrete suggestions for enhancing overall security are also
presented.

The appendices provide extensive references to other publications,
security organizations, anti-viral software sources, applicable (U.S.)
state and Federal laws against computer crime, and detailed
descriptions of all IBM and Apple Macintosh viruses known as of 1
October 1990.

Although written for ADAPSO members, almost any computer user should
find it instructive.  The appendices are an excellent source of
further information, addresses and phone numbers, and pointers to
software.  At least one university professor has indicated he will use
the book in a security course, and some law enforcement agencies are
also considering using the book for instructional purposes.

The authors are interested in comments and feedback about the book,
especially in areas where information might be added.  You can contact
them by sending mail to "virus-book@cs.purdue.edu"

Table of Contents:
  Preface
  Executive Summary
  Introduction
  Programmed Threats
    Definitions
    Damage
    Authors
    Entry
    Summary
  What is a Computer Virus?
    Names
    A History Lesson
    Formal Structure
    How do viruses spread?
    The three stages of a virus's life
    Replication strategies
    Recognizing a viral infection
  Dealing with Viruses
    Prevention
    Detection of a viral infection
    Recovery
    Summary
  Security
    A definition of security
    Security as a goal
    Risk assessment
    Some General Approaches
    Summary
  Legal Issues
    Criminal laws
    Civil suits
    Summary
  Attitudes
  Further Information on Viruses
    Characteristic lengths
    Names of Known Viruses
    Known IBM PC viruses by Characteristics
    Known Apple Macintosh Viruses
    Characteristic resources for Mac viruses
  Information on Anti-Viral Software
    Selected reviews of Anti-viral Software
    Easily obtained software
    Internet Archives
    Other Places to Look
  Further Information on Legal Aspects of Viruses
    Federal Laws
    State Laws
    Other Sources of Information
  Further Reading and Resources
    Organizations and Associations
    Government Agencies
    Journals and Newsletters
    Other Readings

A copy can be ordered from
      ADAPSO
      1300 North Seventeenth St.
      Suite 300
      Arlington, VA 22209  USA
      Attn: Mr. John Gracza

Single copies are $30.  Copies ordered on university stationary or on
stationary of ADAPSO member companies is only $20, and $16 for the
second and subsequent copies.

Requests for review copies or special considerations should be
addressed directly to John Gracza.  Copies have been given away to
ADAPSO member companies, and various state and Federal law enforcement
agencies, so check with others in your organization to see if a copy
isn't already available for review.

Overseas orders will be shipped surface mail.  Overseas orders that
are to be shipped air mail should include an additional $10 for
postage.

All payment should be in US dollars, no cash or stamps.


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

Date:    29 Jan 90 13:24:00 -0400
From:    "Andrew D'Uva" <aduva@guvax.georgetown.edu>
Subject: Security and Internet Worms (Source Code)

It seems that the information revolution has brought with it great
problems.  These vast interconnected networks and systems now allow us
to transfer data and programs quickly and at little cost.  The problem
lies in the fact that their level of integration opens them to
infection by worms and trojen horses.  We have even had people ask for
source code for these programs!  Is the solution, as Don Ingli wrote,
to set up some form of reporting mechanism to track these requests?

Sadly, I believe it is.  In the United States a certain level of
privacy has been granted as a constitutional right.  That privacy,
however, is not given rights status when it may be demonstrated to
contravene the public good.  In the case of willful and malicious
network destruction/overload/etc, we can only hope that the network
authorities will take pains to trace these people.  The problem, as I
see it, is that no unified network authority exists.  We can hardly
expect to fight the problem without a centralized "clearing house" for
virus information.  This list serves as one such clearing house.

However--we still have not (as far as I know) set up a worldwide
security group dedicated to addressing problems like these.  Internet
is so large that this would be hard to do.

Yes, I believe that viral source code ought to be distributed and
studied-but under controlled conditions.  The universities offer the
best hope of such a controlled setting.  These problems must be
addressed.  If, as we do in national security issues/clearances, the
focus remains on preventing the outflow of information we risk losing
these battles.

-
 -------------------------------------------------------------------------------
- -
Andrew D'Uva
Georgetown University
Washington, D.C.
   Internet: ADUVA@GUVAX.GEORGETOWN.EDU or 76106.3120@CompuServe.COM
   Bitnet  : ADUVA@GUVAX
 CompuServe: 76106,3120

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

Date:    29 Jan 90 21:50:16 +0000
From:    mel@milton.u.washington.edu (Mary Ellen Lee)
Subject: Article on Cliff Stoll

I hope someone will correct me if there's a better newsgroup for this:

The February issue of Smithsonian magazine has a breezy little article
on Cliff (Cuckoo's Egg) Stoll. Nice coverage of the man, the book, and
the "popularization" of computers in general. It's on page 20.

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

Date:    Mon, 29 Jan 90 09:08:48 -0800
From:    Jim Gillogly <jim%blaise@rand.org>
Subject: Did Morris try to stop the worm?

Geof Cooper said:
> One thing that makes me wonder: A newspaper article claims that Morris
> wanted to stop the worm when it started to get out of control, and
> decided that he wasn't able to.  When the Internet group started to
> try and control it, why didn't he offer to help?

The following message was sent the morning after the network worm started.
My understanding is that it was sent by a friend of Morris.  Checking the
"Received" times suggests that it it didn't arrive in time to do any good.

      Jim Gillogly

 --------- Forwarded message -------------
Received: from SRI-NIC.ARPA by rand.org; Sat, 5 Nov 88 03:20:10 PST
Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Fri, 4 Nov 88 23:23:24 PS
T
Received: from cs.brown.edu by RELAY.CS.NET id aa05627; 3 Nov 88 3:47 EST
Received: from iris.brown.edu (iris.ARPA) by cs.brown.edu (1.2/1.00)
      id AA12595; Thu, 3 Nov 88 03:47:19 est
Received: from  (128.103.1.92) with SMTP via tcp/ip
	by iris.brown.edu on Thu, 3 Nov 88 03:34:46 EST
Message-Id: <8811030834.AA10454@iris.brown.edu>
Date: Thu, 3 Nov 88 03:34:13 EST
From: foo%bar.arpa@RELAY.CS.NET
To: tcp-ip@SRI-NIC.ARPA

A Possible virus report:

There may be a virus loose on the internet.

Here is the gist of a message Igot:

I'm sorry.

Here are some steps to prevent further transmission:

1) don't run fingerd, or fix it to not overrun its stack when reading
arguments.

2) recompile sendmail w/o DEBUG defined

3) don't run rexecd

Hope this helps, but more, I hope it is a hoax.
qui

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

Date:    Mon, 29 Jan 90 13:01:38 -0500
From:    "Gregory E. Gilbert" <C0195@UNIVSCVM.BITNET>
Subject: Yet Another WDEF Infection (Mac)

WDEF A has made it to The University of South Carolina.  So far I have
only seen one person who has been infected.  I am sure their will be more.

If anyone has any ideas how to control it in our Microlabs I would
appreciate hearing from them (any other experiences too.)  Thanks and
happy hunting.

Greg

Postal address: Gregory E. Gilbert
		Computer Services Division
		University of South Carolina
		Columbia, South Carolina   USA   29208
		(803) 777-6015
Acknowledge-To: <C0195@UNIVSCVM>

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

Date:    Mon, 29 Jan 90 18:24:57 -0500
From:    V2002A@TEMPLEVM.BITNET
Subject: VAX Virus request and UMNEWS (general)

Hi,

     Having been a UMNEWS user for 2+ years, I thought that VIRUS-L
should know that ALL users of UMNEWS are required to register by E-MAIL
in order to use the service.  When a new user issues the REGISTER
command the first time, they are sent a copy of the policy for using
UMNEWS.

     The policy states explicitly that illegal and unethical use
of UMNEWS will not be tolerated.  It also states that in registering,
the user has read and understood the policy document.

     Clearly the request for a VAX virus was in direct violation of
the UMNEWS policy and the requestor stands a good chance of losing
all access to UMNEWS.

     The policy document is available from UMNEWS@MAINE on bitnet.
The file name is UMBB POLICY

		       Andy Wing
		       Senior Analyst
		       Temple University School of Medicine

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

Date:    Mon, 29 Jan 90 17:06:20 -0400
From:    "Ghassan N. Alkhoja" <ALKHOJA@GWUVM.BITNET>
Subject: Yankee Doodle Virus

To all Virus experts,

Does anyone out there have any experience with the Yankee Doodle virus.
One of the departments on-campus here at GWU is infected with that virus.
I would appreciate all help that you can provide. Thank you.

Ghassan N. Alkhoja
Sr. Programmer/Analyst
Computer Information and Resource Center
The George Washington University

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

Date:    29 Jan 90 19:19:22 +0000
From:    G.Toal@edinburgh.ac.uk
Subject: Prophylactic anti-viral suggestion

Dear net friends,

   here is a suggestion which may help protect against trojans and viruses --
I haven't seen it mentioned on virus-l (although I've only been reading
it since the start of the Aids scare - the first time I've been personally
affected by viruses) so if I'm repeating an old idea please forgive me.

   I use a computer made in the UK called the Acorn Archimedes -- it is a
proprietary RISC cpu, but I can use it with MSDOS programs because it comes
with a pretty good MSDOS emulator: a combination of a CPU emulator, device
emulator, and operating system emulator. (The device emulator attempts to
pass low-level calls like disk i/o through to the Archimedes' disk controller,
the MSDOS emulator runs an emulated ROM but also passes some BDOS commands
through to the host filing system -- for instance, drive F: could come off
a network drive in Archimedes format, not MSDOS.  [The various parts
of the emulation are all implemented in software, I should make clear...]

   It occurred to me that a similar program could be run on a *genuine*
MSDOS machine in order to provide a safety wrapper around any programs
which were run on that machine.  (Ie it would still be an emulator, but
it would have a head-start in performance because the emulated CPU &
the real CPU were very similar :-) )

   This 'emulator' (I'll call it a 'CPU condom' from now on) would therefore
be able to guarantee that any memory access only came from emulated memory --
no program would be able to muck around with real memory.  It would only allow
access to the devices which the user chose to allow (eg, clock - yes,
disk controller - no); and it would trap all higher-level BDOS/BIOS calls
in order to ask the user (say by switching to an alternate screen display
and back again) whether he/she wanted to allow any particular file to
be written to.

   The CPU condom would probably not be able to allow a full 640K to
the running program - I don't know - that's for MSDOS experts to work out.
With a program like this, you would be able to run any unknown code
with complete confidence.  It could be parameterized so that particular
programs being run always were allowed to write only to specific directories,
to save users having to say 'yes' or 'no' every time a file was being
written.

   Unfortunately, I don't have the expertise to write this myself, (I
know very little of MSDOS or 808X's and really don't want to waste brain-cells
learning it ;-) )  but the readership of this list is sufficiently wide
that writing such a system may appeal to someone.

Over & out,
  regards,
    Graham Toal   <gtoal@ed.ac.uk>

PS If written portably, an MSDOS emulator which did solely file I/O
and screen/keyboard I/O would be usable on other systems -- especially
useful for things like unpacking self-extracting .exe files on unix
mainframes -- almost impossible otherwise.  (I have countless numbers
of archive unpackers on our local Unix machine to save telephone
bandwidth when I fetch something from a server and discover I only
want 15% of the archive it came in!)

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

Date:    30 Jan 90 01:03:10 +0000
From:    munnari!dbrmelb.oz.au!steveo@dbrmelb.dbrhi.OZ (Stephen Oakes)
Subject: Possible new virus?? NUCLEUR WAR.

A Friend Of A Friend had this happen on his XT upon booting from the
Hard Disc.  A message appeared saying something like:

"    Welcome Home !!!!
     I have had a good rest, have you?

     Now, lets get down to business.

     Do you want ...  THERMO NUCLEUR WAR!

     Press any Key to continue.
"

(I'm not sure if "NUCLEAR" was originally mispelt, or copied down
incorrectly)

The FOAF immediately switched his computer off, and is now preparing
to reformat his Hard disc.  If this is a virus, it probably came form
games software which the FOAF copied from A Friend.  I know nothing
about where the FOAFOAF gets his software.

    Anyone know anything about this one?

Stephen Oakes : steveo@dbrmelb.dbrhi.oz

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

Date:    Mon, 29 Jan 90 23:34:00 -0500
From:    Leichter-Jerry@CS.YALE.EDU
Subject: Universal virus detectors

All this debate about whether virus detection is equivalent to the
halting problem, whether real CPU's are best modeled and FSA's or
Turing machines, and so on, is interesting but in a deep sense
completely irrelevant.

With simple hardware support, one can design a system in which all
viruses are trivial detectable.

	Technique:  The hardware will maintain, in both memory and
	on disk, an "is executable code flag".  For practicality,
	assume this is done on a block-by-block basis say in units
	of a K.

	The hardware enforces the following rules:

	1.  Any attempt to execute code from a memory block which
	is not marked executable fails.

	2.  The only way to write into a block of memory that is
	marked executable is from a disk block marked executable.

	3.  Any attempt to write to a disk block marked executable
	fails.  (To write to such a block, the executable flag must
	first be cleared.)

	4.  Any disk block can be marked executable at any time.

	Memory blocks are marked executable only by reading execu-
	table disk blocks into them.

	5.  Associated with every disk block is a time stamp.  When
	a block is marked executable, the hardware updates its time-
	stamp.

	6.  The system comes with physical ROM blocks, marked exe-
	cutable, which contain at least the code needed to display
	the timestamps on all executable blocks.

One could obviously come up with a simpler system - e.g., just keep a
timestamp on EVERY block - but this one is close to practical.  The
sticky spot is 4, which makes it impossible to build executable code
without going through the disk.  Building disk caches for such a
system would also be a complex undertaking.  On the other hand, the
rules are so simple that one could attain a very high degree of
confidence that the hardware was enforcing them correctly.

Why does this work, despite all the proofs?  (Note that it works just
fine even if the disk is assumed to be infinite, in which case the
machine is a Turing machine.  If you are worried about the theoretical
problem of repeated time-stamps - just use variable-length
time-stamps, which are no problem on an infinite disk.)  It works
because none of the standard models have anything that corresponds to
the timestamp: Memory that can be written by the system, but not by
externally-controllable code within the system.

							-- Jerry

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

Date:    30 Jan 90 04:45:11 +0000
From:    annala%neuro.usc.edu@usc.edu (A J Annala)
Subject: Re: Virus request

>> >        Dose anyone have a idea about VAX Virus? Or interesting on
>> >        it? I think the most difficult point is how to spread it
>> >        out. So if someone has any bright idea, contact with me.
>
>What as a whole can the computer industry do to help prevent individuals
>like this from the potential releasing of these viruses(viri?) into the
>vast networks??  Should it be illegal to own or transmit virus source
>(for non-security personnel)??  Also, should there be an international
>watchdog agency set up to investigate such requests??  Should the
>CIA/FBI/FCC be involved in cooperation with IBM/DEC/AT&T/etc.. to form a
>task force along with our list's virus expert?  Has anyone contacted this
>person's administration along with MAINE's and BITNIC/BITNET administration?
>Right now, its up to us to report these requests and its the responsibility
>of MAINE to act on requests submitted via UMNEWS.
>
>Can we make it illegal to have virus sources without stomping on our
>constitutional rights??  What about other countries??
>
>Obviously this particular Taiwanese knows little about VAX networking and
>uses of viruses(worms) in those networking facilities.

There are people who write computer programs (including viruses) and there
are people who only use computer programs (including viruses).  It would
appear that the originator of the request for a VAX Virus is a member of
the latter group.  While it is rather amusing that the requestor could be
so terribly naive as to post his note to a public newsgroup, I seriously
doubt he would be sufficiently competent to introduce a virus into DECNET,
SNA, TCP based networks.  Calling out the computer gestapo in this case may
seem a little heavy handed.  Perhaps someone would consider sending him a
friendly note explaining the damaging potential of actually introducing one
of the responses to his request into a live computer network.  One might be
tempted to highlight the potential administrative/regulatory response to the
actual use of the information gleaned from his request.

NO.  One cannot forbid the possession of sources, linkable objects, or even
executables for a virus without doing fundamental harm to the Bill of Rights.
Viruses may be an unpopular idea ... but the protection of the right of the
individual to free expression of his ideas ... and the right to share those
ideas with other people is fundamental to the concept of a free society.  If
one encroaches on the fundamental right of free speech (including writing)
then one does fundamental damage to our constitutional guarantees.  Moreover,
even if you would allow such a prohibition in spite of it's constitutional
implications, the regulation would most likely be unenforceably broad.  It
would be all but impossible to distinguish the program category "virus" from
other less virulent programs.  Let's keep to prosecuting harmful use of such
material rather than mere possession of unpopular ideas.

AJ

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

Date:    30 Jan 90 06:34:49 +0000
From:    khijol!erc@cs.utexas.edu (Ed Carp, aka Mr. Ed the talking horse...)
Subject: Re: Virus request

woodb!scsmo1!don@cs.UMD.EDU writes:

>He will probably get a few replies as well as some sources. What as a
>whole can the computer industry do to help prevent individuals like
>this from the potential releasing of these viruses(viri?) into the
>vast networks??

 Not a whole lot, except to take reasonable security precautions.

>Should it be illegal to own or transmit virus source (for non-security
>personnel)??

 No.  How would you define the term "security personnel"?  I can write
a virus with a little effort.  Does this make me a criminal?  Of
course not!  Similarly, I have a complete set of lockpicking tools.
Does this make me a criminal?  Again, the answer is no.  It's not the
tool, it's the use of the tool.  Remember, you can design a workable
atomic bomb from documents that you can find at most any large public
library.  Why should it be different for anything else?  Let's not get
swept up in this anti-virus hysteria -- let's see some reason.

>Also, should there be an international watchdog agency set up to
>investigate such requests??  Should the CIA/FBI/FCC be involved in
>cooperation with IBM/DEC/AT&T/etc.. to form a task force along with
>our list's virus expert?

I think this is going a bit overboard.  Sounds like paranoid hysteria.

>Has anyone contacted this person's administration along with MAINE's
>and BITNIC/BITNET administration?

>Right now, its up to us to report these requests and its the
>responsibility of MAINE to act on requests submitted via UMNEWS.

 Really?  Who appointed "us" net.police?  Or net.censor?

>Can we make it illegal to have virus sources without stomping on our
>constitutional rights??  What about other countries??

 I doubt it.

Right after the Internet virus was released, I saw several postings
requesting source for the virus.  Sure, there were probably net.idiots
who wanted to take the source, hack it up, and re-release it, but
there were obviously sincere, rational investigators who wanted to
investigate the virus, tear it apart, figure out just how it worked,
and then build a better virus-catcher.  There are people who are out
there who make money by doing this sort of thing.  Are you suggesting
that the people who have already become established (known) in the
field have some sort of exclusive on source?  Who appointed Gene
Spafford the net.virus.god?  This is NOT a flame against Gene, but I
have a dim view of folks who want to set up Gene and others like him
on a pedestal.  I respect Gene's abilities in his field, but there are
lots of programmers who can do the same thing.

If someone wants to write a virus, he can sure do it without having
access to source.  Who's going to judge?  If I ask for source (hey,
Gene, can you mail me the latest source to the Internet virus?), does
that make me automatically suspect?  Am I a "bad guy"?  I could forge
my mail address, looking like I come from IBM's Virus Research Group
(thinking about it, I don't really *need* to forge THAT), send Gene a
request, then, when I get the source, use it for my own nefarious
purposes.  Alternately, I could be doing genuine virus research for
defending AIX against viruses.  There IS such work going on, you know.

I could even be legit.  I sub-contract for IBM.  This gives me access
to IBM's facilities, phones, etc.  I could pose as a virus research
(or even BE a virus researcher), get the source, and do whatever.

Just because one is a "security expert" doesn't make them a "good guy"; just
because one isn't doesn't make them a "bad guy".
- --
Ed Carp                 N7EKG/5 (28.3-28.5)     uunet!cs.utexas.edu!khijol!erc
Austin, Texas           (512) 832-5884          "Good tea.  Nice house." - Worf
"Love in any language, fluently spoken here"             -- sung by Sandi Patti

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

Date:    30 Jan 90 05:22:52 +0000
From:    wcpl_ltd@uhura.cc.rochester.edu (Wing Leung)
Subject: Re: WDEF at University of Rochester (Mac)

      WDEF B is found in University of Rochester.  Tonight I've found
one of my disk crash due to a problem in the Desktop file.  After recovering
it at the Computer Center, we use Disinfectant 1.5 to scan the Desktop file
and WDEF B is found.  My friend use it to scan his disks too.  The earliest
infection found so far is on 22nd Jan.

Peter

  _    _  ____        ____   _        * Internet:     wcpl_ltd@uhura.cc.rochester.edu
 (/   /  //  / //   ) (/              * BITNET  :     WCPL_LTD@UORDBV
 / / /  //    //___/ _/               * DecNet  :     UORHEP::PETER
/_/_/  //__/ //           _/\___/     * UUCP    :     ...rochester!uhura!wcpl_ltd

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

Date:    Tue, 30 Jan 90 11:54:32 +0000
From:    "Dr. A. Wood" <XPUM01@prime-a.central-services.umist.ac.uk>
Subject: re: 'Virus request' from Taiwan

......Re this message:-
From:  IN%"UMNEWS@MAINE.BITNET"  "Vax discussion" 21-JAN-1990 23:11:59.77
Subj:  <Vax 85> Virus on VAX
From: 7811100@TWNCTU01.BITNET

Hi! Does anyone have a idea about VAX Virus? Or interesting on it? I
think the most difficult point is how to spread it out. So if someone
has any bright idea, contact with me. James Huang

......and this reply to it:-
Date:    Thu, 25 Jan 90 12:08:35 -0500
From:    woodb!scsmo1!don@cs.UMD.EDU
Subject: RE: Virus request

Here is a message from UMNews's Vax discussion list. I thought the
list should know about this. The node is Taiwanese.  This is insane.
Obviously this particular Taiwanese knows little about VAX networking
and uses of viruses (worms) in those networking facilities. He will
probably get a few replies as well as some sources. What as a whole
can the computer industry do to help prevent individuals like this
from the potential releasing of these viruses into the vast networks??
Should it be illegal to own or transmit virus source (for non-security
personnel)?? Also, should there be an international watchdog agency
set up to investigate such requests?? Should the CIA/FBI/FCC be
involved in cooperation with IBM/DEC/AT&T/etc.. to form a task force
along with our list's virus expert? Has anyone contacted this person's
administration along with MAINE's and BITNIC/BITNET administration?
<etc etc>
.............................................................................

If James Huang is Taiwanese, then his first and most familiar language
is likely not English but Chinese, and likely he committed no computer
ethical error but merely a language blunder, namely the common capital
offence of 'unclear use of a pronoun'!  <WOODB!SCSMO1!DON@CS.UMD.EDU>,
in the course of emptying his  flamethrower down the  computer link at
the  unfortunate Huang, seems to   imply that Huang   meant "I want to
spread VAX virus".  But Huang could also have intended to say  "I want
to spread news about how to notice and combat VAX virus"

- - which is what Virus-L is for!!
{A.Appleyard} (email: APPLEYARD@UK.AC.UMIST), Tue, 30 Jan 90 11:25:08 GMT

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

Date:    Tue, 30 Jan 90 08:18:29 -0500
From:    Jim Ennis <JIM@UCF1VM.BITNET>
Subject: WDEF Infection (Mac)

Hello,

  We had a WDEF infection of our Mac lab at the University of Central
Florida.  The person fixing the viruses traced the source back to a
local copy center which has some Mac for use on a hourly basis and
students brought their infected disks from the store to our Mac lab.
The person who kills viruses for us has cleaned up the Macs in our
lab.

 -----------------------------------------------------------------------------
 Jim Ennis
 UCF - Computer Services
 JIM@UCF1VM.BITNET

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

End of VIRUS-L Digest
*********************
-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Jan 90 21:40:45 -0800
From:      sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz)
To:        DOUG%YSUB.BITNET@CORNELLC.cit.cornell.edu, TCP-IP@NIC.DDN.MIL
Cc:        <BOB%YSUB@WLV.IMSD.CONTEL.COM>, ysub.cornell."Bob@bitnet, ysub.cornell:Quigley"%bitnet@WLV.IMSD.CONTEL.COM
Subject:   Re:  rsh vs remsh -- how does one handle the name conflict?
> From: "Doug Sewell" <DOUG%YSUB.BITNET@CORNELLC.cit.cornell.edu>
> 'rsh' has been the name of the 'restricted shell' for Unix systems
> for as long as I've worked with them, but this has mostly been SysV
> environments.  On our UTS system, '/bin/rsh' is a link to '/bin/sh'.

	that's funny - on all the systems I've worked with, 'rsh'
	insists on a hostname (and possibly a "-l username" as well).
	but, then, i've (luckily?) not had to work on System V... ;-)

	Steven
-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Jan 90 14:49:42 EST
From:      "Doug Sewell" <DOUG%YSUB.BITNET@CORNELLC.cit.cornell.edu>
To:        TCP-IP@SRI-NIC.ARPA
Cc:        "Bob Quigley" <BOB@YSUB>
Subject:   rsh vs remsh -- how does one handle the name conflict?
'rsh' has been the name of the 'restricted shell' for Unix systems
for as long as I've worked with them, but this has mostly been SysV
environments.  On our UTS system, '/bin/rsh' is a link to '/bin/sh'.

On our Encore (4.2-based) system, there is no '/bin/rsh'.  If I enter
'rsh' on the Encore, it wants to know what host to use.

So, I'd conclude rsh (remote shell) is a Berkeleyism, and rsh (restricted
shell) is a ATTism.

Could you reorder your path ?  That would allow you to rename 'remsh'
to 'rsh'.  If a user truly is to be restricted, you would specify
the full  path-name for /bin/rsh, and they couldn't change their path
or directory anyway (some of the 'rsh' restrictions) to circumvent it.

Doug Sewell (DOUG@YSUB.BITNET), Tech Support, Computer Center,
Youngstown State University, Youngstown,  OH 44555
>> Love it or hate it, your body is yours for life.
-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 90 13:13:51 GMT
From:      donegan@stanton.UUCP (Steven P. Donegan)
To:        comp.protocols.misc,comp.protocols.tcp-ip,comp.protocols.nfs
Subject:   Re: networking over X.25

If your PAD supports the SET command for manipulating PAD parameters this
should set you up for a .1 second forward rate:

SET 4:1

You may need to work with parameters 2 and 15 (echo and editing) to fine tune
the PAD for CURSES.
-- 
Steven P. Donegan (stanton!donegan)
Sr. Network Design Engineer 
Corporate Telecommunications Services
Western Digital Corporation
The opinions expressed here are mine, not Western Digital's.

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      Tue, 30 Jan 90 12:41:16 SET
From:      Dave Stafford <ESC1814%ESOC.BITNET@CUNYVM.CUNY.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Network Records

Having implemented a Wide and Local Area network based on TCP/IP (and other
protocols) I've now run up against a administrative problem.

I have a Class B number split into 8 bit subnets and distributed throughout
Europe at several European Space Agency Sites. There are numerous ethernet
and token-rings LANs at each site, and a multitude of system administrators.

Now my problem is that there seems to be all manner of tools for designing,
monitoring etc. these networks, but none for administering them.

Eg. I want a database product for tracking the allocation of the subnet numbers
and also host numbers on the individual subnets. This needs to be a distributed
system so that records may be maintained at different sites, yet queries should
be possible from any site. Perhaps some automated tracking system and
allocation procedure would also be useful.

Does anyone know of such a product?

Dave Stafford
European Space Operations Centre
Robert Bosch Strasse 5,
Darmstadt, West Germany
Tel (49) 6151 886 907
Fax (49) 6151 886 908
-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 90 13:53:53 GMT
From:      snorkelwacker!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!trn@BLOOM-BEACON.MIT.EDU  (Tony Nardo)
To:        tcp-ip@nic.ddn.mil
Subject:   MILNET -> non-MILNET routing -- anyone else noticing problems?
Since early last Friday, the *.jhuapl.edu network has had difficulty in
establishing and/or maintaining links to several non-MILNET sites (e.g.
*.cmu.edu).  Links tend to survive for only a few minutes at best.  When
an attempt is made to "ping -sv" such a site, the resulting output is
usually silence or a dump of the form:

36 bytes from 10.2.0.5: icmp_type=3 (Dest Unreachable)
x00: x45000024
x04: x78950000
x08: x06010000
x0c: x0a020005
x10: x80f4b030
x14: x0300d847
x18: x00000000
x1c: x45000054
x20: xa9c20000
x24: xfb018686
x28: x80f4b030
x2c: x8002de38
icmp_code=0
36 bytes from 10.1.0.28: icmp_type=3 (Dest Unreachable)
x00: x45000024
x04: x25450000
x08: x06010000
x0c: x0a01001c
x10: x80f4b030
x14: x0300d848
x18: x00000000
x1c: x45000054
x20: xa9c30000
x24: xfb018685
x28: x80f4b030
x2c: x8002de38
icmp_code=0

Has anyone else been experiencing problems along these lines?
--
Tony Nardo,		   INET: trn@warper.jhuapl.edu, trn@aplcen.apl.jhu.edu
 Johns Hopkins Univ./APL   UUCP: {backbone!}mimsy!aplcen!trn
		    Quote(s) relocated to my finger .plans
-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 90 15:21:34 GMT
From:      ogicse!caesar.cs.montana.edu!uakari.primate.wisc.edu!samsung!umich!terminator!merit.edu!rsc@decwrl.dec.com  (Richard Conto)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Who are the TCP/IP "port number police" ??
In article <9001291915.AA02256@jessica.Stanford.EDU> almquist@JESSICA.STANFORD.EDU ("Philip Almquist") writes:
>Rich,
>> I am trying to find out who to contact to officially register TCP/IP
>> port numbers.  I would also like to get a current list of port numbers
>> and their respective owners...
>
>	You want to read RFC1010, "Assigned Numbers".  It lists all
>officially assigned port numbers and also gives the procedure for
>obtaining port number assignments.
>
>	Some commonly used protocols do not use officially-assigned port
>numbers for various reasons.  Hans-Werner Braun of NSFNET recently
>attempted to make a list of these unofficial port numbers.  I seem to
>recall it's available via anonymous FTP from MERIT.EDU.
>
>						Philip

See "pub/ports", available via. anomalous FTP from merit.edu (35.1.1.42).
(And I don't vouch for the accuracy, just that it exists.) Also, the
assigned numbers RFC mentioned is in "pub/rfc/RFC1010.TXT-1".

--- Richard Conto
-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 90 19:00:22 GMT
From:      zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!utzoo!censor!isgtec!bmw@tut.cis.ohio-state.edu  (Bruce Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   I'm trying to SLIP from AT to UNIX, but can't!
Summary
-------
I've had no luck getting a SLIP link to work between an AT running
NCSA Telnet 2.2d (Clarkson version) and a Convergent Technologies
running CTIX 6.1 with TCP/IP version 3.1.  I have a feeling that my
troubles stem from something basic (I have no experience with SLIP
other than this attempt). If someone out there who has SLIP experience
could take a look at my findings and suggest something (especially
something to try), I'd be mighty pleased!

Setup
-----
The CT box is called "mutant", has an IP address of 3.0.0.8, and
is fully connected by ether to a dozen other hosts.  The AT is known
as "churchy" in the hosts files, IP address of 3.0.0.11 and is connected
through COM1 at 9600 baud (I have also tried 2400 baud) to host "mutant".
The packet driver is SLIP8250 version 5.3.

[I verified that Telbin works ok with a WD8003 in the AT both with telnet's
own internal WD driver and with a packet driver loaded.  In fact I'm using
it right now.]

Experimental Findings
---------------------
1) I slattach the SLIP link, run a serial line monitor on the AT and
   ping the IP address of the AT:

    mutant% slattach /dev/tty014 mutant churchy 2400
    mutant% ping churchy 1 1

- captured serial input on churchy (AT):

    0000000000 c0 01 18 40 b0 45 00 00 1d fd 0e 00 00 20 01 d5
    0000000020 bf 03 01 d8 40 80 00 00 8c aa ad ab 09 10 40 80
    0000000040 c0
    0000000041

2) I run trace, slip8250 and telbin on the AT in "slave" mode and
   ping the AT:

    mutant% ping churchy 1 1

- the Telbin control screen says "IP header checksum error"
  (or something very close to that.)

- results from packet trace:

       0.00 driver_info() = 5 6 0 0 2
       0.05 access_type(6 -1 0 0) = 4709
       0.05 get_address(4709) = no_error
       0.05 get_address(4709) = no_error
      13.96 receive_upcall(4709) = 38 bytes
    0000  01 02 08 18 40 b0 45 00 00 1d fd 67 00 00 20 01  ....@0E...}g.. .
    0010  d5 66 0d 02 08 10 61 40 00 00 0b 08 00 8c 9e 6b  Uf....a@.......k
    0020  61 00 00 00 00 00                                a.....
      22.69 release_type(4709) = no_error

3) I run telbin on the AT and try to connect to "mutant":

    C:\NCSA22TN> telbin -h config.slp mutant

- Telbin times out.
- netstat on mutant shows that 5 packets were received over sl0, but little
  else of interest can be discerned (at least by me).

4) A colleague who has this setup:
    - 386 box
    - FTP software's PC/TCP
    - CT with CTIX 6.1, TCP 3.1 (same basic UNIX setup as mine)
   has run SLIP successfully between his 386 and the Convergent.

Plea
----
Help!

-- 
Bruce Walker    ~    ...uunet!utai!lsuc!isgtec!bmw    ~   isgtec!bmw@censor
"What is the mind? No matter. What is matter? Never mind." -- Homer Simpson
ISG Technologies Inc.   3030 Orlando Dr. Mississauga.  Ont.  Can.   L4V 1S8
-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 90 19:49:42 GMT
From:      DOUG@YSUB.BITNET ("Doug Sewell")
To:        comp.protocols.tcp-ip
Subject:   rsh vs remsh -- how does one handle the name conflict?

'rsh' has been the name of the 'restricted shell' for Unix systems
for as long as I've worked with them, but this has mostly been SysV
environments.  On our UTS system, '/bin/rsh' is a link to '/bin/sh'.

On our Encore (4.2-based) system, there is no '/bin/rsh'.  If I enter
'rsh' on the Encore, it wants to know what host to use.

So, I'd conclude rsh (remote shell) is a Berkeleyism, and rsh (restricted
shell) is a ATTism.

Could you reorder your path ?  That would allow you to rename 'remsh'
to 'rsh'.  If a user truly is to be restricted, you would specify
the full  path-name for /bin/rsh, and they couldn't change their path
or directory anyway (some of the 'rsh' restrictions) to circumvent it.

Doug Sewell (DOUG@YSUB.BITNET), Tech Support, Computer Center,
Youngstown State University, Youngstown,  OH 44555
>> Love it or hate it, your body is yours for life.

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 90 20:48:33 GMT
From:      voder!dtg.nsc.com!andrew@ucbvax.Berkeley.EDU  (Lord Snooty @ The Giant Poisoned Electric Head )
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)
<2447@ncr-sd.SanDiego.NCR.COM>, ward@babel.SanDiego.NCR.COM (Ed Ward 2337) :
> I'm looking for some information comparing the Ethernet throughput of the 
> AMD lance, Seeq 8005, and Intel 82??? controller chips....

I'd look at National's NIC too - they practically own the Enet market.
-- 
...........................................................................
Andrew Palfreyman	andrew@dtg.nsc.com	Albania before April!
-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      30 Jan 90 21:38:59 GMT
From:      voder!pyramid!athertn!joshua@ucbvax.Berkeley.EDU  (Flame Bait)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
How about this as an refinement of my "gas tax" idea:
    Every connectable device comes with a counter.  You pay the network
    and they give you a certain number of packets.  Every week or month
    or year or decade, you buy some more packets.  The counter would 
    be some sort of self contained chip (like a DES chip) to make it
    hard to break into it.  Lost packets are too bad.  This is much 
    closer to the "gas tax ideal".  The tax has low run time cost, and
    you only pay for what you use (roughly).  Enforcement could be 
    administrative (checking people before you physically connect them
    to the net) and random (check every millionth packet to make sure
    the "tax chip" on that device has not been tampered with).

In article <4430@orion.cf.uci.edu> DHWalker@uci.edu (David Walker) writes:
>I guess I think the "tax" should be on a connection to the network, not on 
>the connectable device, if I understand you correctly.  

Sure.  I do not care if the tax is on network connection or network devices.
If you make it on a device, it encourages people to hook themselves up to 
the network (since they are paying for it anyway, they might as well use
it.)  I like the idea of those who buy networkable equipment, but choose
not to be connected subsidizing those who are connected.  I want universal
connectivity.

>There should be a fixed base price that people should pay to be connected, 
>but people who need more/better service than others should pay enough 
>additional money to increase the network's capacity to provide that service.

More like people who need specialized service should pay for it seperately.
This is sort of like taxes on trucks.  They pay much more in taxes than
cars, but they hurt the roads a lot more to.

>Your gas tax analogy isn't bad, though, except that per-gallon comes too 
>close to per-packet for my liking.

Let me be clear about why I like the gas tax:
    1. It is an almost no overhead tax.  It magically disappears when I
       fill the tank, which I would need to do anyway.
    2. It is an OK measure of road usage.  Note that it is not a perfect
       messure, since some people buy gas for off road racing.  But as a
       first guess, it is pretty good.

The order here is important.  I want the tax to be low overhead (easy to
collect).  I'm willing to make it less fair in order to make it low
overhead.  

>It occurs to me that my thoughts imply that care be taken to see that the 
>desired level of service is actually delivered. I suppose that's probably 
>one of the things wrong with the Interstates.

If you want better service, I think your networks must be owned and 
opperated by private industry.  That is a seperate issue from how the
network is paid for.

Joshua Levy
--------                Quote: "The fact is, if your front money is not for
Addresses:                      real, then you're not for real."
joshua@atherton.com                               -- To Live and Die In L.A.
{decwrl|sun|hpda}!athertn!joshua    work:(408)734-9822    home:(415)968-3718
-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 90 01:26:01 GMT
From:      wuarchive!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!cluster!metro!bunyip!brolga!ggm@decwrl.dec.com  (George Michaelson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: billing for use
vcerf@NRI.RESTON.VA.US writes:

>anticipated. For instance, when the UK was faced with paying for
>TCP/IP traffic on X.25 IPSS service, they quickly re-wrote their
>email application to do a file transfer rather then using SMTP
>because the SMTP took up a lot more packet exchanges than FTP!

This model also reflects how email is routinely sent within the UK JANET.
The coloured books layering uses the existing blue book FTP transfer to
pass store and forward mail messages whose contents are defined by the grey
book. A minor addressing change in the blue book/transport connect identifies
the contents as mail.

The mail/ftp layering makes sense in the contect of store and forward mail.
and minimizes duplication of protocol implementation by using the existing 
blue book ftp implementation. Batched SMTP comes close in attempting to share
usage of an existing TCP/IP connection and thus avoids n-1 connect/fork/exec
overheads for n messages but as you point out still incurs more protocol
overheads than simply sending a batch of mail as a (compressed?) ftp file.

I wonder how many IBM half duplex login users will choose to club together
and get their screen sessions sent across the waters as batched ftp :-)

	-George

Internet: G.Michaelson@cc.uq.oz.au                     Phone: +61 7 377 4079
  Postal: George Michaelson, Prentice Computer Centre
          Queensland University, St Lucia, QLD Australia 4067. 
-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 90 04:12:56 GMT
From:      amdcad!ncpmont@ucbvax.Berkeley.EDU  (Mark Montgomery)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Ethernet Throughput (AMD vs. Intel vs. Seeq)
In article <582@berlioz.nsc.com> andrew@dtg.nsc.com (Lord Snooty @ The Giant Poisoned Electric Head       ) writes:
><2447@ncr-sd.SanDiego.NCR.COM>, ward@babel.SanDiego.NCR.COM (Ed Ward 2337) :
>> I'm looking for some information comparing the Ethernet throughput of the 
>> AMD lance, Seeq 8005, and Intel 82??? controller chips....
>
>I'd look at National's NIC too - they practically own the Enet market.
>-- 
>...........................................................................
>Andrew Palfreyman	andrew@dtg.nsc.com	Albania before April!

Whoa, boy!	I think that the statement "they practically own the Enet
market" is a bit rash.	Check with IBM, DEC, SUN or 3COM or look inside their
boxes.  I think you'll find that there are about twice as many AMD LANCE, SIA
and XCVR chips in them as all those other manufacturers have sockets combined.
"LOOK AGAIN" to quote the T.I. speak n' spell chip.		Mark
-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Jan 90 13:01:53 PST
From:      postel@venera.isi.edu
To:        ryburn@granite.cr.bull.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: PEP and SL/IP & PPP

Scott Ryburn:

See: RFC-1055 for SLIP, and see also RFC-1134 for PPP.

--jon.
-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Jan 90 13:11:25 PST
From:      slm@wsc-sun.boeing.com (Shamus McBride)
To:        TCP-IP@NIC.DDN.MIL
Subject:   tcp port numbers
I tossed out a tcp port number list a couple of weeks ago and would like to
thank the following people for responding:

    Jim Kaump <jfk@PacBell.COM>
    Terry Slattery (SECAD) <tcs@BRL.MIL>
    Chris <tengi@Princeton.EDU>
    Steve Jay <shj@ultra.com>

I revised my list with the inputs received and have attached it below.
This will be my last posting of the list. A recent note from Richard
Conto pointed me to the file "pub/ports" available via anomymous FTP
from medit.edu (35.1.1.42). This list clearly shows the "anarchy" of
port usage above 255.
 
(Following list trimmed to 80 columns)

ALL vendors = RFC ibm sgi sun ultrix unicos yp 
 
 tcp:
    7 echo                        RFC:ALL                          # Echo
    9 discard                     RFC:ALL                          # Discard
   11 users:systat                RFC:ALL                          # Active User
    # systat on ibm sgi sun ultrix ultrix unicos yp
    # users in RFC
   13 daytime                     RFC:ALL                          # Daytime
   15 unassigned-15:netstat       RFC:ALL
    # netstat on ibm sgi sun ultrix ultrix unicos yp
    # unassigned-15 in RFC
   17 quote:qotd                  RFC:ibm:sgi:ultrix:unicos        # Quote of th
    # qotd on ibm sgi ultrix ultrix unicos
    # quote in RFC
   19 chargen                     RFC:ibm:sgi:ultrix:unicos        # Character G
   20 ftp-data                    RFC:sun:yp                       # File Transf
   21 ftp                         RFC:ALL                          # File Transf
   23 telnet                      RFC:ALL                          # Telnet
   25 smtp                        RFC:ALL                          # Simple Mail
   37 time                        RFC:ALL                          # Time
   42 nameserver                  RFC:ibm:sgi:ultrix:unicos        # Host Name S
   43 nicname:whois               RFC:ALL                          # Who Is # us
    # whois on ibm sgi sun ultrix ultrix unicos yp
    # nicname in RFC
   53 domain                      RFC:ALL                          # Domain Name
   57 private-57:mtp              RFC:ibm:sgi:ultrix:unicos        # any private
    # mtp on ibm sgi ultrix ultrix unicos
    # private-57 in RFC
   77 private-77:rje              RFC:ALL                          # any private
    # rje on ibm sgi sun ultrix ultrix unicos yp
    # private-77 in RFC
    # 5 in RFC
   79 finger                      RFC:ALL                          # Finger
   87 private-87:link             RFC:ALL                          # any private
    # link on ibm sgi sun ultrix ultrix unicos yp
    # private-87 in RFC
    # 245 in RFC
   95 supdup                      RFC:ALL                          # SUPDUP
  101 hostname:hostnames          RFC:ALL                          # NIC Host Na
    # hostnames on ibm sgi sun ultrix ultrix unicos yp
    # hostname in RFC
  102 iso-tsap:tsap               RFC:sun:yp:ultrix                # ISO-TSAP # 
    # tsap on ultrix
    # iso-tsap in RFC sun yp
  103 x400                        RFC:sun:yp                       # X400 # ISO 
  104 x400-snd                    RFC:sun:yp                       # X400-SND
  105 csnet-ns                    RFC:sun:yp                       # Mailbox Nam
  105 #csnet-cs ibm:sgi:ultrix:unicos #csnet-cs ibm  #csnet-cs sgi  #csnet-cs ul
  109 pop:pop-2                   ibm:sgi:ultrix:unicos:RFC:sun:yp # Post Office
    # pop-2 in RFC sun yp
    # pop on ibm sgi ultrix ultrix unicos
  111 sunrpc                      RFC:ALL                          # SUN Remote 
  113 auth                        RFC:ibm:sgi:ultrix:unicos        # Authenticat
  115 sftp                        RFC:ibm:sgi:ultrix:unicos        # Simple File
  117 uucp-path                   RFC:ALL                          # UUCP Path S
  119 nntp                        RFC:ALL                          # Network New
  123 ntp                         RFC:sun:yp                       # Network Tim
  144 NeWS:unassigned-144         sun:yp:RFC                       # Window Syst
    # unassigned-144 in RFC
    # NeWS on sun yp
  153 sgmp-netview:unassigned-153 ibm:RFC
    # unassigned-153 in RFC
    # sgmp-netview on ibm
  160 reserved-160:sgmp-trap      RFC:ibm
    # sgmp-trap on ibm
    # reserved-160 in RFC
  162 reserved-162:snmp-trap      RFC:ibm
    # snmp-trap on ibm
    # reserved-162 in RFC
  170 print-srv:reserved-170      ultrix:RFC                       # network Pos
    # reserved-170 in RFC
    # print-srv on ultrix ultrix
  175 reserved-175:vmnet          RFC:ibm                          # RSCS over T
    # vmnet on ibm
    # reserved-175 in RFC
  201 nqs:reserved-201            yp:RFC                           # NQS daemon
    # reserved-201 in RFC
    # nqs on yp
    # 607 on unicos
  260 rtape                       ultrix                           # remote tape
  512 exec                        ALL
  513 login                       ALL
    # 49 in RFC
  514 shell                       ALL                              # no password
  515 printer                     ALL                              # line printe
  520 efs                         ibm:sgi:ultrix:unicos            # for LucasFi
  526 tempo                       ibm:sgi:ultrix:unicos
  530 courier                     ALL                              # experimenta
  531 conference                  ibm:sgi:ultrix:unicos
  532 netnews                     ibm:sgi:ultrix:unicos
  540 uucp                        ibm:sgi:ultrix:unicos            # uucp daemon
  543 klogin                      yp                               # Kerberos au
  544 kshell                      yp                               # and remote 
  556 remotefs                    ibm:sgi:ultrix:unicos            # Brunhoff re
  570 eval                        ultrix                           # remote eval
  600 pcserver                    yp                               # SunIPC
  607 nqs                         unicos                           # Cray Networ
    # 201 on yp
  608 cde                         unicos                           # Cray Distri
  712 vexec                       ibm
  713 vlogin                      ibm
  714 vshell                      ibm
  750 kerberos                    yp                               # Kerberos au
  751 kerberos_master             yp                               # Kerberos au
  754 krb_prop                    yp                               # Kerberos sl
  755 kadmind                     yp
  888 erlogin                     yp                               # Login and e
  906 sample                      yp                               # Kerberos sa
 1109 kpop                        yp                               # Pop with Ke
 1234 mkuserd                     yp
 1524 ingreslock                  ALL
 1525 orasrv                      oracle
 2001 filesrv:lgc_pd              ibm:unicos
    # lgc_pd on unicos
    # filesrv on ibm
 2002 lgc_sdsrv                   unicos
 2015 cypress                     sgi                              # cypress rou
 2017 cypress-stat                sgi                              # cypress mon
 2030 client                      ibm
 2053 knetd                       yp                               # Kerberos de
 2105 eklogin                     yp                               # Kerberos en
 2106 venus.itc                   ibm
 5000 VTVIN                       unicos                           # bill samayo
 5003 xcwcs                       ultrix:yp                        # CWCS contro
 5004 cwdata                      ultrix:yp                        # CWCS file t
 5232 #sgi-dgl                    sgi                              #sgi-dgl sgi 
 5558 remotefb                    sgi                              # Remote Fram
 6000 x-server                    sgi                              # X11 window 
22375 quantic                     unicos

 udp:
    7 echo                        RFC:ALL                          # Echo
    9 discard                     RFC:ALL                          # Discard
   13 daytime                     RFC:ALL                          # Daytime
   19 chargen                     RFC:ibm:sgi:ultrix:unicos        # Character G
   37 time                        RFC:ALL                          # Time
   39 rlp                         RFC:ibm:sgi:ultrix:unicos        # Resource Lo
   42 nameserver:name             RFC:sun:yp                       # Host Name S
    # name on sun yp
    # nameserver in RFC
   53 domain                      RFC:ALL                          # Domain Name
   67 bootps:bootp                RFC:sgi:ultrix                   # Bootstrap P
    # bootp on sgi ultrix ultrix
    # bootps in RFC
   68 bootpc                      RFC:sgi                          # Bootstrap P
   69 tftp                        RFC:ALL                          # Trivial Fil
  111 sunrpc                      RFC:ALL                          # SUN Remote 
  123 ntp       e 3.2 
-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Jan 90 13:47:52 PST
From:      Sol Lederman <SOL@NIC.DDN.MIL>
To:        tcp-ip@NIC.DDN.MIL
Subject:   MMDF help needed
I'm trying to help someone track down a very esoteric (to me) MMDF problem
and would appreciate help from an MMDF wizard. Please call me (800-235-3155)
or e-mail to me providing a phone number if you can help.

Thanks very much,
Sol Lederman/NIC
-------
-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      Wed, 31 Jan 90 12:02:03 EST
From:      Bob Haring-Smith <RHH@brownvm.brown.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   meaning of netstat output
Does anyone know the significance of a high value for "Bad proto" in
the output from netstat on Unix machines using ethernet?  We're seeing
values in the tens of thousands out of a few hundred thousand packets
sent/received in all.  Some "Bad proto" values are negative, too.  (Off
the scale?)  Any help would be appreciated.
                                           --Bob
-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 90 13:39:58 GMT
From:      bnrgate!bcars85!linegar@uunet.uu.net  (Derick Linegar)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP for HPUX
Hi,
	I am looking for a SLIP implementation that will work on a HP series
	300 machine running version 6.5 of HPUX. HPUX is a "sorta" SysV kernel
	so pointers to a SysV version of SLIP is also desirable.

	Please, E-mail me, and I'll summarise if there is any interest. 

	Thanks in advance...
#include <disclaimer.h>
Derick Linegar,     Internet Systems 4P25,              Bell-Northern Research 
BITNET: LINEGAR@BNR.ca                                  P.O. Box 3511 Station C
							Ottawa ONT. K1Y 4H7
-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 90 16:15:30 GMT
From:      encore!pinocchio.encore.com@husc6.harvard.edu  (Jeff d'Arcy)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: rsh vs remsh -- how does one handle the name conflict?
DOUG@YSUB.BITNET ("Doug Sewell"):
- On our Encore (4.2-based) system, there is no '/bin/rsh'.  If I enter
- 'rsh' on the Encore, it wants to know what host to use.
- 
- So, I'd conclude rsh (remote shell) is a Berkeleyism, and rsh (restricted
- shell) is a ATTism.

Pretty much true.  On the UMAX V systems I've used in-house, rsh is the ATT
restricted shell, while nsh is the BSD remote (network) shell.


Jeff d'Arcy     OS/Network Software Engineer     jdarcy@encore.com
  Encore has provided the medium, but the message remains my own
-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 90 16:16:20 GMT
From:      ESC1814@ESOC.BITNET (Dave Stafford)
To:        comp.protocols.tcp-ip
Subject:   Network Records


Having implemented a Wide and Local Area network based on TCP/IP (and other
protocols) I've now run up against a administrative problem.

I have a Class B number split into 8 bit subnets and distributed throughout
Europe at several European Space Agency Sites. There are numerous ethernet
and token-rings LANs at each site, and a multitude of system administrators.

Now my problem is that there seems to be all manner of tools for designing,
monitoring etc. these networks, but none for administering them.

Eg. I want a database product for tracking the allocation of the subnet numbers
and also host numbers on the individual subnets. This needs to be a distributed
system so that records may be maintained at different sites, yet queries should
be possible from any site. Perhaps some automated tracking system and
allocation procedure would also be useful.

Does anyone know of such a product?

Dave Stafford
European Space Operations Centre
Robert Bosch Strasse 5,
Darmstadt, West Germany
Tel (49) 6151 886 907
Fax (49) 6151 886 908

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 90 17:02:03 GMT
From:      RHH@BROWNVM.BROWN.EDU (Bob Haring-Smith)
To:        comp.protocols.tcp-ip
Subject:   meaning of netstat output

Does anyone know the significance of a high value for "Bad proto" in
the output from netstat on Unix machines using ethernet?  We're seeing
values in the tens of thousands out of a few hundred thousand packets
sent/received in all.  Some "Bad proto" values are negative, too.  (Off
the scale?)  Any help would be appreciated.
                                           --Bob

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Feb 90 01:13:13 PST
From:      ho@la.tis.com (Hilarie K. Orman)
To:        tcp-ip@nic.ddn.mil
Subject:   For the record - Racal Interlan is up
Troubles I reported recently in reaching Racal Interlan about their
TCP/IP products appear to have been transient, and I have been able to
reach them by packet and by telephone.
-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 90 20:45:15 GMT
From:      maytag!watcsc!rbetel@iuvax.cs.indiana.edu  (Richard Betel)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP-IP and NSCA.

 I have been following this newsgroup and ~.ibmpc for 5 months now, but
I still don't have a good answer to my questions about TCP-IP:
 What is it? I understand that TCP and IP are levels of the OSI model,
but I am not sure what that means. How are TCP and IP related? And how
does NSCA that they discuss in ~.ibmpc relate to TCP/IP?
                               Richard
-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      31 Jan 90 22:32:04 GMT
From:      zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!jarthur!elroy.jpl.nasa.gov!zardoz!neil@tut.cis.ohio-state.edu  (Neil Gorsuch)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: PEP and SL/IP
In article <4792@convex.convex.com> datri@convex.com (Anthony A. Datri) writes:
>>Well, I've heard things that imply the Sun serial ports are silly,
>>except for the "CPU port" (I suppose that's a serial port that's directly
>Ports of a Systech MTI (aka alm) in a Sun are less than wonderful.
>The CPU board has two on-board ports run from a zilog chip that are better.

And the ports in a SCSI serial box are even better still, since they
support full hardware modem control, and use the standard tty
drivers already in the Sun 8-).


--
Neil Gorsuch        INTERNET: neil@cpd.com          UUCP: uunet!zardoz!neil
MAIL: 1209 E. Warner, Santa Ana, CA, USA, 92705     PHONE: +1 714 546 1100
Uninet, a division of Custom Product Design, Inc.   FAX: +1 714 546 3726
AKA: root, security-request, uuasc-request, postmaster, usenet, news

END OF DOCUMENT