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 March 1990 (411 messages, 212768 bytes)
SOURCE: http://securitydigest.org/exec/display?f=tcp-ip/archive/1990/03.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      Thu, 01 Mar 90 09:21:27 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   Nominations for SIGCOMM Award



		      The SIGCOMM Award


The SIGCOMM Award was initiated in 1989 as a  means  of  honoring
computer  communications  professionals for outstanding technical
achievement in the fields of data- and computer-  communications.
The award consists of a plaque and a $2000 honorarium.  The award
will be presented at the  annual  SIGCOMM  Conference,  at  which
time,  the awardee is invited to deliver a technical address.  In
the following are guidelines for submitting a nomination.

   1.   Self-nominations are not accepted.

   2.   The nominee need NOT be a member of ACM SIGCOMM

   3.   The nominator MUST be a member of ACM SIGCOMM

   4.   Nominations must be received by  the  chairman  of  the
	SIGCOMM  Award  Committee  no later than May 30 of each
	year.

   5.   Nominations which did not result in  an  award  can  be
	resubmitted/updated in subsequent years.

   6.   Previous awardees are not eligible for  future  nomina-
	tions.   (The  1989  awardee  was  Paul  Baran, for the
	invention of packet switching).

   7.   Members of the Award Committee are not eligible.

   8.   Members of the SIGCOMM Executive  Committee  (chairman,
	vice  chairman,  secy-treasurer  and  editor as well as
	past chairman) are not eligible.

Material to be included in nomination:

   1.   Curriculum Vitae, including publications, of nominee

   2.   Concise statement (one sentence) of the work for  which
	the  award  is  being  nominated.   This statement will
	appear on the award plaque.

   3.   Description of the nominee's role in the work  justify-
	ing the nomination.

   4.   Letters of recommendation from  others  which  identify
	rationale  for  the  nomination  and  by what means the
	recommender knows of the nominee's work. It  is  recom-
	mended that at least three letters of recommendation be
	included in the nominations materials.

   5.   Justification for declaring the nominee's work to be  a
	major, lifetime contribution to computer communications.

The nomination should be made in the form of a  letter  addressed
to  the  chairman  of  the SIGCOMM Award Committee. The nominator
should solicit recommendations from colleagues in the  field  who
are  most  familiar  with  the nominee's achievements.  It is not
recommended to send copies of published  papers  or  books  along
with  the nomination materials.  The nominator is responsible for
gathering all nomination materials and sending two copies of  all
materials  to  reach  the chairman of the awards committee before
May 30th. No late nominations will be considered for the  current
year.   They  will be held over until the following year for con-
sideration.

The 1990 chair of the SIGCOMM Award Committee is:

      Dr. Franklin F. Kuo     Tel: 415-859-4116
      SRI International       e-mail: Kuo@NISC.SRI.COM
      333 Ravenswood Avenue   fax: 415-859-6171
      Menlo Park, CA 94025


Inforomation on SIGCOMM '90

SIGCOMM '90 will be held in Philadelphia, Pennsylvania, September
25-27th, with tutorials on September 24th.  Registration informa-
tion will appear in the  July  issue  of  Computer Communication
Review and  the  August issue of IEEE Communications.  For more
information, contact the General Chair: Prof. David Farber,  Pro-
fessor  of  Computer  and  Information  Science and of Electrical
Engineering, University of Pennsylvania, 200 South 33rd St,  Phi-
ladelphia,  Pennsylvania,  19104-6389, USA; Telephone: (215) 898-
9508; EMAIL: farber@cis.upenn.edu; FAX: (215) 898-0587

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      Thu, 01 Mar 90 16:10:20 -0800
From:      jqj@rt-jqj.Stanford.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   more on RFC wars

I notice that, according to Joyce Reynolds' message of 22 Feb 90, RFC 1143 is
"Copyright 1990, Daniel J. Bernstein.  However, distribution of this memo in
original form is unlimited."  Is there, or should there be, a policy on
acceptance of copyrighted materials for RFCs?  In particular, since one of the
arguments given for text-format RFCs was ability to extract quotations easily
and store the material for online search and retrieval, should any materials
be accepted as RFCs that do not permit this use?

I haven't been following copyright law in the last couple of years, so perhaps
"fair use" doctrine covers all reasonable uses of RFCs; could someone who
knows the recent case law comment briefly?  I suspect not, and that in fact we
should require an explicit disclaimer of rights on future RFCs.
-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Mar 90 08:22:21 EST
From:      gaw@mercury.acc.com (...Glen............)
To:        uunet!salt.acc.com!gaw%saturn.ACC.COM@uunet.uu.net, wrs!yuba!hwajin@uunet.uu.net
Cc:        sun!decwrl!dcrocker@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re: UDP bind question
Thank you for the information about where I could obtain the 
specification to TPI.

Glen Warhoilic
gaw@mercury.acc.com
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 90 03:59:33 GMT
From:      mentor.cc.purdue.edu!dls@ee.ecn.purdue.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP Protocol Question: reusing connections

	You get the RST from MachineB because it has to wait 2MSL (TIME_WAIT
state in the TCP spec) to make sure that MachineA's idea of that connection has
died. If MachineB gets anything else with the same port pair, it assumes it's
a retransmission (normally) and ACK's it. Unfortunately, SYN is only allowed
when MachineB's end is in LISTEN, but it's in TIME_WAIT. Ooops => RST.
	You'd get the RST regardless of the sequence numbers, though you'd
get one for ACKing more than MachineB sent, if that were the case, too. The
window management really isn't related though-- the problem is that MachineB
can't be sure that MachineA got his ACK of A's FIN, so it has to wait around
to handle retransmissions gracefully.

	It's doing the right thing and the solution is to have one of them
pick a different port each time.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)
-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Mar 90 11:32:38 EST
From:      dlj@proteon.com (Daniel L. Jones)
To:        mep@aqua.whoi.edu
Cc:        mag%WLBR@wlv.imsd.contel.com, tcp-ip@nic.ddn.mil
Subject:   IP routers

   Proteon has a low-end router, which is PC based that is less
expensive and perfect for small networks.

Dan Jones
-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 90 10:33:06 GMT
From:      ESC1814@ESOC.BITNET
To:        comp.protocols.tcp-ip
Subject:   Re: Looking for SNA<->TCP/IP gateway

I've heard rumor Cisco will be routing SNA, is this true?

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      Thu, 01 Mar 90 10:20:16 SET
From:      ESC1814%ESOC.BITNET@CUNYVM.CUNY.EDU
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Looking for SNA<->TCP/IP gateway
I've heard rumor Cisco will be routing SNA, is this true?
-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 90 12:18:09 GMT
From:      crdgw1!gecrdvm1!hathawa@uunet.uu.net  (Barry Hathaway)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: 3270 terminal access
All users here have to access at least one application (a time card system)
on our IBM mainframe.  We have attached our IBM to our local ethernet using
a BTI ethernet controller and run IBM TCP/IP software.  The Sun users just
invoke tn3270 to fire up a full-screen telnet session with the IBM application.
-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      Thu, 1 Mar 90 22:08:31 PST
From:      ron@manta.nosc.mil (Ron Broersma)
To:        nems!dtix!curt@mimsy.umd.edu, tcp-ip@nic.ddn.mil
Subject:   Re: *.jhuapl.edu -- serious gateway thrashing
I'm wondering if some of this gateway thrashing isn't related to the
fact that EGP packets from the MILNET core started exceeding 4096 bytes
a month or two ago.  At that time, I was tracing some thrashing problems
and I noticed the following symptoms.  Over the course of an hour, the
packets would gradually increase in size.  Just as they got within 10
to 20 bytes of 4096, many of the EGP implementations would suddenly
start getting checksum errors or buffer overflows because they had
4K buffers.  The ones that got a few packets with bad checksums would
suddenly stop peering with that core gateway.  Then, all of a sudden the
EGP packets out of the core would be smaller by a few hundred bytes because
of many fewer peers.  As the EGP players all tried to acquire a different
gateway, they would not get the checksum errors for an hour or so until
the packets approached 4096 bytes and they would again perform this
dance-of-the-gateways.

The message here is to make sure your EGP implementation can handle
packets larger than 4K bytes.  The most recent gated supports 8K packets
as I recall.

Something I had considered was to make a list of all the networks that
disappeared from the EGP packets right after the "dance".   Then if one
could determine who announced those nets to the core you could get a
handle on where the broken EGP implementations were located.

There's some other strangeness going on too.  We had a case this week
where one site running EGP was announcing its network to the core but
the core wasn't telling anybody else about it.  By peering with a
different mailbridge, it started working.  Strange.

And to top it off, the ground started shaking yesterday.  But we think
that is an unrelated (hardware) problem.

--Ron
-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 90 14:21:27 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   Nominations for SIGCOMM Award




		      The SIGCOMM Award


The SIGCOMM Award was initiated in 1989 as a  means  of  honoring
computer  communications  professionals for outstanding technical
achievement in the fields of data- and computer-  communications.
The award consists of a plaque and a $2000 honorarium.  The award
will be presented at the  annual  SIGCOMM  Conference,  at  which
time,  the awardee is invited to deliver a technical address.  In
the following are guidelines for submitting a nomination.

   1.   Self-nominations are not accepted.

   2.   The nominee need NOT be a member of ACM SIGCOMM

   3.   The nominator MUST be a member of ACM SIGCOMM

   4.   Nominations must be received by  the  chairman  of  the
	SIGCOMM  Award  Committee  no later than May 30 of each
	year.

   5.   Nominations which did not result in  an  award  can  be
	resubmitted/updated in subsequent years.

   6.   Previous awardees are not eligible for  future  nomina-
	tions.   (The  1989  awardee  was  Paul  Baran, for the
	invention of packet switching).

   7.   Members of the Award Committee are not eligible.

   8.   Members of the SIGCOMM Executive  Committee  (chairman,
	vice  chairman,  secy-treasurer  and  editor as well as
	past chairman) are not eligible.

Material to be included in nomination:

   1.   Curriculum Vitae, including publications, of nominee

   2.   Concise statement (one sentence) of the work for  which
	the  award  is  being  nominated.   This statement will
	appear on the award plaque.

   3.   Description of the nominee's role in the work  justify-
	ing the nomination.

   4.   Letters of recommendation from  others  which  identify
	rationale  for  the  nomination  and  by what means the
	recommender knows of the nominee's work. It  is  recom-
	mended that at least three letters of recommendation be
	included in the nominations materials.

   5.   Justification for declaring the nominee's work to be  a
	major, lifetime contribution to computer communications.

The nomination should be made in the form of a  letter  addressed
to  the  chairman  of  the SIGCOMM Award Committee. The nominator
should solicit recommendations from colleagues in the  field  who
are  most  familiar  with  the nominee's achievements.  It is not
recommended to send copies of published  papers  or  books  along
with  the nomination materials.  The nominator is responsible for
gathering all nomination materials and sending two copies of  all
materials  to  reach  the chairman of the awards committee before
May 30th. No late nominations will be considered for the  current
year.   They  will be held over until the following year for con-
sideration.

The 1990 chair of the SIGCOMM Award Committee is:

      Dr. Franklin F. Kuo     Tel: 415-859-4116
      SRI International       e-mail: Kuo@NISC.SRI.COM
      333 Ravenswood Avenue   fax: 415-859-6171
      Menlo Park, CA 94025


Inforomation on SIGCOMM '90

SIGCOMM '90 will be held in Philadelphia, Pennsylvania, September
25-27th, with tutorials on September 24th.  Registration informa-
tion will appear in the  July  issue  of  Computer Communication
Review and  the  August issue of IEEE Communications.  For more
information, contact the General Chair: Prof. David Farber,  Pro-
fessor  of  Computer  and  Information  Science and of Electrical
Engineering, University of Pennsylvania, 200 South 33rd St,  Phi-
ladelphia,  Pennsylvania,  19104-6389, USA; Telephone: (215) 898-
9508; EMAIL: farber@cis.upenn.edu; FAX: (215) 898-0587

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 90 16:18:26 GMT
From:      zaphod.mps.ohio-state.edu!mips!bridge2!jarthur!polyslo!rnicovic@tut.cis.ohio-state.edu  (Ralph Nicovich)
To:        tcp-ip@nic.ddn.mil
Subject:   Routing and Multiple Subnets on one net

Netters,

I find something strange on our network which seems to involve all
Routers on our network
It seems to be an incompatability between the routers and the addressing
on our network, and I thought you might have some insight or at least 
see if my cenario makes sence.
First, we are running multiple (2) subnets on the same physical (DLL)
network. There are a number of papers that claim this is leagal, but
perhaps their setup was diferent. In our case the two networks (subnets)
are 129.65.16.0 and 129.65.160.0, the wrinkle is that the mask on
16.0 is ff.ff.f0.00 and on 160.0 it is ff.ff.ff.00 . 
What happens is that a kinettics fastpath gateway on 160 sends out
a apple link broadcast. imediatly each of our routers retransmits the
same packet to the physical (DLL) address of the router that connects
16.0 to 160.0 . This router between the two subnets has two ethernet
interfaces both on the same cable.
It is my understanding that routers do not route broadcast packets.
In fact that is the benifit of routers over Data Link Bridges.
This is my guess of what happens. 
The Cisco and all the other routers are on network 16.0 with a mask
of ff.ff.f0.00. They see this broadcast packet from the kinettics
since at the DLL level it is a broadcast and they must look at it.
They then apply their network mask to the IP destination address
of 129.65.160.255 (which is the propper broadcast for 160.0 .
When the routers apply this mask they see 0's in the host field
and therfore do not recognise it as a broadcast at the IP level.
They then send it to the router between 16.0 and 160.0 since
they know that path and feel the packets should be routed.
Personaly I would think that any packet that is a broadcast
at the DLL level should not be automaticaly routed. Mabye this
is not the case.
Any Ideas ?
Ralph Nicovich
Cal Poly State University
Network Engineering
-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 90 19:13:22 GMT
From:      bionet!turbo.bio.net!phakt.usc.edu@apple.com  (Tony Li)
To:        tcp-ip@nic.ddn.mil
Subject:   comp.dcom.sys.cisco passes

The vote was 221 in favor, 35 against.  

Per USEnet newsgroup creation guidelines, there will now be a 5 day
waiting period for any necessary corrections to the vote tally.
Please mail any corrections to me, tli@usc.edu.  Thanks.

No votes:
----------------------------------------------------------------------
"Roger Fajman" <RAF%CU.NIH.GOV@usc.edu>
Bill Nugent <whn%SH.CS.NET@usc.edu>
Brian Holmes <BHOLMES%WAYNEST1.BITNET%CORNELLC.cit.cornell.edu@usc.edu>
David Paul Zimmerman <dpz%convex.com@usc.edu>
David Wright <dww@stl.stc.co.uk>
Greg Satz <satz%cisco.com@usc.edu>
Guy Almes <almes%rice.edu@usc.edu>
JSorenson.WBST%Xerox.COM@usc.edu
Jean-Francois Gagnon <aspyjfg%cid.aes.doe.CA@usc.edu>
Jeff Kilpatrick <b11!jeff>
Michael A. Patton <MAP%lcs.mit.edu@usc.edu>
Mike Moravan <moravan%csupwb.ColoState.EDU@usc.edu>
Paul Groff <groff%westford.ccur.com%RELAY.CS.NET@usc.edu>
ben%hpcts1.corp.hp.com@usc.edu
blm%6sceng%polari%sumax%beaver.cs.washington.edu%rutgers.uucp@usc.edu (Brian Matthews)
cdspr!alzabo!kebera@rutgers.edu (Krishna E. Bera)
dcmwood%spot.Colorado.EDU@usc.edu (David CM Wood)
dwillis%polyslo.CalPoly.EDU@usc.edu (Alden Willis)
gfw%pueblo.att.com@usc.edu
hepner@cod.nosc.mil (Thomas A. Hepner)
jqj%rt-jqj.Stanford.EDU@usc.edu (JQ Johnson)
jrp%rducky.uucp%csufres.uucp@usc.edu (JIM PICKERING)
loa%nddsun2.sps.mot.com ?@usc.edu  (Kanchei Loa)
mellon%decwrl.dec.com@usc.edu (Ted Lemon)
nih-csl!elsie!ado@uunet.UU.NET (Arthur David Olson)
oplinger@ra.crd.ge.com (B. S. Oplinger)
prue%venera.isi.edu@usc.edu
ray%philmtl.philips.ca%rutgers.uucp@usc.edu (Ray Dunn)
riiali@lut.fi (Pekka Riiali)
root%rcvie.uucp%relay.EU.net@usc.edu (System PRIVILEGED Account)
sob@bcm.tmc.edu (Stan Barber)
tar%ksuvax1.cis.ksu.edu@usc.edu (Tim Ramsey)
wisner@hayes.fai.alaska.edu (Bill Wisner)
wmarko%ub.d.umn.edu@usc.edu (William J. Marko)
wrl%wdl1.fac.ford.com@usc.edu (Bill Lewandowski)

Yes votes:
----------------------------------------------------------------------
"David C. White" <davew%gvgpsa.gvg.tek.com%RELAY.CS.NET@usc.edu>
"David" <hearn%ccint1.rsre.mod.uk@usc.edu>
"Doug McCallum" <dougm%ico.isc.com%rutgers.uucp@usc.edu>
"Gerben Jansen" <GERBEN%SARA.NL%VM.USC.EDU@usc.edu>
"J. Paul Holbrook" <ph%SEI.CMU.EDU@usc.edu>
"Jeff Wabik" <jwabik%uh.msc.umn.edu@usc.edu>
"John M. Wobus" <JMWOBUS%SUVM.BITNET%CORNELLC.cit.cornell.edu@usc.edu>
"Kevin Oberman, LLNL, (415)422-6955" <OBERMAN%icdc.llnl.gov@usc.edu>
"Kurt Schreiner" <ks@cs.uni-sb.de>
"Marcel Dorenbos, C3, tfn 070-435127" <MCM_Dorenbos%pttrnl.nl%CUNYVM.CUNY.EDU@usc.edu>
"Mark A. Brown" <mark%nova.usc.edu@usc.edu>
"ROLF @DTN226-7184" <mcclellan%delni.enet.dec.com@usc.edu>
"STIGALL        ,JOHN      ,BAC" <stigall%ucs.indiana.edu@usc.edu>
"Steiner, Albert   Northwestern U Acc C" <ASteiner%nucyb.bitnet%acns.nwu.edu@usc.edu>
<John_Robert_Breeden%cup.portal.com%portal%claris%ames%ames.uucp%elroy.uucp@usc.edu>
AFDDN.TCP-IP%GUNTER-ADAM.AF.MIL@usc.edu
Aaron Leonard at UofA Telecommunications <LEONARD%arizona.edu@usc.edu>
Alan S. Watt <swatt%noc.net.yale.edu@usc.edu>
Alan Wu <alw%FENCHURCH.MIT.EDU@usc.edu>
Allen Robel <robelr%bronze.ucs.indiana.edu@usc.edu>
Andrew Boardman <amb%cs.columbia.edu@usc.edu>
Andy.Linton%comp.vuw.ac.nz@usc.edu
Arnold Nipper --- XLINK <nipper%ira.uka.de%RELAY.CS.NET@usc.edu>
Barry Lustig <barry%ads.com@usc.edu>
Ben Yalow <YBMCU%CUNYVM.BITNET@VM.usc.edu>
Bengt Larsson <bengtl%maths.lth.se@usc.edu>
Benzi mizrahi <VSBENZI%WEIZMANN.BITNET%CUNYVM.CUNY.EDU@usc.edu>
Bill Chen <chen%cunixf.cc.columbia.edu@usc.edu>
Bob <Robert.Smart%ditmela.cng.dit.CSIRO.AU@usc.edu>
Bob Currier - DCAC Network Comm. Specialist <currier%cs.duke.edu@usc.edu>
Brian Jay Gould <gould%pilot.njin.net@usc.edu>
Chris Myers <chris%wuarchive.wustl.edu@usc.edu>
Dale Smith <dsmith@oregon.uoregon.edu>
Dave Morton <dave%ecrcvax.uucp%elroy.uucp@usc.edu>
David Waitzman <djw@BBN.COM>
Derick (D.G.) Linegar <LINEGAR%BNR.CA@usc.edu>
Douglas Greenwald <R1DAG%AKRONVM@usc.edu>
Dwight Kruger <DKRUGER%UALTAVM.bitnet%ugw.utcs.utoronto.ca@usc.edu>
Edwin Kremer <edwin%praxis.cs.ruu.nl@usc.edu>
Eric M. Berg <A.Eric%GSB-How.Stanford.EDU@usc.edu>
Francis Dupont <dupont%inria.inria.fr@usc.edu>
Frank J. Robey <fjr%ulana.mitre.org@usc.edu>
Fredrik.Johansson%dc.luth.se@usc.edu
Geoffrey (G.) Kratz <KRATZ%BNR.CA@usc.edu>
George Young <young%vlsi.ll.mit.edu@usc.edu>
Guenter Mueller <gmueller%sun1.ruf.uni-freiburg.de%RELAY.CS.NET@usc.edu>
Harish Pillay <harish@ECE.ORST.EDU>
Harrison Spain - spain@mdcbbs.com <spain@mdcbbs.com>
Hock Koon Lim <lim%cwlim.INS.CWRU.Edu@usc.edu>
Inge Dahl <Inge.Dahl%sintef.no@usc.edu>
JSTIER%ccmail.sunysb.edu@VM.usc.edu
Jason Zions <jason%cnd.hp.com@usc.edu>
Jeffrey Siegal <jbs%FENCHURCH.MIT.EDU@usc.edu>
Jerry Aguirre <jerry%OLIVEY.ATC.OLIVETTI.COM@usc.edu>
Jim Forster <forster%cisco.com@usc.edu>
Jim Hayes <hayes%apple.com@usc.edu>
John Jendro <johnj%jove.cs.pdx.edu%RELAY.CS.NET@usc.edu>
John Romine <jromine%beanie.ICS.UCI.EDU@usc.edu>
Johnny Eriksson <bygg%sunic.sunet.se@usc.edu>
Jonathan Trudel <trudel%revenge.rutgers.edu@usc.edu>
Kannan Varadhan <kannan%osc.edu@usc.edu>
Kent C. Brodie <brodie@fps.mcw.edu>
Luc Ottavj <Luc.Ottavj@mirsa.inria.fr>
MH 6.6 (Eric Brunner) <brunner%ibmpa%ibmsupt.uucp%uunet.UU.NET@usc.edu>
Marc Sheldon <ms%unido.informatik.uni-dortmund.de@usc.edu>
Mark Litwack <litwack@operations.dccs.upenn.edu>
Mark Nagel <nagel@wintermute.ICS.UCI.EDU>
Mark Prior <mrp%ucs.adelaide.edu.au@usc.edu>
Martin Ryan <munnari!phillip.edu.au!MARTIN@uunet.UU.NET>
Martin Walter <root@sun1.ruf.uni-freiburg.de>
Michael Newbery <newbery@mips.vuw.ac.nz>
Michaeljon Miller <mjmiller%snoopy.dsg.honeywell.com@usc.edu>
Nate Hess <nhess%us.oracle.com%oracle.uucp%elroy.uucp@usc.edu>
PLETICHA%MPAD.SPAN%STAR.STANFORD.EDU@usc.edu (Dennis Pleticha/MDSSC-ESD @
Paul E. McKenney <mckenney%itstd.sri.com@usc.edu>
Paul Serrano <Paul_Serrano.BUCKWHEAT%unixmac.synoptics.com@usc.edu>
Phil Draughon <jpd%miata.acns.nwu.edu@usc.edu>
Phil M. Green <pmgreen%gamera.cns.syr.edu@usc.edu>
Pierre (P.) Fortin <FORTINP%BNR.CA@usc.edu>
Pushpendra Mohta <pushp%CERF.NET@usc.edu>
Ralph Pursifull <ralph%hpspdra.spd.hp.com@usc.edu>
Rex Mammel <rexm%uswat.uswest.com@usc.edu>
Rich Kulawiec <rsk%boulder.Colorado.EDU@usc.edu>
Richard H. Miller <rick@pavlov.bcm.tmc.edu>
Richard.Rosenlund%eua.ericsson.se@usc.edu
Ron Rusnak <ronr%tank.uchicago.edu@usc.edu>
Stefan Lundberg <GUCSL%gdmvs.gd.chalmers.se@usc.edu>
Steve Chappelow <swc%kira.uvm-gen.uvm.edu%RELAY.CS.NET@usc.edu>
Steve Kaminski <kaminski%SCL.CWRU.Edu@usc.edu>
Ted Lindgreen <ted%encore.nl@usc.edu>
Tim Flavin <tflavin%pinocchio.encore.com@usc.edu>
Tim Steele <tjfs%tadtec.uucp%NSFnet-Relay.AC.UK@usc.edu>
Ton Roovers <ton%gufalet.uucp%relay.EU.net@usc.edu>
Tor Lillqvist <tml%hemuli.tik.vtt.fi@usc.edu>
Tore Larsen <tore%sfd.uit.no@usc.edu>
Wayne Clark <waynec%wayland.ens.tek.com%RELAY.CS.NET@usc.edu>
William "Chops" Westfield <BILLW%MATHOM.CISCO.COM@usc.edu>
acbhour@cc.ruu.nl (Rudi van Houten)
alanb%world.std.com@usc.edu (Alan R Bleier)
andy%homxb.att.com@usc.edu
attcan!darkover!seachg!jalsop@gpu.utcs.toronto.edu (John Alsop)
aubry%stisun5.epfl.ch%CUNYVM.CUNY.EDU@usc.edu (Georges AUBRY)
baker%VITAM6.uucp%uunet.UU.NET@usc.edu (Fred Baker)
barbe%sdr.SLB.COM@usc.edu (Claude Barbe - SDR - 1 203 431 5524)
bbryan%pdn.paradyne.com%rutgers.uucp@usc.edu (Bill Bryan)
bede%linus.mitre.org@usc.edu
bierma%nprdc.navy.mil@usc.edu (Larry Bierma)
carl%csli.Stanford.EDU@usc.edu (Carl Schaefer)
casper%fwi.uva.nl@usc.edu
ccef001%emx.utexas.edu@usc.edu (Mark Klotzbach)
cdr%amdcad%ames.uucp%ll-xn.uucp@usc.edu (Carl Rigney)
ches%research.att.com@usc.edu
chris%rt.cs.columbia.edu@usc.edu (Chris Maio)
chrise%hpsrcje.hp.com@usc.edu
christopher raczka <raczka%gldoa.enet.dec.com@usc.edu>
cjy%physics.att.com@usc.edu
csmoko%relay.nswc.navy.mil@usc.edu (Chuck Smoko - E41)
curt%dtix.dt.navy.mil@usc.edu (Curt Welch)
dauerbac%mercury.Tymnet.COM@usc.edu (David Auerbach)
dbaron%MIT.EDU@usc.edu (Dennis Baron)
dcf%scobee.ATT.COM@usc.edu
dd%ariel.unm.edu@usc.edu
ddl%husc6.harvard.edu@usc.edu (Dan Lanciani)
despond%stisun3.epfl.ch%CUNYVM.CUNY.EDU@usc.edu (Yves DESPOND)
dixon@pdn.paradyne.com (Tom Dixon)
dklein%pueblo.att.com@usc.edu
dsill%relay.nswc.navy.mil@usc.edu
dupuy%hudson.cs.columbia.edu@usc.edu (Alexander Dupuy)
ereed%leadsv.uucp%elroy.uucp@usc.edu (Ed Reed)
euatdt@euas17.ericsson.se (Torsten Lif)
generous%dev.dtic.dla.mil@usc.edu (Curtis Generous)
ggw%wolves.UUCP%duke.cs.duke.edu@usc.edu (Gregory G. Woodbury)
gil@banyan.banyan.com  (Gil Pilz@Eng@Banyan)
gr%pogo.amd.bnl.gov@usc.edu (George Rabinowitz)
guyton%condor%rand.org@usc.edu
haas%cs.utah.edu@usc.edu (Walt Haas)
hamlin%afit-ab.arpa@usc.edu (Joe Hamlin)
harker%fsdcupt.csd.mot.COM ?@usc.edu  (Robert Harker, Motorola FSD, 408-864-2790)
he%idt.unit.no@usc.edu
hedrick%cs.rutgers.edu@usc.edu
hks%funet.fi@usc.edu (Harri Salminen)
hoshino%kz.tsukuba.ac.jp@usc.edu (Tsutomu Hoshino)
howard%ericsson.se@usc.edu (Howard Gayle)
ibmsupt!ibmpa!cslater@uunet.UU.NET (Charlie Slater)
jaa%genesis.net.com@usc.edu (Jesse Adam)
jacobs%ficc@uunet.UU.NET (Carl R. Jacobs)
james lin <yeejang@hpindda.hp.com>
jbc%cs.utexas.edu@usc.edu (John B. Chambers)
jconti@skat.usc.edu (John Conti)
jdr%semi.harris-atd.com@usc.edu (Jim Ray)
jer%lzaz.att.com%rutgers.uucp@usc.edu
jh%funet.fi@usc.edu (Juha Hein{nen)
jjb%cs.wayne.edu@usc.edu
jls2%ursa-major.SPDCC.COM@usc.edu (Jeff Stoner)
jms%tardis.Tymnet.COM@usc.edu (Joe Smith)
johns%house.uucp%uunet.UU.NET@usc.edu (John Schnizlein)
ken@kericks.chi.il.us (Ken Erickson)
kph%cisco.com@usc.edu
krishnan%cs.uh.edu@usc.edu (Krishnan Parameshwaran)
kross%ihlpa.att.com@usc.edu
kwe%buitb.bu.edu@usc.edu (Kent England)
latzko%cs.rutgers.edu@usc.edu
lengge%chx400.uucp@usc.edu
linimon%attctc.dallas.tx.us%rutgers.uucp@usc.edu (Mark Linimon)
lloyd%aplcen.apl.jhu.edu@usc.edu (Lloyd W. Taylor)
lol%SJ.ATE.SLB.COM@usc.edu
mark@cblpf.att.com (Mark R Horton)
mcb%presto.ig.com@usc.edu (Michael C. Berch)
mcohen%homxa.att.com@usc.edu
mende%cs.rutgers.edu@usc.edu
merlin%smu.uucp%uunet.UU.NET@usc.edu (David Hayes)
mikes%zephyr.ens.tek.com%RELAY.CS.NET@usc.edu
mills%ll-xn.uucp%granite.cr.bull.com@usc.edu
morgan%jessica.Stanford.EDU@usc.edu
munnari!bunyip.cc.uq.oz.au!miw@uunet.UU.NET (Mark Williams)
munnari!lv.sait.edu.au!Chris.Rusbridge@uunet.UU.NET
mvw%KUB.NL%CUNYVM.CUNY.EDU@usc.edu
naftoli@aecom.yu.edu (Robert N. Berlinger)
netmgr%finsun.CSC.FI@usc.edu
news%m2xenix%intelhf.hf.intel.com%rutgers.uucp@usc.edu (Randy Bush)
newton%einstein.eds.com%rutgers.uucp@usc.edu (Richard E. Newton)
nlm%ulysses.att.com@usc.edu
paul%oxy.edu@usc.edu (Paul Hubbard)
perttula%pepper.rc.Nokia.Fi@usc.edu (Pasi Perttula RC 905)
pte900%aarnet.anu.oz.au@usc.edu (Peter Elford)
rbp%well.sf.ca.us%rutgers.uucp@usc.edu (Bob Pasker)
rbthomas%jove.rutgers.edu@usc.edu
rcjoep%gate.urc.tue.nl@usc.edu (Joep Brand)
remaker%pepsi%amdcad%ames.uucp%ll-xn.uucp@usc.edu (Phillip A. Remaker)
rene%yzrnur.uucp@usc.edu (Rene)
rhott%volleydog.nswc.navy.mil@usc.edu
richardt@Legato.COM (Richard Threadgill)
roes%seri.philips.nl@usc.edu (Aloys Roes)
root%naucse%naucse.uucp%cs.arizona.edu@usc.edu (Paul Balyoz)
rpa%lzaz.ATT.COM@usc.edu
rsparbe%relay.nswc.navy.mil@usc.edu (Robert Sparbel - E41)
russell%acf5.NYU.EDU@usc.edu (Bill Russell)
sartin%hplcip%hplabs.hp.com@usc.edu
shore%adobe.com@usc.edu (Andrew Shore)
smb%ulysses.att.com@usc.edu
snorthc%relay.nswc.navy.mil@usc.edu
spa%fctunl.rccn.pt@VM.usc.edu (Salvador Pinto Abreu)
spurgeon%emx.utexas.edu@usc.edu (Charles Spurgeon)
ssid%mtuxo.att.com@usc.edu
steve%wattres%claris.uucp%ames.arc.nasa.gov@usc.edu (Steve Watt)
svenole%vest.sdata.no@usc.edu
sweeny%ucs.indiana.edu@usc.edu
sylvain@chorus.fr (Sylvain Langlois)
tdrake%relay.nswc.navy.mil@usc.edu
tds%tds386e.att.com@usc.edu
thos%gargoyle.uchicago.edu@usc.edu
timsmith%Sun.COM@usc.edu (Timothy G. Smith - Technical Consulting)
tkevans%fallst%wb3ffv.ampr.org%rutgers.uucp@usc.edu
tli@alcor.usc.edu (Tony Li)
tombre@loria.crin.fr (Karl Tombre)
trent%coyote.Colorado.EDU@usc.edu
vaillan%ireq.hydro.qc.ca@usc.edu (C.Vaillancourt Hydro-Quebec QC 514-652-8238)
vbarnes%relay.nswc.navy.mil@usc.edu
wuu%mtfmd.att.com@usc.edu (John T Wuu)
xanadu!STella@uunet.uu.net
yendor%homxc.att.com@usc.edu
Tony Li - USC Computer Science Department
Internet: tli@usc.edu Uucp: usc!tli
Thus spake the master programmer: "A well written program is its own
heaven; a poorly-written program its own hell."
-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Mar 90 20:20:00 GMT
From:      apollo!apollo.hp.com!mishkin@eddie.mit.edu  (Nathaniel Mishkin)
To:        tcp-ip@nic.ddn.mil
Subject:   Curious SMTP behavior
I'm trying to figure out why I'm having difficulty talking to certain
SMTP servers.  Here's a sample dialog (output from my SMTP client):

    Running AA18102
    <cstacy@BBN.COM>,<gildea@BBN.COM>... Connecting to BBN.COM (tcp)...
    220 bbn.com Server SMTP (Complaints/bugs to:  Postmaster@BBN.COM)
    >>> HELO amway.apollo.com
    250 bbn.com - you are a charlatan
    >>> MAIL From:<wba@apollo.com>
    451 Nameserver timeout during parsing
    >>> QUIT
    221 bbn.com says goodbye to amway.ch.apollo.hp.com at Thu Mar  1 14:24:51.
    <cstacy@BBN.COM>,<gildea@BBN.COM>... Deferred: No such file or directory

I understand why the "you are a charlatan" message is coming out.
(Presumably the server is back mapping my IP address and noticing that
it doesn't map to "amway.apollo.com".)  This is just a nuisance message,
as far as I can tell.  The real problem is the:

    >>> MAIL From:<wba@apollo.com>
    451 Nameserver timeout during parsing

Does anyone out there know what the SMTP server is trying to do that
might induce it to print out that message?  All I can imagine is that
the server is trying to resolve "apollo.com" (although it's not really
clear why it'd bother).  As far as I know, no one else is having problems
resolving "apollo.com".

Thanks for any help.


                    -- Nat Mishkin
                       Hewlett Packard Company / Apollo Systems Division
                       mishkin@apollo.com
-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      Fri, 02 Mar 90 07:08:53 -0500
From:      vcerf@NRI.Reston.VA.US
To:        owen@dg-rtp.dg.com
Cc:        scs@vax3.iti.org, keith%spider.co.uk@relay.cs.net, tcp-ip@nic.ddn.mil, bind@ucbarpa.berkeley.edu, vcerf@NRI.Reston.VA.US
Subject:   Re: Use Domain In Hostname Or Not?
I suggest that the important rule to follow is that any 
mail you export from a local domain which goes out on
the Internet always bear a fully qualified domain name
on all addressees. What you do with message copies internally
is your business, but we need fully qualified names on anything
flowing to the rest of the world.

Vint Cerf
-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Fri, 02 Mar 90 13:04:42 -0800
From:      "Milo S. Medin" (NASA ARC NSI Project Office) <medin@nsipo.nasa.gov>
To:        zaphod.mps.ohio-state.edu!mips!bridge2!jarthur!polyslo!rnicovic@tut.cis.ohio-state.edu (Ralph Nicovich)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Routing and Multiple Subnets on one net

Ralph, I think you are the victim of excessive layering.  The problem 
is that while routers are not to forward broadcasts, they determine
what is a broadcast by looking at the destination IP address, and
NOT the MAC level header.  So if you run with multiple subnets on
a physical cable, you will typically also have multiple broadcast
addresses as well.  If a router then recieves a broadcast packet 
for a destination IP address other than the broadcast address 
configured into it's interface, it will try and forward it!

Personally, I consider every router guilty of this in violation of RFC-1009.
Though several quite respected people disagree with me on this.  The
real fix to modify the internal data structures from the driver to the 
IP forwarder to tag the de-encapsulated (de-ecapsulated from the link 
level that is) IP packet with a pseudo-header that keeps the information
about whether or not it was recieved via a MAC level multicast (broadcast
is a specific case of multicasting), and NEVER forward it in this case.
I'm told this is being doing in 4.4 BSD, but I would encourage folks
to beat up their router vendors to do this as well.  It violates the
principle of maximum robustness to do otherwise...

It's silly to throw away good information you pick up at layer 2, and
then use a hueristic to try and get around this at layer 3.  You can
never forward things with both 0's and 1's destination addresses, or
net broadcasts, or subnet broadcasts, but all this trys to fix
the symptoms, and not the problem, which is throwing away very 
valuable level 2 info.

					Thanks,
					   Milo
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Mar 90 10:48:05 PST
From:      braden@venera.isi.edu
To:        tcp-ip@nic.ddn.mil, zaphod.mps.ohio-state.edu!uwm.edu!bionet!hayes!wisner@tut.cis.ohio-state.edu
Subject:   Re:  gathering network statistics
Try NNStat/statspy.  THere is a file named pub/NNStat.tar.Z available for
anonymous FTP from host venera.isi.edu.  See also pp 200-209 in 1988
ACM SIGCOMM proceedings.

There is a person named Kannan at Ohio State who has played extensively
with statspy.

Bob Braden

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Mar 90 09:18:00 EST
From:      TANNERC@CRNL.AECL.CA
To:        TCP-IP@NIC.DDN.MIL
Subject:   MX Records
We are in the process of setting up a name server, and are wondering
about MX and A records. For example, is it possible to set things up
so that FTP requests go to one IP address, and MAIL messages go to
another.

Thanks in advance for your help.

Chris Tanner                  TANNERC@CRNL.AECL.CA
Chalk River Nuclear Labs
-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 90 05:49:55 GMT
From:      mcdchg!laidbak!stevea@rutgers.edu  (Steve Alexander)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP bind question
In article <862@wrs.wrs.com> hwajin@wrs.wrs.com (Hwa Jin Bae) writes:
>Talk about trivial differences.  The options data structure differs in
>varying degrees but for all pratical purposes the differences can be
>resolved ....

Sure, but they shouldn't have to be.  The differences between 4.3BSD and
System V Release 3 can be resolved too, but it's a waste of time.  Why 
should I write the same code N different times in slightly different ways?
If I #ifdef my TP0 implementation for WIN, ISC, and LAI, that's great, but
what happens the when some other implementation comes along?

>I don't like Fascism.

Neither do I.  That's not the point.  The point is that there's more to
a transport interface than primitives to support connecting, sending data, 
and disconnecting.  Someone, either AT&T, or a group of interested vendors, 
should do protocol bindings for TLI, and define address formats, options, 
device names and so forth for TCP and UDP.  Then TLI programs that want 
to access a TCP/IP transport stack could be written knowing that they 
would work regardless of the underlying TCP/IP implementation.  Similar 
definitions could be developed for other types of transports.  What's 
fascist about that?  If you don't like fascism, don't use TLI or sockets.  
Write your own transport interface and use that.  Strike a blow for freedom. 
Just don't expect anyone else to use it, because it would be fascist to 
force it on us.  

As an implementor of TCP/IP, I don't care what the address and options
formats are as long as they work.  As a user of TCP/IP, I care because
I want my programs to be portable.  Portable does not mean #ifdef'd.  
#Ifdef'ing only means that my program is portable to the systems that
I've ported it to.  I want it to be portable to as many systems as possible
without modification.  I can't do that with the current mess.

--
Steve Alexander, Software Technologies Group    | stevea@i88.isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 90 12:58:00 EST
From:      "HQEIS::MCDANIEL" <mcdaniel%hqeis.decnet@hqafsc-vax.af.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   RE: *.JHUAPL.EDU -- SERIOUS GATEWAY THRASHING
Andrews AFB

                  I N T E R O F F I C E   M E M O R A N D U M

                                        Date:     02-Mar-1990 11:46am EST
                                        From:     Mr Rodney McDaniel
                                                  MCDANIEL
                                        Dept:     HQ AFSC/SCXP
                                        Tel No:   AV 858-7909 COMM 981-7909
                                        Owner:    Mr Rodney McDaniel

TO:  _MAILER!                             ( _DDN[TCP-IP@NIC.DDN.MIL] )
TO:  _MAILER!                             ( _DDN[NIC@NIC.DDN.MIL] )

CC:  _MAILER!                             ( _DDN[RON@MANTA.NOSC.MIL] )
CC:  _MAILER!                             ( _DDN[CURT@DTIX.DT.NAVY.MIL] )

Subject: RE: *.JHUAPL.EDU -- SERIOUS GATEWAY THRASHING


HAS ANYONE THOUGHT ABOUT CONTACTING THE FOLLOWING OFFICES RELATING 
TO DDN MILNET PROBLEMS:

CONUS MILNET MONITORING CENTER
AUTOVON 222-2268/5726
COMM: 202-692-2268/5726
EMAIL ADDRESS:  DCA-MMC.DCA-EMS.DCA.MIL

CONUS TROUBLE DESK (MILNET & DSNET)
1-800-451-7413
AUTOVON 231-1787
COMM: 202-486-1982

NAVY POINT OF CONTACT:
THIS FOLLOW-UP PROBLEM WAS FURTHER IDENTIFIED BY A TWO NAVY.MIL
SYSTEMS.

NAVAL TELECOMMUNICATIONS COMMAND     AUTOVON 292-0381
ATTN: N521                           COMM: 202-282-0381
4401 MASSACHUSETTS AVENUE NW         EMAIL: NAVTELCOM@DDN2.DCA.MIL
WASHINGTON, DC 20390-5290

DCA/DDOM (B651)
WASHINGTON, DC 20305-2000
MAJOR CORDER - MILNET MANAGER
AUTOVON 222-7580
COMM: 202-692-7580
EMAIL ADDRESS: MILNETMGR@DDN3.DCA.MIL

THIS INFORMATION IS AVAILABLE IN DDN NEWSLETTER #56, STORED ON THE 
NIC.DDN.MIL, <TACNEWS> MENU ITEM 6. OPTION, VIA TELENET, BY 
CALLING 1-800-235-3155 OR SENDING A REQUEST TO: NIC@NIC.DDN.MIL 
(USER ASSISTANCE) THIS NEWSLETTER PROVIDES THE POINTS OF CONTACT 
FOR DDN PROBLEMS.  PLEASE NOTE: A NEW DDN NEWSLETTER #57 IS 
FORTHCOMING AND A DRAFT CAN BE OBTAINED SAME AS ABOVE OR USING FTP
AND REQUESTING NETINFO:WHO-DDN.TXT AND PROVIDES ALL THE DCA DDN 
PROGRAM OFFICE FUNCTIONS AND PERSONNEL.
HOWEVER, STILL AWAITING THE DDN NIC TO POST AN UPDATED VERSION OF 
DDN NEWSLETTER #56, DATED 8 JUN 88.   HOPE THIS HELPS DIRECTING 
THE PROBLEM INTO THE PROPER CHANNELS.   PLUS, DCA IS RESPONSIBLE 
FOR THE MAILBRIDGES BETWEEN MILNET & INTERNET SO SUGGEST THIS BE 
DIRECTED TO THE DDN MILNET POC'S LISTED ABOVE FOR WORKING A 
POSSIBLE EGP PROBLEM.  WOULD LIKE TO SEE A SUMMARY RESPONSE ON HOW 
THE PROBLEM WAS CORRECTED ON THE TCP-IP MAILER.

RODNEY A. MCDANIEL, DAFC
AIR FORCE SYSTEMS COMMAND
DDN PROGRAM MANAGER
EMAIL: MCDANIEL@HQAFSC-VAX.AF.MIL
ANDREWS AFB MD - AUTOVON 858-7909 - COMM: 301-981-7909



-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 90 07:59:00 GMT
From:      mcsun!hp4nl!ruuinf!praxis!edwin@uunet.uu.net  (Edwin Kremer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Curious SMTP behavior
In article <48f06f20.20b6d@apollo.HP.COM> mishkin@apollo.HP.COM (Nathaniel
Mishkin) writes:

   | I'm trying to figure out why I'm having difficulty talking to certain
   | SMTP servers.  Here's a sample dialog (output from my SMTP client):
   |     >>> MAIL From:<wba@apollo.com>
   |     451 Nameserver timeout during parsing

   | Does anyone out there know what the SMTP server is trying to do that
   | might induce it to print out that message?

I've seen a (almost) similar behaviour on our sendmail daemon some time
ago: it happened if sendmail was able to find the IP address for the
domain it was resolving (in this case "apollo.com") *but* was unable to
find MX records for that domain. By then, I concluded that it must be
silly to define an IP address in the nameserver, and not to add MX records.

Well, I just DIGged "apollo.com" and... yep, no MX records.


	Hope this helps,
						--[ Edwin ]--
--
Edwin Kremer (SysAdm), Dept. of Computer Science, Utrecht University
Padualaan 14,   P.O. Box 80.089,  3508 TB  Utrecht,  The Netherlands
Telephone: +31-30-534104  | UUCP: ...!uunet!mcsun!hp4nl!ruuinf!edwin
Telefax  : +31-30-513791  | Email: edwin@cs.ruu.nl    [131.211.80.5]
-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 90 08:13:44 GMT
From:      mcsun!hp4nl!ruuinf!praxis!edwin@uunet.uu.net  (Oberman, Kevin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Curious SMTP behavior
In article <2556@ruuinf.cs.ruu.nl>, edwin@praxis.cs.ruu.nl (Edwin Kremer) writes...
>I've seen a (almost) similar behaviour on our sendmail daemon some time
>ago: it happened if sendmail was able to find the IP address for the
>domain it was resolving (in this case "apollo.com") *but* was unable to
>find MX records for that domain. By then, I concluded that it must be
>silly to define an IP address in the nameserver, and not to add MX records.
> 
>Well, I just DIGged "apollo.com" and... yep, no MX records.

Hmm. This clearly indicates a bad mailer. RFC1123 makes it clear that an MX
record should not be required for all nodes, only those providing gateway
services of come sort.

The specific flow of the lookup should be to query for an MX record first and
if any are found, try to get IP addresses for them in the order of the value of
their preferences. If 2 domains show identical preferences, the system to use
should be chosen at random. If no MX record is found, then a direct A query is
made and any respose is used as the address. Very few systems in the world have
MX records.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 90 19:27:00 PST
From:      Leo J McLaughlin <ljm@TWG.COM>
To:        tcp-ip <tcp-ip@nic.ddn.mil>
Subject:   Re: TCP under MS-Windows

>Is there any one who has a TCP communication program working under MS-Windows?
>
>We tried to use TCP of FTP Software and WIN/TCP of Wollongong,
>but with both versions we are having problems with the first
>'socket' call.  TCP of FTP is crashing and WIN/TCP of Wollongong
>gives the error(19) "no such device".

Our latest release, WIN/TCP for DOS 4.1 (and it's sibling WIN/API native
and socket libraries), work under MS-Windows.  Sorry for the delay, it took
a little time to re-verify that all the API stuff works.

enjoy,
leo j mclaughlin iii
Manager of Microcomputer Networking
The Wollongong Group
ljm@twg.com

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 90 11:51:34 GMT
From:      van-bc!skl@ucbvax.Berkeley.EDU  (Samuel Lam)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP or PPP support (opinions wanted)
In article <765@syteke.be>, jim@syteke.UUCP (Jim Sanchez) wrote:
>My Company is thinking about trying to support something such as SLIP
>on our terminal server ports.  With PPP now becoming defined and SLIP
>still kinda implementation specific, what does the net think about the
>advisability of moving to PPP.  Of course, the no-brainer answer would
>be to do both but that costs time and money :-).

It's really only half a "no-brainer" answer, depending on which
protocol you implement first...

If you implemented PPP first, then doing SLIP will only take a tiny
little bit more time.

However, if you implemented SLIP first, doing PPP will take a *lot*
longer.

In short, SLIP is small, PPP is huge.  If you alreday did PPP, you
might as well do SLIP so you can say you have both.  But if you
have only done SLIP, then doing PPP just so that you can claim you
have both is not worth it.

There isn't any common code you could use for both SLIP and PPP.  So
having done one does not give you a head start on the other.

My opinion is to do SLIP first (this will buy you time) and then
do PPP after that.  This way you can talk to existing SLIP entities
right away, and by the time your PPP is ready there will hopefully
be some other PPP entities around for you to talk to.

...Sam
-- 
Internet: <skl@wimsey.bc.ca>	UUCP: {van-bc,ubc-cs,uunet}!wimsey.bc.ca!skl
-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      Fri, 2 Mar 90 14:14:10 -0100
From:      Philippe Prindeville <philipp@Gipsi.Gipsi.Fr>
To:        TCP-IP <tcp-ip@nic.ddn.mil>
Subject:   SunOS 4.0 and BOOTP
Hi.

	I'm trying to port the CMU BOOTP code to our local environment
and not having much luck.  The problem seems to be a bad mix of our
local configuration and SunOS 4.0.  We are using an un-subnetted class
C network number, with '0' as the broadcast address.  Unfortunately,
our BOOTP clients don't know their own address and netmask and hence
will only respond to 255.255.255.255 as the broadcast address, rather
than the local broadcast of X.X.X.255 or X.X.X.0.  The interface must
be kept configured to this mode on the Suns for compatibility with the
other (older and more broken) machines.

	So, my question is:  Is there a way (by manipulating socket
options or whatever) to force a packet to be broadcast on a selected
interface to the all-ones address even if the interface is configured
to another broadcast address?

	Please reply to me directly (our local distribution is a little
flakey).

Thanks,

-Philip
-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 90 15:12:33 GMT
From:      mcsun!unido!rmi!infoac!rmohr@uunet.uu.net  (Rupert Mohr)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP to ISDN Gatway Box
I am trying to find a gateway box that would sit as a node on a tcp-ip
ethernet LAN and pass packets to a ISDN WAN. Has anyone out there had any
experience with such a box? Any suggestions of a possible vendor?

Thanks for the help!

Rupert
-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 90 16:34:55 GMT
From:      sun-barr!newstop!texsun!smunews!ti-csl!ticipa!rick@apple.com  (Rick Carlos)
To:        tcp-ip@nic.ddn.mil
Subject:   RFC1045: Versatile Message Transaction Protocol (VMTP)
Does anyone know of the existence of VMTP implementations?
I need this sort of protocol for a project I'm working on.
Any VMTP information (other than what's in RFC1045) is welcomed.

--
Rick Carlos                  Internet: rick@ticipa.ti.com
Texas Instruments, Inc.          UUCP: ti-csl!ticipa!rick
P.O. Box 655012                 Voice: (214)917-2220
MS 3635                        TI-MSG: FSIC
Dallas, Tx.   75265         TI-DECNET: ticipa::rick
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 90 17:58:00 GMT
From:      mcdaniel%hqeis.decnet@HQAFSC-VAX.AF.MIL ("HQEIS::MCDANIEL")
To:        comp.protocols.tcp-ip
Subject:   RE: *.JHUAPL.EDU -- SERIOUS GATEWAY THRASHING

Andrews AFB

                  I N T E R O F F I C E   M E M O R A N D U M

                                        Date:     02-Mar-1990 11:46am EST
                                        From:     Mr Rodney McDaniel
                                                  MCDANIEL
                                        Dept:     HQ AFSC/SCXP
                                        Tel No:   AV 858-7909 COMM 981-7909
                                        Owner:    Mr Rodney McDaniel

TO:  _MAILER!                             ( _DDN[TCP-IP@NIC.DDN.MIL] )
TO:  _MAILER!                             ( _DDN[NIC@NIC.DDN.MIL] )

CC:  _MAILER!                             ( _DDN[RON@MANTA.NOSC.MIL] )
CC:  _MAILER!                             ( _DDN[CURT@DTIX.DT.NAVY.MIL] )

Subject: RE: *.JHUAPL.EDU -- SERIOUS GATEWAY THRASHING


HAS ANYONE THOUGHT ABOUT CONTACTING THE FOLLOWING OFFICES RELATING 
TO DDN MILNET PROBLEMS:

CONUS MILNET MONITORING CENTER
AUTOVON 222-2268/5726
COMM: 202-692-2268/5726
EMAIL ADDRESS:  DCA-MMC.DCA-EMS.DCA.MIL

CONUS TROUBLE DESK (MILNET & DSNET)
1-800-451-7413
AUTOVON 231-1787
COMM: 202-486-1982

NAVY POINT OF CONTACT:
THIS FOLLOW-UP PROBLEM WAS FURTHER IDENTIFIED BY A TWO NAVY.MIL
SYSTEMS.

NAVAL TELECOMMUNICATIONS COMMAND     AUTOVON 292-0381
ATTN: N521                           COMM: 202-282-0381
4401 MASSACHUSETTS AVENUE NW         EMAIL: NAVTELCOM@DDN2.DCA.MIL
WASHINGTON, DC 20390-5290

DCA/DDOM (B651)
WASHINGTON, DC 20305-2000
MAJOR CORDER - MILNET MANAGER
AUTOVON 222-7580
COMM: 202-692-7580
EMAIL ADDRESS: MILNETMGR@DDN3.DCA.MIL

THIS INFORMATION IS AVAILABLE IN DDN NEWSLETTER #56, STORED ON THE 
NIC.DDN.MIL, <TACNEWS> MENU ITEM 6. OPTION, VIA TELENET, BY 
CALLING 1-800-235-3155 OR SENDING A REQUEST TO: NIC@NIC.DDN.MIL 
(USER ASSISTANCE) THIS NEWSLETTER PROVIDES THE POINTS OF CONTACT 
FOR DDN PROBLEMS.  PLEASE NOTE: A NEW DDN NEWSLETTER #57 IS 
FORTHCOMING AND A DRAFT CAN BE OBTAINED SAME AS ABOVE OR USING FTP
AND REQUESTING NETINFO:WHO-DDN.TXT AND PROVIDES ALL THE DCA DDN 
PROGRAM OFFICE FUNCTIONS AND PERSONNEL.
 HOWEVER, STILL AWAITING THE DDN NIC TO POST AN UPDATED VERSION OF 
DDN NEWSLETTER #56, DATED 8 JUN 88.   HOPE THIS HELPS DIRECTING 
THE PROBLEM INTO THE PROPER CHANNELS.   PLUS, DCA IS RESPONSIBLE 
FOR THE MAILBRIDGES BETWEEN MILNET & INTERNET SO SUGGEST THIS BE 
DIRECTED TO THE DDN MILNET POC'S LISTED ABOVE FOR WORKING A 
POSSIBLE EGP PROBLEM.  WOULD LIKE TO SEE A SUMMARY RESPONSE ON HOW 
THE PROBLEM WAS CORRECTED ON THE TCP-IP MAILER.

RODNEY A. MCDANIEL, DAFC
AIR FORCE SYSTEMS COMMAND
DDN PROGRAM MANAGER
EMAIL: MCDANIEL@HQAFSC-VAX.AF.MIL
ANDREWS AFB MD - AUTOVON 858-7909 - COMM: 301-981-7909

-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 90 19:53:38 GMT
From:      mailrus!umich!pmsmam!pmsmam.uucp!wwm@tut.cis.ohio-state.edu  (Bill Meahan)
To:        tcp-ip@nic.ddn.mil
Subject:   PC Net/TCP-IP gateway sought
Our site currently has a group of "technical" computers (HP minis, 9000/300
and 9000/800 series, HP-UX) where information for our CIM and Manufacturing
Engineering activities reside.

But, on each engineer/manager desk is an IBM PS/2 (the corporate "Office
Automation Solution").  All the PS/2's connect to PC-Net for remote printing,
connection (through a 3720 gateway) to the corporate mainframes, and access to
a file server (IBM).

We would like to find a gateway that would allow the engineer to use his/her
desktop PC as a terminal into the UNIX systems for access to the information
there.  Currently, many of the PS/2's are ALSO connected to an Allen-Bradley
VistaLAN/1 (through their serial port) so that they CAN access the UNIX systems.
This is a kludge!

Does anyone know of a product (hardware and software) that would allow
"terminal" traffic on the PC-Net to be gatewayed into telnet sessions on an
Ethernet?  Better yet, an X-server so that the engineer could use the PS/2
as an X-terminal into the UNIX systems using ONLY the PC-Net connection
on the back?

All replies, followups, etc. gratefully accepted (but no flames about the
PC-Net please, the corporate bigwigs INSIST on using it).
-- 
Bill Meahan			|  UUCP: uunet!mailrus!umich!pmsmam!wwm
				| snail: 128 Factory St., Ypsilanti, MI 48197
#include <disclaimer.std>	| voice: +1 313 484 9320
/* witty */			|packet: wa8tzg @ wa8ooh.mi.usa.na
-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 90 22:07:55 GMT
From:      david@g.ms.uky.edu  (David Herron -- a slipped disk)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Curious SMTP behavior
>Well, I just DIGged "apollo.com" and... yep, no MX records.

This shouldn't make any difference.  The SMTP daemon he's talking about
is MMDF which makes the assumption that a lack of MX records but a
presence of A records implies A => MX.


-- 
<- David Herron; an MMDF guy                              <david@ms.uky.edu>
<- ska: David le casse\*'      {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-
<- Now arrived at a nameserver near you:  david@davids.mmdf.com
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Mar 90 22:18:22 GMT
From:      saryu.cs.umd.edu!dheeraj@mimsy.umd.edu  (Dheeraj Sanghi)
To:        tcp-ip@nic.ddn.mil
Subject:   Time to do IP options in gateways
I am interested in finding out, how much do the use of IP options
slows down the gateways.

I am sending TCP packets from host A to host A via gateway B. So, I am using
IP_LSRR option. Would the intermediate gateways (i.e. between A & B) take a
lot of time in processing the IP options. (How much?)

I am not a frequent reader of this newsgroup. So if this topic has only
recently been discussed, please excuse me.

Thanks a lot,

-dheeraj

--
Dheeraj Sanghi			(h):301-794-6247	(o):301-454-1516
Internet: dheeraj@cs.umd.edu	UUCP: uunet!mimsy!dheeraj
-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      Sat, 03 Mar 90 08:31:07 PST
From:      Van Jacobson <van@helios.ee.lbl.gov>
To:        tcp-ip@nic.ddn.mil, sun-spots@rice.edu
Subject:   new version of tcpdump available
A new version of tcpdump is available for anonymous ftp from
host ftp.ee.lbl.gov (128.3.254.68), file tcpdump.tar.Z.  (This
is a compressed Unix tar file and must be ftped in *binary*
mode.)  This version runs on both Sun-3s and Sun-4s (including
the Sparcstation-1) and under either Sun OS3.x or 4.x.

Attached is a portion of the README file describing what has
changed since the last release.  Enjoy.

 - Van Jacobson, Steve McCanne, Craig Leres
   Lawrence Berkeley Laboratory

 -------------------------
Sat Mar  3 04:45:39 PST 1990

This directory contains yet another beta release of the source
for tcpdump.  We are still in the middle of replacing the Sun
NIT interface with an enhanced version of the CMU/Stanford
packet filter that was distributed with 4.3bsd.  We hope that
the next version of tcpdump will run an any 4bsd system, not
just Suns.  Our intent is to include the new version with the
4.4bsd distribution.

Major changes from the June '89 release to this release are:

 - Sparc architectures, including the Sparcstation-1, are now
   supported thanks to Steve McCanne and Craig Leres.

 - SunOS 4.0 is now supported thanks to Micky Liu of Columbia
   University (micky@cunixc.cc.columbia.edu). To compile, you
   need to define SUNOS4.  You will also need to replace the Sun
   supplied /sys/OBJ/nit_if.o with the appropriate version from
   this distribution's SUNOS4 subdirectory:
	   nit_if.o.sun3	(any flavor of sun3)
	   nit_if.o.sparc	(all Sun4's except for the Sparcstation-1)
	   nit_if.o.sun4c	(Sparcstation-1)
   These nit replacements fix a bug that makes nit essentially
   unusable in Sun OS 4.  In addition, our sun4c nit gives you
   timestamps to the resolution of the SS-1 clock (1 us) rather
   than the lousy 20ms timestamps Sun gives you  (tcpdump will
   print out the full timestamp resolution if it finds it's running
   on a SS-1).

 - IP options are now printed.

 - RIP packets are now printed (RIP printing is partly thanks to
   code contributed by Ken Adelman of TGV).

 - There's a -v flag that prints out more information than the
   default (e.g., it will enable printing of IP ttl, tos and id)
   and -q flag that prints out less (e.g., it will disable
   interpretation of Appletalk-in-UDP).

 - The grammar has undergone substantial changes (if you have an
   earlier version of tcpdump, you should re-read the manual
   entry).  The syntax is more regular than the previous version
   and should be easier to learn and remember.

   The most useful change is probably the replacement of the "byte"
   operator by an arithmetic expression syntax that lets you filter
   on arbitrary fields or values in the packet.  E.g., "ip[0] > 0x45"
   would print only packets with IP options or ST packets,
   "tcp[13] & 3 != 0" would print only TCP SYN and FIN packets.

   The most painful change is that concatenation no longer means
   "and" -- e.g., you have to say "host foo and port bar" instead
   of "host foo port bar".  The up side to this down is that
   repeated qualifiers can be omitted, making most filter
   expressions shorter.  E.g., you can now say "ip host foo and
   (bar or baz)" to look at ip traffic between hosts foo and bar or
   between hosts foo and baz.  [The old way of saying this was "ip
   host foo and (ip host bar or ip host baz)".]

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 90 03:31:45 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:   Re: RFC1045: Versatile Message Transaction Protocol (VMTP)
Rick,

My notes show the VMTP archives available for anonymous FTP at
gregorio.stanford.edu, in the directory vmtp-ip.  Should be exactly
what you're looking for.

By the way, I'm keeping track of all of the implementations of
"obscure" RFCs other than the standard ones -- my list isn't ready for
public use yet, it's still real ugly, but eventually I'm looking to
make it publicly available.

--Ed

Edward Vielmetti, U of Michigan math dept.
emv@math.lsa.umich.edu
-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      3 Mar 90 04:25:57 GMT
From:      tolsoft!hahn@ucbvax.Berkeley.EDU  (John Hahn)
To:        tcp-ip@nic.ddn.mil
Subject:   IP-X25: Whatif no calling x25 addr?
I am in the midst of implementing an IP-X25 solution for my company's Unix
based OS. One issue which I am trying to resolve is the actions that
the IP-X25 software must take on situations which involve incoming X25call
requests to IP.

First of all we are dealing with non-ddn PDN world so that ip-x25 addresses are
mapped from some configuration table. So all incoming call requests require
a calling address which need to be mapped to an ip_address so that this
particular VC will be bound to an ip_address. BUT what can you do if there
is no calling address present?? This is not a required field in X25 spec 
and many do not bother using it. Obviously one can simply require it. One
is tempted to look at the ip datagrams which will be coming through the VC
and extract the src ip_addr and attempt to use it. This src ip addr ,however,
may NOT be the ip addr of the remote IP-X25 host. But even this seem a lot
what better than just refusing the connection.

If any one can share some of their experience in this matter it would be
greatly appreciated. Thanks in advance.

john.
-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      Sun, 04 Mar 90 15:22:08 -0800
From:      "Philip Almquist" <almquist@jessica.Stanford.EDU>
To:        zaphod.mps.ohio-state.edu!mips!bridge2!jarthur!polyslo!rnicovic@tut.cis.ohio-state.edu (Ralph Nicovich)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Routing and Multiple Subnets on one net
Ralph,
> First, we are running multiple (2) subnets on the same physical (DLL)
> network. There are a number of papers that claim this is leagal, but
> perhaps their setup was diferent. In our case the two networks (subnets)
> are 129.65.16.0 and 129.65.160.0, the wrinkle is that the mask on
> 16.0 is ff.ff.f0.00 and on 160.0 it is ff.ff.ff.00 . 

	I don't believe that the IP and subnet specs either explicitly
permit or deny running multiple nets or subnets on the same cable, in large
part (as I understand history) because it didn't occur to their authors that
anyone would want to.  However, it has since become accepted practice in
large parts of the IP community, and I seem to recall that the Host
Requirements RFC's try to ensure that hosts handle this practice correctly.

	Multiple subnet masks on the same net, on the other hand, is still a
very controversial practice, with strong proponents and strong detractors.
One thing that is agreed upon is that using multiple subnet masks requires
great care in choosing masks and assigning addresses in order to avoid the
sorts of problems you report.  I seem to recall that there is some
mathematical analysis of what works and what doesn't in the OSPF spec.
There has also been talk of starting an IETF working group to study the
issue.

> Personaly I would think that any packet that is a broadcast
> at the DLL level should not be automaticaly routed.

	Your view is at odds with the tradional one, but is becoming
fashionable.  My guess is that your view will be incorporated into the next
revision of RFC1009.
							Philip
-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      Sun, 4 Mar 90 10:37:12 PST
From:      art@opal.acc.com (Art Berggreen)
To:        hahn@tolerant.com, tcp-ip@nic.ddn.mil
Subject:   Re:  IP-X25: Whatif no calling x25 addr?
>I am in the midst of implementing an IP-X25 solution for my company's Unix
>based OS. One issue which I am trying to resolve is the actions that
>the IP-X25 software must take on situations which involve incoming X25call
>requests to IP.

Having been around IP-over-X.25 interfacing for several years, I'll throw
in my $0.02.

>First of all we are dealing with non-ddn PDN world so that ip-x25 addresses are
>mapped from some configuration table. So all incoming call requests require
>a calling address which need to be mapped to an ip_address so that this
>particular VC will be bound to an ip_address. BUT what can you do if there
>is no calling address present?? This is not a required field in X25 spec 
>and many do not bother using it. Obviously one can simply require it. One
>is tempted to look at the ip datagrams which will be coming through the VC
>and extract the src ip_addr and attempt to use it. This src ip addr ,however,
>may NOT be the ip addr of the remote IP-X25 host. But even this seem a lot
>what better than just refusing the connection.

One other possiblity is to accept the call without an IP address bound to it.
This allows incoming traffic to arrive over the circuit but requires a new
outbound circuit to potentially be opened to the same endpoint.  In general
I'd be against looking into the IP header for determining the address binding,
be one can determine if the source address corresponds to the previous hop
by comparing the network part with your own address(es) for the receiving
interface.  Our most recent implementation of IP-over-X.25 for PDNs require
that both the called and calling address be present and map to a known IP
address.  Also, be aware that on some PDNs the CALLED X.25 address can be
received in two formats, one for local calls and one for "international"
calls.

>If any one can share some of their experience in this matter it would be
>greatly appreciated. Thanks in advance.
>
>john.

Make sure you support negotiating as large a packet size and packet window
as possible.  Major performance impacts in this area.
You should also be careful about providing some configurability for the
circuit inactivity timers.  And if you get into managing multiple SVCs to
the same endpoint, there are some non-obvious problems both for X.25 and
for upper layers.   Finally, you might want to look into what the IETF
group on PDN Cluster routing is doing (especially X.25 addresses servers).

Art Berggreen
ACC

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 90 04:09:12 GMT
From:      amdahl!rtech!wrs!hwajin@ames.arc.nasa.gov  (Hwa Jin Bae)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: UDP bind question
In article <1990Mar2.054955.24392@i88.isc.com> stevea@i88.isc.com (Steve Alexander) writes:
>Someone, either AT&T, or a group of interested vendors, 
>should do protocol bindings for TLI, and define address formats, options, 
>device names and so forth for TCP and UDP.

I agree wholeheartedly.  No problems there.  I just don't like a single
vendor defining some bogus standard and forcing it down our throats (as
your original message seemed to suggest, but I guess you didn't mean
that -- AT&T putting pressure on vendors of TCP/IP instead of assisting
some commonly supported conformance specs for protocol bindings based on
consensus).  However, the problem also has to do with not just the lack
of such "standardization" efforts (whatever happened to the X/OPEN thing
that looked very much like TLI?) but the reality of corporate greed and
politics.
-- 
Hwa Jin Bae (hwajin@wrs.com)
Wind River Systems
-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 90 16:18:59 GMT
From:      zaphod.mps.ohio-state.edu!uwm.edu!ogicse!emory!hubcap!ncrcae!cs-col!vause@tut.cis.ohio-state.edu  (Sam Vause, NCR Corporate Customer Services)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP to ISDN Gatway Box
In article <835@infoac.rmi.de> rmohr@infoac.rmi.de (Rupert Mohr) writes:
>I am trying to find a gateway box that would sit as a node on a tcp-ip
>ethernet LAN and pass packets to a ISDN WAN. Has anyone out there had any
>experience with such a box? Any suggestions of a possible vendor?
>
>Thanks for the help!
>
>Rupert

The NCR TOWER family of systems will indeed connect you directly between
TCP-IP and an ISDN such as X.25:  
	TOWER 32/200 w/ OS 1.01.00, WIN-TCP/IP 4.00.01
	TOWER 32/[357]00 w/ OS 1.00.01, WIN-TCP/IP 4.00.01
	TOWER 32/[46][05]0 w/ OS 3.00.01, WIN-TCP/IP 4.00.01
	TOWER 32/8[05]0 w/ OS 2.00.00, WIN-TCP/IP 4.00.01
The base link-level driver (HDLC) and X.25 services (X.25Net) are
also   required.    Additionally,   there   is   an  Host  Packet
Assembler/Disassembler  (HPAD)  product  available   to   provide
library  routines into the X.25 cloud; combined with the TCP/IP<-
>X.25 modules, you can literally run  TCP/IP  over  X.25  between
nodes, whereever they are in the world.  Finally, the is also  an
interface product for direct cloud contact from the TOWER known
as Terminal Packet Assember/Disassembler (TPAD).  It functions
much like a Hardware PAD, except it allows direct cloud access
from your CRT screen.

Hope this helps!
					--sam
+---------------------------------------------------------------+
|Sam Vause, NCR Corporation, Customer Services - TOWER Support  |
|3325 Platt Springs Road, West Columbia, SC 29169 (803) 791-6953|
|                                vause@cs-col.Columbia.NCR.COM  |
|                         ...!uunet!ncrlnk!ncrcae!cs-col!vause  |
|                ...!ucbvax!sdcsvax!ncr-sd!ncrcae!cs-col!vause  |
+---------------------------------------------------------------+
-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 90 16:50:41 GMT
From:      encore!pinocchio.encore.com@husc6.harvard.edu  (Jeff "spackle-man" d'Arcy)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP routers
dlj@proteon.com (Daniel L. Jones):
>    All three router companies that were mentioned, make good products.
> But Proteon has specific advantages:
> [product hype deleted]

I'm sure you're trying to help your company by spreading the word about
their products, and it may even be possible that the marketing division
appreciates your attempt to reduce printing costs by using the net to
distribute their copy.  However, your PR department is probably not too
pleased because such postings give the impression that Proteon is hiring
rude high-pressure salesmen to work in customer service.

Postings of the "yeah, we have one of those" class are generally regarded
as OK, but this sort of "we're better than them and here's some buzzwords
to convince you" posting is inappropriate.



Jeff d'Arcy     OS/Network Software Engineer     jdarcy@encore.com
    DISCLAIMER: I don't represent Encore any more than you do
-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Mar 90 00:53:21 EST
From:      "Phillip G. Gross" <pgross@NRI.Reston.VA.US>
To:        tcp-ip@nic.ddn.mil
Cc:        pgross@NRI.Reston.VA.US
Subject:   Re: IP routers

> Instead of overloading a host with the communciations
> processing of an ever expanding network, dedicate a network device
> to handle the job.   

Good advice.  So far, so good.

> ... But Proteon has specific advantages:  

Coming from a Proteon customer service representative, this is essentially
an advertisement.  Please refrain from this type of abuse of the network
in the future.  If you have any questions about the proper use policy, 
please contact the agency who is sponsoring your Internet connectivity.


> Support for OSPF, a dynamic (IGP) routing protocol, which is standardized. 

Now you have compounded the abuse by giving incorrect information.  

OSPF is not an Internet standard.  It is a PROPOSED Internet standard, 
which is the first stage of a three step process.  Please see RFC 1130 
for details.

Phill Gross, Chair
Internet Engineering Task Force
-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      4 Mar 90 20:04:36 GMT
From:      mailrus!umich!terminator!terminator.cc.umich.edu!bryan@tut.cis.ohio-state.edu  (Bryan Beecher)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP to ISDN Gatway Box
In article <835@infoac.rmi.de> rmohr@infoac.rmi.de (Rupert Mohr) writes:
>I am trying to find a gateway box that would sit as a node on a tcp-ip
>ethernet LAN and pass packets to a ISDN WAN. Has anyone out there had any
>experience with such a box? Any suggestions of a possible vendor?

I'm part of a project that's doing some work on a ISDN-TCP/IP.  (Most
of the work was done before EDUCOM, but there's still a little bit of
development going on.)  Basically, we have a 80386 PC that has both
an Ethernet card and a Teleos card.  Software written by Dory Leifer
(with a little bit from me) looks like an application to the Teleos board
and a packet driver to either KA9Q or FTP Software programs.  Right now
the code will only drive one BRI.  We're now working on getting it to
drive more than one BRI and to handle a PRI.

If anyone wants some more information, you can mail me or Dory (who
reads mail at dory_leifer@um.cc.umich.edu).  If you send me an address
I can also send out one of the leftover glossies we have from EDUCOM.
--
Bryan Beecher, U-M Information Technology Division  (+1 313 747 4050)
Domain:	bryan@terminator.cc.umich.edu  Path: mailrus!terminator!bryan
-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Mar 90 08:15:54 PST
From:      kozel@milano.cisco.com (Edward R. Kozel)
To:        mcsun!unido!rmi!infoac!rmohr@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject:   Re:  TCP/IP to ISDN Gatway Box
Rupert,
	Several customers and RBOCS (at test sites) are using routers
with connections to ISDN via Terminal Adapters.  This works fine,
and appears to be the near term solution for ISDN connectivity.

Ed Kozel

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      Mon, 05 Mar 90 08:14:28 CST
From:      "O'Brennan, Gerry" <C0022@UMRVMB.UMR.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: tn3270 for Apollo or RT?
On Sun, 04 Mar 90 14:12:54 CST Mike Castle said:
>I *believe* that you are one of the people involved in maintenance of the
>Apollo systems (I don't have my docs with me, but your name looks awfully
>familiar).  I thought that you might be interested in this.  I just saw
>this posting on a TCP/IP discussion list via LISTSERV.
>
>************************************************************
>*   Mike Castle  *  Life is like a clock:  You can work    *
>*      Nexus     *  constantly and be right all the time,  *
>* S087891@UMRVMA *  or not work at all and be right at     *
>*                *  least twice a day.                     *
>************************************************************

Yeah, I saw the same thing. I plan on checking into it, but I believe that
this is for the 9.7 OS of Apollo (which we have running) and we need one that
will run under SR10. We have taken the source and beat it to a pulp on SR10
and it won't process the keyboard. Hopefully, Kevin's answer IS for SR10.

Thank you for the information...

Gerry O'Brennan
Acknowledge-To: <C0022@UMRVMB>
-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Mar 90 08:43:51 EST
From:      mep@aqua.whoi.edu (Michael E. Pare)
To:        tcp-ip@nic.ddn.mil, ww0n+@andrew.cmu.edu
Subject:   Re:  Proteon p4200
>Could some kind soul please refresh my memory on the loopback packet
>sent by Proteon p4200 gateways?  As I remember, this packet contains an
>intentional CRC error.  At what rate are these sent?  Our p4200 is
>sending ethernet packets which have *both* the source and destination
>ethernet address set to 02:07:01:00:00:00 (notice all the zeros).  Is
>this "normal"???  The ethernet address of the associated interface is
>supposed to be 02:07:01:01:BF:15.  (Could it be that the interface is. .
>. . broken?!?  :-)

The p4200 issues two test packets every four seconds to the address you
have listed.  Both packets contain identical information (I don't know
what it is) but the first one is intentionally misaligned (not a crc error).
The second packet is good.  SO, no, your interface is not broken.  The
biggest complaint I have about these test packets is that with some
systems, the misaligned packet shows up as a crc error, and you have to
keep this in mind if you are using this system to check for errors on the
network.  (the two packets are issued a few microseconds apart).  Hope this
answers your questions.

Michael Pare, P. Eng.
Woods Hole Oceanographic Institution
Woods Hole, MA 
-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      Mon, 05 Mar 90 14:17:42 PST
From:      Jim Forster <forster@cisco.com>
To:        tcp-ip@nic.ddn.mil
Cc:        mogul@decwrl.dec.com (Jeffrey Mogul)
Subject:   Re: Directed broadcasts??
In response to Warren Gish's question about directed broadcasts, Jeff Mogul
wrote:

>> On the other hand, I think it is nearly universally agreed that if
>> broadcasting is evil, then directed broadcasting is evil compounded.
>> I.e., I wouldn't suggest using them (and as far as I know, few
>> routers implement directed broadcasting).
>>     

The Gateway Requirements RFC, 1009, required that routers support directed
broadcasts.  This subject came up in the IETF Router Requirements meeting,
and will be discussed in the document the group is writing.  The consensus
of the group was that directed broadcasts are sometimes useful but they
should be handled carefully.  In particular, if supported, there should be
provision to administratively disable forwarding of these broadcasts.

We find it useful to allow several replicated instances of network services
(TFTP & DNS servers) to be located on a subnet, in which cases off-subnet
clients can request service with knowing or caring which server responds by
sending a directed broadcast.  This is an example of why it's probably not a
good idea to chant the "broadcasts are evil" mantra in response to every
mention of broadcasts.  (:-)

Jeff's suggestion:

>> Or maybe you should just use the Domain Name System (DNS) to provide some
>> late binding (i.e., assign a nickname to the host that is currently
>> providing the service, and require the clients to look up that nickname
>> whenever they want to use the service).  You can do it today if your
>> software uses DNS (and if it doesn't, fix that first).

may be applicable to to your situation, and if so, is a good suggestion as
the servers may then be located anywhere.


 -- Jim Forster
    cisco Systems
-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 90 07:41:07 GMT
From:      oberman@rogue.llnl.gov (Oberman, Kevin)
To:        comp.protocols.tcp-ip
Subject:   Re: IP routers

In article <9002281630.AA23536@sonny.proteon.com>, dlj@proteon.com (Daniel L. Jones) writes...
> 
>   Instead of overloading a host with the communciations
>processing of an ever expanding network, dedicate a network device
>to handle the job.   
>   All three router companies that were mentioned, make good products.
>But Proteon has specific advantages: 

[Sales pitch for Proteon omitted.]

I'm not really fond of seeing this list used for blatant advertizing, so I'll
have to put in my $0.02.

I am currently involved in the selection of a "standard" router for our
Laboratory network and havbe spent a lot of time looking at the various
available products. ALL have some significant advantages and I don't think
Proteon's are anything overwhelming.

If you are planning to aquire any router type product, I suggest that you look
at the analysis of routers done by Scott Bradner at Harvard. He ran some
(admittedly) less than comprehensive tests on Proteon, cisco, NSC, and
Wellfleet boxes and the numbers were eye opening.

I'm not including any of the results of the tests as I feel that without a
proper explanation of the methodology used and the inclusion of most, if not
all of the numbers generated in the testing, any references would be unfairly
out of context. But I think I can say that Proteon would not be likely to
include this report in their sales literature.

Speed is far from the only (or even the most significant) critereon for the
selection of a router, but it is one of the more important if one is planned
for a busy network link. Other things to worry about is the abiltiy of the
router to handle all of the required protocols. On out LAN we support
AppleTalk, DECnet, DOD IP, OSI, LAT, and IPX. The proper routing/bridging of
all of these protocols is very significant if your net uses them.

If I had the numbers of the sales reps for cisco and Wellfleet, I'd put them
here, but I don't have them handy. So I'll just emphasize that you should be
VERY careful in a router procurement. It may have drastic impact on your net
for a ong time to come. And there are a lot of complex factors that have
significant impact on what the "right" choice is for you. It's a lot more than
just price and performance. And I have yet to find a "perfect" router.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Mar 90 14:34:10 EST
From:      Frank Solensky <solensky%interlan.interlan.com@RELAY.CS.NET>
To:        tcp-ip@NIC.DDN.MIL
Subject:   "TCP header prediction" pointer?
Is there some RFC / journal article that describes the TCP header prediction
algorithm and/or observed results?

Thanks in advance---		Frank Solensky
				  Racal Interlan
-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 90 14:14:28 GMT
From:      C0022@UMRVMB.UMR.EDU ("O'Brennan, Gerry")
To:        comp.protocols.tcp-ip
Subject:   Re: tn3270 for Apollo or RT?

On Sun, 04 Mar 90 14:12:54 CST Mike Castle said:
>I *believe* that you are one of the people involved in maintenance of the
>Apollo systems (I don't have my docs with me, but your name looks awfully
>familiar).  I thought that you might be interested in this.  I just saw
>this posting on a TCP/IP discussion list via LISTSERV.
>
>************************************************************
>*   Mike Castle  *  Life is like a clock:  You can work    *
>*      Nexus     *  constantly and be right all the time,  *
>* S087891@UMRVMA *  or not work at all and be right at     *
>*                *  least twice a day.                     *
>************************************************************

Yeah, I saw the same thing. I plan on checking into it, but I believe that
this is for the 9.7 OS of Apollo (which we have running) and we need one that
will run under SR10. We have taken the source and beat it to a pulp on SR10
and it won't process the keyboard. Hopefully, Kevin's answer IS for SR10.

Thank you for the information...

Gerry O'Brennan
Acknowledge-To: <C0022@UMRVMB>

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      Mon, 5 Mar 90 19:43:00 EST
From:      Chris Tanner <01696%AECLCR.bitnet@ugw.utcs.utoronto.ca>
To:        <TCP-IP@NIC.DDN.MIL>
Subject:   MX Records
We are in the process of setting up a name-server here and have a questions
about A and MX records. I kind-of understand the difference between these
two record types, but is it possible to say set things up so that for a
system name such as XXX.AECL.CA, FTP's would go to one IP address, and
SMTP (mail) would be sent (via an MX record) to another IP address.

We need this since we have a machine with FTP access, but not SMTP access,
there is another machine on site that can send mail to this machine.

Thanks in advance for your ansswers.

Chris Tanner                   01696@AECLCR.BITNET

Chalk River Nuclear Labs

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 90 19:45:44 GMT
From:      dsl.pitt.edu!sean@pt.cs.cmu.edu  (Sean McLinden)
To:        tcp-ip@nic.ddn.mil
Subject:   CMOT availability
Here is probably a frequently asked question: Is anyone able to comment on
available implementations of CMOT? How about those which are distributable?
Source code implementations?

Thanks.

Sean McLinden
Decision Systems Laboratory
University of Pittsburgh
-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Mar 90 22:17:42 GMT
From:      forster@CISCO.COM (Jim Forster)
To:        comp.protocols.tcp-ip
Subject:   Re: Directed broadcasts??

In response to Warren Gish's question about directed broadcasts, Jeff Mogul
wrote:

>> On the other hand, I think it is nearly universally agreed that if
>> broadcasting is evil, then directed broadcasting is evil compounded.
>> I.e., I wouldn't suggest using them (and as far as I know, few
>> routers implement directed broadcasting).
>>     

The Gateway Requirements RFC, 1009, required that routers support directed
broadcasts.  This subject came up in the IETF Router Requirements meeting,
and will be discussed in the document the group is writing.  The consensus
of the group was that directed broadcasts are sometimes useful but they
should be handled carefully.  In particular, if supported, there should be
provision to administratively disable forwarding of these broadcasts.

We find it useful to allow several replicated instances of network services
(TFTP & DNS servers) to be located on a subnet, in which cases off-subnet
clients can request service with knowing or caring which server responds by
sending a directed broadcast.  This is an example of why it's probably not a
good idea to chant the "broadcasts are evil" mantra in response to every
mention of broadcasts.  (:-)

Jeff's suggestion:

>> Or maybe you should just use the Domain Name System (DNS) to provide some
>> late binding (i.e., assign a nickname to the host that is currently
>> providing the service, and require the clients to look up that nickname
>> whenever they want to use the service).  You can do it today if your
>> software uses DNS (and if it doesn't, fix that first).

may be applicable to to your situation, and if so, is a good suggestion as
the servers may then be located anywhere.


 -- Jim Forster
    cisco Systems

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 90 01:45:30 GMT
From:      pacific.mps.ohio-state.edu!ohstpy!miavx1!pemurray@tut.cis.ohio-state.edu
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP connection between PC and Unix w/ KA9Q
Hello.  I've got a small project I'm working on.  I'm trying to get a 
SLIP link from a PC to a Ultrix (Unix) box over a dialup line.  From
what the instructions say, KA9Q should be able to do this.  The software
on the PC works fine, and the source on the Ultrix box compiled and ran,
but I can't figure out how to connect the two.

Any tips would be greatly appreciated.  Thanks in advance!  Post or e-mail,
which ever is convenient or appropriate.

Peter Murray                                  murrayp@apsvax.aps.muohio.edu
Miami University                                      pemurray@miavx1.bitnet
-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Mar 90 14:33:44 -0600
From:      dab@berserkly.cray.com (David Borman)
To:        tcp-ip@nic.ddn.mil, telnet-ietf@timbuk.CRAY.COM
Subject:   TELNET option list update

Hi there.

Attached is a list of all the TELNET options.  This is the list that
will be going into the next revision of the Assigned Numbers RFC.
We need to verify the last column, "USE".  This column states whether
or not that option is in use.  If you see a "no" by a telnet option
that your telnet implementation makes use of, please send me mail so
that we can correct the list.  Those followed by a "?" are those that
the IETF TELNET WG was not sure about when it reviewed this list (at
the Stanford IETF meeting...).

Please send your updates to dab@cray.com (or jkrey@ISI.EDU if for some
reason you can't get mail to me).

		-Dave Borman
		dab@cray.com


      Number   Name                                    RFC  NIC  DPH USE
      ------   ---------------------------------       --- ----- --- ---
         0     Binary Transmission                     856 ----- yes yes
         1     Echo                                    857 ----- yes yes
         2     Reconnection                            ... 15391 yes  no
         3     Suppress Go Ahead                       858 ----- yes yes
         4     Approx Message Size Negotiation         ... 15393 yes  no
         5     Status                                  859 ----- yes yes
         6     Timing Mark                             860 ----- yes yes
         7     Remote Controlled Trans and Echo        726 39237 yes  no
         8     Output Line Width                       ... 20196 yes  no
         9     Output Page Size                        ... 20197 yes  no
        10     Output Carriage-Return Disposition      652 31155 yes  no
        11     Output Horizontal Tabstops              653 31156 yes  no
        12     Output Horizontal Tab Disposition       654 31157 yes  no
        13     Output Formfeed Disposition             655 31158 yes  no
        14     Output Vertical Tabstops                656 31159 yes  no
        15     Output Vertical Tab Disposition         657 31160 yes  no
        16     Output Linefeed Disposition             658 31161 yes  no
        17     Extended ASCII                          698 32964 yes  no
        18     Logout                                  727 40025 yes  no
        19     Byte Macro                              735 42083 yes  no
        20     Data Entry Terminal                     732 41762 yes  no ?
        21     SUPDUP                              734 736 42213 yes  no
        22     SUPDUP Output                           749 45449 yes  no
        23     Send Location                           779 ----- yes  no
        24     Terminal Type                          1091 ----- yes yes
        25     End of Record                           885 ----- yes  no
        26     TACACS User Identification              927 ----- yes  no ?
        27     Output Marking                          933 ----- yes  no
        28     Terminal Location Number                946 -----  no  no
	29     3270 Regime                            1041 -----  no  no ?
        30     X.3 PAD                                1053 -----  no  no
        31     Window Size                            1073 -----  no yes
        32     Terminal Speed Option                  1079 -----  no yes
        33     Remote Flow Control                    1080 -----  no yes
        34     Linemode                               1116 -----  no yes
        35     X Display Location                     1096 -----  no  no ?
       255     Extended-Options-List                   861 ----- yes yes

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Mar 90 13:12:18 PST
From:      braden@venera.isi.edu
To:        dab@berserkly.cray.com, tcp-ip@nic.ddn.mil, telnet-ietf@timbuk.cray.com
Cc:        braden@venera.isi.edu
Subject:   Re:  TELNET option list update
 Used by tn3270/IBM3270 hosts:
 
        25     End of Record                           885 ----- yes  YES
        
I believe both of the following are implemented and used somewhere:
        
        20     Data Entry Terminal                     732 41762 yes  no ?              21     SUPDUP                              734 736 42213 yes  no

Bob Braden
-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Mar 90 16:33:56 -0600
From:      dab@berserkly.cray.com (David Borman)
To:        tcp-ip@nic.ddn.mil, telnet-ietf@timbuk.CRAY.COM
Subject:   New telnet source

I have put a new copy of telnet/telnetd out on ucbarpa.berkeley.edu.
This is a snapshot of the telnet/telnetd from the 4.4BSD development
source.  It is available via anonymous ftp, and is in the file
	pub/telnet.90.03.01.tar.Z
which is a compressed tar file.  There is also a file called
	pub/telnet.90.03.01.diff.Z
which is a compressed copy of a "diff -rc" output between the
previous version of telnet/telnetd that I placed on ucbarpa
(put out on November 28, 1989), and this new version.

All future versions put on ucbarpa will have names of the form:
	pub/telnet.YY.MM.DD.tar.Z
where YY is the year, MM is the month, and DD is the day that
the tar file was created.

From the README file:

    CHANGES/BUGFIXES SINCE LAST RELEASE:
	Some support for IP TOS has been added.  Requires that the
	kernel support the IP_TOS socket option.

	Both telnet and telnetd now use the cc_t typedef.  typedefs are
	included for systems that don't have it (in termios.h).

	SLC_SUSP was not supported properly before.  It is now.

	IAC EOF was not translated  properly in telnetd for SYSV_TERMIO
	when not in linemode.  It now saves a copy of the VEOF character,
	so that when ICANON is turned off and we can't trust it anymore
	(because it is now the VMIN character) we use the saved value.

	There were two missing "break" commands in the linemode
	processing code in telnetd.

	Telnetd wasn't setting the kernel window size information
	properly.  It was using the rows for both rows and columns...

I have compiled this code on:
	BSD 4.3, 4.4
	Cray UNICOS 5.0, 5.1, 6.0
	SunOs 3.5
	DYNIX V3.0.12

For both SunOS 3.5 and DYNIX V3.0.12, the server did not have
the LINEMODE option enabled, since the LINEMODE option requires
some kernel support.  But it runs just fine without LINEMODE,
giving you a server that supports other options like
	Remote Flow Control Option
	Terminal Speed Option
	Window Size Option
	Terminal-Type Option (RFC 1091)
	Binary Option (much better implementation than 4.3BSD)
so it is probably worthwhile to get even if you can't make the
kernel modifications needed for the LINEMODE option.

As always, please send any bug reports to me: dab@cray.com

		-Dave Borman, dab@cray.com
-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Mar 90 13:39:00 EST
From:      Haggar (H.) Alsaleh <HAGGAR@BNR.CA>
To:        tcp-ip@nic.ddn.mil
Subject:   ANSI Doc.
Greetings,
could some one tell me how/where can I get ANSI documents
through the internet.

          Thanks in advance......Haggar@bnr.ca

-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 90 09:54:36 GMT
From:      mcsun!sunic!dkuug!rcbal!iff!hba@uunet.uu.net  (Henrik Ballermann)
To:        tcp-ip@nic.ddn.mil
Subject:   Interface between IP and Network provider
I am looking for a describtion of the interface between Interactive Systems 
implementation of IP (a STREAMS multiplexer driver) and the network provider
linked under IP (like a ethercard driver). I know of llc.h and lihdr.h which
defines operations and message formats, but I miss a protocol describtion.

I case you know of such document please respond by mail.

Regards
Henrik Ballermann
RC International, Denmark
mail : hba@iff.rci.dk
-- 
Venlig Hilsen
    HBA
-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 90 10:24:31 GMT
From:      sob@talcott.harvard.edu  (Scott Bradner)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IP routers
fyi - the results of the "less than comprehensive" tests I did are
on husc6.harvard.edu in pub/rtests.

Scott
-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      Tue, 6 Mar 90 12:36:00 GMT
From:      JohnHolbrook <jon%CSC.UMIST.AC.UK@CUNYVM.CUNY.EDU>
To:        tcp-ip@NIC.DDN.MIL
Subject:   TCP/IP INFO SOURCES NEEDED!!!!!!
Dear sir,
	I am interested in finding out more about TCP/IP protocols and their
implementation in a real world application. Could you perhaps supply a list
of books or journals which would enable me to teach myself more about this
topic?
	Thank you very much.
		Yours,
			John J Holbrook
-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 90 15:28:40 GMT
From:      kdb@cscraz.ncsu.edu (Kevin D. Bond)
To:        comp.protocols.tcp-ip,comp.sys.apollo
Subject:   Re: tn3270 for Apollo or RT?

C0022@UMRVMB.UMR.EDU ("O'Brennan, Gerry") writes:

>Yeah, I saw the same thing. I plan on checking into it, but I believe that
>this is for the 9.7 OS of Apollo (which we have running) and we need one that
>will run under SR10. We have taken the source and beat it to a pulp on SR10
>and it won't process the keyboard. Hopefully, Kevin's answer IS for SR10.
 
>Thank you for the information...
 
>Gerry O'Brennan
>Acknowledge-To: <C0022@UMRVMB>

Yes, my version works just fine under SR10.  I am trying to find some place
to make it available for anonymous ftp.  I will make it available for
anonymous uucp soon as well.  For anyone that has an immediate need, I can
make binaries for SR9.7 or SR10.2 and mail them to people.

-kevin
--
kdb@cscraz.ncsu.edu
kdb%sas.uucp@mcnc.org

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Mar 90 09:17:50 -0800
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        dab@berserkly.cray.com, tcp-ip@nic.ddn.mil, telnet-ietf@timbuk.CRAY.COM
Subject:   Re:  TELNET option list update
Dave:

The Network Virtual Data Entry Terminal (NVDET) is implemented and used in
the DoDIIS Community.  The RFC that you've listed for Option 20, however,
is not the one used.  The DoDIIS Community uses RFC 1043 (Yasuda and Thompson).

      Number   Name                                    RFC  NIC  DPH USE
      ------   ---------------------------------       --- ----- --- ---
        20     Data Entry Terminal                732 1043 41762 yes yes

Merton

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 90 20:19:24 GMT
From:      snorkelwacker!usc!brutus.cs.uiuc.edu!zweig@tut.cis.ohio-state.edu  (Johnny Zweig)
To:        tcp-ip@nic.ddn.mil
Subject:   A thought on RFC1145
I just had a thought about RFC1145 yesterday at lunch, and wanted to
let the Net see if they can think of anything more on the subject.

RFC1145 suggests a TCP option to allow TCP connections to use a checksum-
algorithm different from the traditional TCP checksum algorithm.  Since
it is implicit in the RFC that different connections on the same host
could be using different checksum algorithms, a funny thing happens. It
becomes necessary to look into each segment to retrieve the port numbers
and figure out which connection it is BEFORE checking the checksum!

Of course, uncorrupted packets will still check, so there's no harm in
looking into one. And, presumably, if a packet is corrupted anywhere other
than in the port numbers, the checksum algorithm for that connection will
still detect the fact.  The only thing that's a little weird is if the
port numbers themselves get scrogged so the wrong checksum algorithm is
used to check the thing.  This can only happen on damaged packets, so
the fact that they can't get used on their proper connection is not a
loss; and it seems overwhelmingly unlikely that the checksum would just
happen to check using the algorithm of the incorrectly-specified connection
and that the sequence numbers would makes any sense -- but it is a strange
sort of thing to think about.  It just seems strange to me to be using
information from a segment before checking whether the information is
correct....

Another weird thing is the fact that RST-segments will use the vanilla
TCP checksum (to allow for hosts to lose all information about a
connection and still generate a RST-segment that will be acceptable to
the other side) -- this means that if a non-vanilla  checksum fails you
have to look for MORE stuff in the still-questionably corrupt packet
(the RST bit) and check again. A little scary....

Also please note that any line containing the word "fragment" in your
copy of RFC1145 is spurious (there was an error after it left the hands
of the authors and entered into the clutches of the editors, who do a
great job and everyone loves them, even though they do make mistakes
now and then) and should be deleted.  It will be re-released without
the offending lines real soon now.

-Johnny 1145
-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      6 Mar 90 20:41:08 GMT
From:      zds-ux!behm@uunet.uu.net  (Brett Behm)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP Benchmarks

I know this question must have been asked a dozen times now, but I
can't find in in our archives so I'll ask it again.  Are there benchmarks
available for analyzing the performance of TCP/IP over ethernet?
I think I can recall something about a NFS benchmark which would also
be helpful.

Thanks in advance-

Brett Behm  uunet!zds-ux!behm
-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 90 01:31:58 GMT
From:      sdcc6!CERF.NET@ucsd.edu  (Pushpendra Mohta)
To:        tcp-ip@nic.ddn.mil
Subject:   Xylogics Annex Term Server Accounting / Unix Utilities

Hi

Has anyone ever modified the Xylogics Terminal Server
Security /Audit Functions to produce "wtmp" style
outputs which can be  fed into Unix utilities like
"last" and "ac" to generate accounting/billing information ?

For that matter has anyone got a script to generate 
this information from the Annex acp_logfile format ?

Email replies please.

Thanks 

Pushpendra
-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 90 01:56:58 GMT
From:      ka9q.bellcore.com!karn@bellcore.com  (Phil Karn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Correct SIGCOMM Dates
In article <9003020743.AA02500@ucbvax.Berkeley.EDU> craig@NNSC.NSF.NET (Craig Partridge) writes:
>
>Hi folks:
>
>    Due to a goof on my part, IEEE COMPUTER lists SIGCOMM '90 as being
>in August -- that's not correct.  The proper dates are 24-27
>September.  The conference is in Philly.
>
>Craig
>
>PS: Final reminder -- papers due March 2nd (that's a week from this
>Friday).  Phil Karn (karn@thumper.bellcore) is the program chair.

Along these lines...

I've been getting a lot of phone calls and email messages from people asking
for an extension of the deadline past March 2. We set this deadline before
we knew that the conference wouldn't take place until late September,
so there's no problem with getting your papers in a week or two late.
But get them in as soon as possible!

Also, I've received three papers electronically. This is fine; in fact,
if you have a choice, I prefer electronic paper submission because it
makes it that much easier for me to ship them to the reviewers.

Thanks!

Phil
-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Wed, 07 Mar 90 11:54:20 PST
From:      richardt@Legato.COM
To:        zds-ux!behm@uunet.uu.net (Brett Behm)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP Benchmarks
Legato has three benchmarks which may be useful to you -
they are etherck, netck, and nhfsstone.  They may be obtained
by sending mail to request@legato.com with 'send <package>' as
the subject, and with a valid path back to you in the body.

Ex:
  To: request@legato.com
  Subject: send nhfsstone
  path richardt@mica.berkeley.edu

There are presently some problems with our mail gateway - if your
site uses uunet as your mail forarder, you should send to 
uunet!legato!request instead - sun and uunet don't seem to be
cooperating these days...

RichardT
-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      Wed, 07 Mar 90 12:50:55 PST
From:      Dave Crocker <dcrocker@nsl.dec.com>
To:        vcerf@nri.reston.va.us, owen@dg-rtp.dg.com, scs@vax3.iti.org, keith%spider.co.uk@relay.cs.net, tcp-ip@nic.ddn.mil, bind@ucbarpa.berkeley.edu
Subject:   Re: Use Domain In Hostname Or Not?
I have just become convinced that a stronger rule should prevail.

Certainly, the Internet requires full domain specification. I now believe
that this applies even within a single domain or autonomous system.

We are more clever, here, and I recently got burned by it.

Our local sendmail is configured to shorten local names, removing the
host reference.  Hence, I received a piece of mail which was copies to
a local users, named 'smith' (obviously, this is just an example) and I
then replied to the full distribution list.

Unfortunately, I don't know or communicate with the local smith and I
have this entry in my private aliases file for another friend, named
smith.  My friend, rather than the local employee, received the reply.

Very bad.

D/
-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Wed, 07 Mar 90 13:33:27 PST
From:      Paul A Vixie <vixie@wrl.dec.com>
To:        dcrocker@wrl.dec.com
Cc:        vcerf@nri.reston.va.us, owen@dg-rtp.dg.com, scs@vax3.iti.org, keith%spider.co.uk@relay.cs.net, tcp-ip@nic.ddn.mil, bind@ucbarpa.berkeley.edu
Subject:   Re: Use Domain In Hostname Or Not?
Unfortunately, it's a choice between seeing a message header like:

	From: joe
	To: jim, steve, john, fred, al, gary, lou

and a header like:

	From: joe@jove.pa.dec.com
	To: jim@jove.pa.dec.com, steve@jove.pa.dec.com, john@jove.pa.dec.com,
	    fred@jove.pa.dec.com, al@jove.pa.dec.com, gary@jove.pa.dec.com,
	    lou@jove.pa.dec.com

Obviously this ought to be solved in the user-agent in some way that removes
ambiguity only when it won't collide with the personal aliases of the user
reading and replying to the mail.  

Meanwhile, the marketplace of readability will favor those postmasters who
remove local domain specifications from local addresses when delivering mail
to local users.

Paul Vixie
Postmaster@pa.dec.com
-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Mar 90 14:40:52 PST
From:      tots!niven!tep@Logicon.COM (Tom Perrine)
To:        snoopy!sri-nic.arpa!tcp-ip
Subject:   Postscript RFCs and LazerWriters
I have recently FTP'ed this Postscript RFC and have been unable to
print it using either of our Postscript printers (LazerWriters and
LazerWriter NTs). The printer returns an error message to the host:

  %%[ Error: undefined; OffendingCommand: SmallCapsFont ]%%
  %%[ Flushing: rest of job (to end-of-file) will be ignored ]%%

If it matters, I am using Transcript on a Sun-3/260, SunOS 3.5.1. I
have also tried bypassing the Transcript software and printing direct
to /dev/lw with the same result.

Is this a function that would be downloaded in a prologue file?

I noticed that the RFC claims to be Adobe-Postscript-2.0, and our
Transcript software usually generates Postscript that has a version of
1.x. Do I need a firmware upgrade for our LazerWriters to handle this?

Just another vote for ASCII-only RFCs.

Tom Perrine (tep)
Logicon (Tactical and Training Systems Division) San Diego CA (619) 455-1330
Internet: tep@tots.Logicon.COM		GENIE: T.PERRINE
UUCP: nosc!hamachi!tots!tep -or- sun!suntan!tots!tep
-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Mar 90 12:01:06 EST
From:      Cliff Stallings <cliff@wsu-eng.eng.wayne.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   fax via digital data
is it possible to connect a phone line to a "TCP/IP based network" which
would be capable of converting fax images to digital data and vice versa?
 
If not, what is the best means to accomplish this?
 
Thanks in advance for any assistance...
 
Cliff@wsu-eng.eng.wayne.edu
 

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 90 07:29:43 GMT
From:      pasteur!helios.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!usc!samsung!munnari.oz.au!uniwa!pico!dean@ucbvax.Berkeley.EDU  (Dean Economou)
To:        tcp-ip@nic.ddn.mil
Subject:   Packet order on LANs
Does anyone know if there are any protocols used over LANs which assume
that packet order is maintained at the MAC level?

By this I mean, that the protocols rely on the MAC maintaining packet
order and will fail, or have degraded performance, if order is NOT
maintained?

Thanks,
Dean Economou.
-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      Wed, 07 Mar 90 12:54:11 EST
From:      Rudy.Nedved@RUDY.FAC.CS.CMU.EDU
To:        David Borman <dab@berserkly.cray.com>
Cc:        tcp-ip@nic.ddn.mil, telnet-ietf@timbuk.CRAY.COM
Subject:   Re: TELNET option list update

David,

Several departments at CMU use various options listed as "no" in USE.
They are:

In general (Unix, TOPS-20, TOPS-10, VMS)
        23     Send Location                           779 ----- yes  no
Used when the terminal location number fails.
        28     Terminal Location Number                946 -----  no  no
Used extensively to communicate quickly and effectively the terinal
location.
        35     X Display Location                     1096 -----  no  no ?
Used to transmit the "DISPLAY" Unix shell variable extensively used by X 
programs for establishing communication.

For our IBM machines:
        25     End of Record                           885 ----- yes  no
Used to talk to IBM machines using tn3270 variant program.

All of these are critical to maintaining our environment.

-Rudy
-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      Wed 7 Mar 90 15:29:04-EST
From:      C. David Young <DYOUNG@A.ISI.EDU>
To:        tcp-ip@nic.ddn.mil
Cc:        dyoung@A.ISI.EDU
Subject:   nsca telnet and univation
Has anybody succeeded in getting NSCA Telnet working with a Univation
Ethernet board in an IBM compatible PC?  I have been trying without
success and suspect that my packet driver may be out of spec with
the PC/TCP Packet Driver Specification.  I have LNINIT.COM dated 12-17-86
and DRV.EXE dated 10-02-89.  Any help would be greatly appreciated.

David Young
dyoung@a.isi.edu
-------
-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 90 10:31:01 GMT
From:      mcsun!unido!rmi!infoac!rmohr@uunet.uu.net  (Rupert Mohr)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: TCP/IP to ISDN Gatway Box

Ok,Ok... I will summarize. Please write only with information.
(Every letter from the US costs a buck...)

By now I received 6 replies, 4 of them asking for a resume...

But the mail lines here in W.Germany were down from friday to
today. So I think, mail will come in now.

Regards,
Rupert
-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Mar 90 16:04:22 EST
From:      barns@gateway.mitre.org
To:        nelson@clutx.clarkson.edu, tcp-ip@nic.ddn.mil
Subject:   Re: partial transfer recovery in RFC and OSI protocols
I promised to respond to Russ Nelson's last on this subject a couple of
months ago, but keep being distracted by "real work".  Anyway, here it
is, late as it is.  It's LONG and won't interest everyone, but it is a
substantive topic.  For context: The sub-issue at hand is the degree to
which an FTP restart implementation based on the approach developed by
Rick Adams for BSD UNIX can support interoperable restarting of FTP
transfers between arbitrary combinations of system types.
From Russ Nelson's message of 24 Dec 89 04:51:28 GMT:

>We are trying to decide which file transfer restarting solution is
>more general: sender-controlled or receiver-controlled.
>Sender-controlled restarting relies on the sender issuing restart
>markers periodically, and on the receiver being able to preserve its
>state at these arbitrary (to it) points.  Receiver-controlled
>restarting relies on the sender being able to suppress the initial N
>octets.

[Russ didn't say it, but what the receiver does in the FTP RFC version
of the "sender-controlled" method is to remember its state in the form
of a receiver marker, distinct from the sender marker.  If the receiver
is also the User-PI (ftp client) then this amounts to preserving its
state.  If the receiver is a Server-PI then it reports the state in a
110 reply to the User-PI.  In the latter case, the User-PI upon restart
will send the receiver marker to the receiver, which restores its
state.  For a complete description, see RFC 1123, section 4.1.3.4.]

>The restart method prescribed by the FTP RFC is sender-controlled.
>The restart method implemented by Adams is receiver-controlled.  These
>two methods may both be implemented at the same time provided the
>markers emitted by the sender-controlled restart are distinguishable
>from a string of decimal digits.

To save typing I will refer to RC for receiver-controlled methods,
whether they closely resemble the Adams implementation or not.  Several
additions to the basic Adams RC design have been suggested (by Russ
Nelson, by Craig Jackson, maybe by others I've forgotten, and even by
me).  These additions all involve implementation-specific actions by
the file receiver which can be invisible to the file sender, and thus
can interoperate.

The basic interoperation issue with RC schemes is this:  The restart
state is described interoperably by specifying a byte number in the FTP
data connection stream associated with the transfer of this file in the
mode currently selected.  Three actions then need to be done
correctly:

     (1) The file receiver (which has previously received part of a
     file) must signal this byte number N to the file sender.

     (2) The sender must send the portion of the data stream following N.

     (3) The receiver must do whatever is necessary to join the
     incoming data to the partial file correctly.

These are easy to do when there is no transformation of the data stream
between the FTP data connection representation and the filestore
representations on the two hosts.  They may or may not be easy when the
hosts use different character sets, file structures, etc., to store the
files.

Items 1 and 3 interact with each other to some extent.  If the receiver
performs a complex transformation (or a non-invertible one) on the data
before storing it, then the appropriate value of N may not be
determined by the content of the partial file and the operating
system's state data about the partial file.  Such a receiver would need
to implement some explicit state-saving means.  This may constrain the
usable values of N, but since the receiver decides what N to signal to
the sender, a carefully thought out design should be able to solve
items 1 and 3.

Item 2 is trivial in principle, since the sender could presumably do
the same processing (including any transformations) on the restart
attempt that it did for the original transfer attempt, but not actually
send the first N octets to the network.  This is probably not the
way one would want to actually implement it.

It follows from these two statements that the RC approach can be made
to interoperate between any system types, provided that the receiver
correctly implements a solution for items 1 and 3, and that the sender
implements item 2.  The only element which must be in common between
the two ends is the protocol for signaling N.  Achieving a solution for
1 and 3 (on an arbitrary system) involves implementing some
state-saving mechanism external to the basic file system.  When this
discussion started, I was not thinking in terms of this add-on (which
is not in the Adams version because it is not needed on UNIX); thus my
statement that the Adams solution was not general.  I agree that
Adams+Jackson (or similar) can be general.

Generality often carries a price tag.  (This, after all, is why Adams
made a different restart design; not because the RFC-specified design
failed to Restart, but because of what else it entailed.)  An A+J RC
design has a different set of drawbacks from the SC design.  I don't
know if either one dominates the other; at first glance, it seems to be
an "apples and oranges" comparison.

The main objection to SC has been the use of "block mode" transfer,
which in practice means the insertion of restart markers into the data
stream during any transfer that one may wish to restart if it fails.
The specific complaints that I recall are:  (1) the nuisance of
inserting markers at all, (2) probably more packets on the data
connection, (3) perhaps additional data copying in the FTP or the TCP
implementation.

     Some notes:

     (2) and (3) trade off.  If the restart markers are
     sent as separate segments, alignment of the file accesses with
     their segments should not be affected.  A TCP implementation may
     not provide a way to force separate packets, though.

     If any data transformations are needed, (3) happens anyway,
     regardless of how Restart is done.  If you settle for (3), (2)
     should be nil relative to the bulk of the data.

     (1) necessarily requires some additional work, but it is arguably
     trivial.

Here are some drawbacks of an RC design.  (1) If the state saving and
restoring algorithms are not trivial, they will probably be very
intricate, and more likely to have bugs than most code is.  (2)  A
failed transfer which is never restarted will leave a "junk" saved
state in a relatively inaccessible place.  (3) The sender-side
implementation of Restart (Item 2 in my first list) may require more
processing than a corresponding SC version.

     Some notes:

     (1) is mostly a matter of items 1 and 3 from my first list getting
     jumbled together in a single chunk of code.  The knowledge needed
     to build this is the same as is required to build a correct SC
     implementation.

     (2) brings up a point made by Russ Nelson - that there will always
     be some kind of saved state entity ("file", probably) in an SC
     implementation.  In the FTP RFC's design, this resides at the
     User-PI, which may be the sender, receiver, or neither.  In the RC
     designs such a saved state entity would reside at the receiver,
     which may be either a User-PI or a Server-PI.  Having it exist at
     the User-PI might be considered better since it means that any
     "junk" is closer to where the user is, and thus more likely to be
     cleaned up.  It also offers the potential for clever user
     interface features, e.g., when the ftp user program starts, it
     reports any prior failed transfers and asks which one to restart,
     if any.  In an RC design, this can be done for aborted "gets" but
     not "puts".  In an SC design, it can be done for either, and even
     for three party transfers.

     (3) is quite interesting.  Although it's possible to start the
     sender's state machine at the beginning of a file and just process
     everything to get to the right state for byte N, this is obviously
     something to be avoided, if possible.  (If the file were small,
     this cost is small, but then again, re-sending the whole file is a
     small cost for a small file.  Restartable FTP is mainly
     interesting for large files!)  This requires three things.  First,
     the sender's operating system/file system must allow positioning
     to some point in mid-file.  Second, there must be some means of
     converting between N, the restart parameter, and the positioning
     parameter used by the OS.  Third, if there is any transformation
     state pertinent to the point that the OS can reposition to, this
     needs to be restored.

     I suppose that most OS's support the first in some fashion.  Those
     that don't leave no alternative for the FTP implementor.

     The second requirement is more interesting.  If the positioning
     parameter is expressed as (say) a record number, the sender in an
     RC scheme must convert N to a record number and offset into the
     record.  If the file is stored as variable length records, it
     seems this would be impossible to do.  (It was a long time ago,
     but I think I remember that GCOS stores Time-Sharing Text Editor
     files as variable-length records of 9-bit ASCII; I don't remember
     if format characters like CR or LF were stored, but I suppose
     not.)  The SC scheme provides a solution for this, because the
     sender can save its state in the body of the restart marker, and
     this will be stored in the saved state entity along with the
     receiver's saved state.

     The third requirement can be handled in the same way as the
     second.  It's probably less of a practical problem, since one
     would presumably design a record-oriented file format to have the
     records contain relatively independent entities for which the
     pending state is always the same for a given file (e.g., every
     end-of-record is an end-of-line).

     One might ask if the last two items can be met by having a
     separate saved state entity at the sender.  The answer is yes, but
     this entity has to contain multiple saved states to be of much
     use.  This is true because at the time of original sending, the
     sender does not know what N the receiver will supply.  If the
     sender saves only one state (a recent one, continually updated),
     and the receiver in a later restart attempt selects N such that it
     corresponds to a point before this saved sender state, the saved
     sender state is useless.  The RFC's scheme gets around this by
     forcing the sender and receiver markers to come together at one
     point (with synchronization), so it is sufficient to save just
     one.  (I have an argument for why one should keep more than one
     state in some situations, but it is unrelated to the current
     topic.)

Whew.

/Bill Barns
barns@gateway.mitre.org
-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      Wed, 7 Mar 90 18:56:00 EST
From:      Haggar (H.) Alsaleh <HAGGAR@BNR.CA>
To:        tcp-ip@nic.ddn.mil
Subject:   Job Opportunity


Key designers are required to work in various CPE projects requiring
system architecture and high-level design. Requires a minimum of a
B.S. or equivalent(Masters preferred) and 3+ years experience with
any or all of the following:

   Hardware Architecture: System architecture definition/high-level
design;voice/data/video switching; high speed design, fiber optics
and related technologies; custom VLSI design; switched systems.
Protocols, LAN/WAN, and fast packet experience preferred.

   SOFTWARE ARCHITECTURE: System architecture definition/high-level
design; object-oriented structures; open network and open architecture
conceptual design; OSI protocols; LAN/WAN experience preferred.

   LAN/WAN Architecture: LAN/WAN and metropolitan area networks; bridge
router/gateway architectures and design; 802.x series protocols;X.25 and
X.75; software design with understanding of hardware.


         CPE OPPENINGS, 8515 park Ln, #1304, Dallas,TX 75231.
P.S: I'm a free man, I speak for my self and no body else.


-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 90 17:16:42 GMT
From:      lll-crg.llnl.gov!booloo@lll-winken.llnl.gov  (Mark Boolootian)
To:        tcp-ip@nic.ddn.mil
Subject:   any restrictions on USER strings passed by clients?

I need a mechanism to allow a user to communicate a little information to our
ftp server (gateway) when logging in.  What I would like to do is allow a user
to type: 

	<id>:username		(where <id> is a single letter or single digit)

instead of just typing their username when prompted by the client.  My concern 
is that some clients may not pass this string through to the server (i.e. the
colon may have some significance to the client).  Surely this is implementation
dependent.  So my questions are:

	(1) Does anyone know of any client which would NOT pass the above 
	    string?
	
	(2) Is there another character which might be preferable to the colon?

I need this piece of information at authentication time so I would rather not
use the QUOTE command to solve this.  Please email any responses as I am forever
behind in reading netnews.

Thanks in advance.
mb

booloo@lll-crg.llnl.gov
-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 90 17:54:11 GMT
From:      Rudy.Nedved@RUDY.FAC.CS.CMU.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET option list update


David,

Several departments at CMU use various options listed as "no" in USE.
They are:

In general (Unix, TOPS-20, TOPS-10, VMS)
        23     Send Location                           779 ----- yes  no
Used when the terminal location number fails.
        28     Terminal Location Number                946 -----  no  no
Used extensively to communicate quickly and effectively the terinal
location.
        35     X Display Location                     1096 -----  no  no ?
Used to transmit the "DISPLAY" Unix shell variable extensively used by X 
programs for establishing communication.

For our IBM machines:
        25     End of Record                           885 ----- yes  no
Used to talk to IBM machines using tn3270 variant program.

All of these are critical to maintaining our environment.

-Rudy

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 90 02:14:37 PST (Thursday)
From:      "Milton_Choo.ESM4"@Xerox.COM
To:        jon%CSC.UMIST.AC.UK@CUNYVM.CUNY.EDU
Cc:        "Milton_Choo.ESM4"@Xerox.COM, tcp-ip@NIC.DDN.MIL
Subject:   Re: TCP/IP INFO SOURCES NEEDED!!!!!!
Hi John,
	Whatever you get, please sent a copy to me. Thanks!
--milton--
-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 90 18:20:23 GMT
From:      van-bc!jtc@ucbvax.Berkeley.EDU  (J.T. Conklin)
To:        tcp-ip@nic.ddn.mil
Subject:   Is there a BibTeX bibliography of all the RFC's
Does anyone have a BibTeX bibliography file containing all the 
RFCs?  If you do, and it's freely redistributable, please send
me mail as to how I can get ahold of it.

Thank you,

	--jtc
-- 
J.T. Conklin
	...!{uunet,ubc-cs}!van-bc!jtc, jtc@wimsey.bc.ca
-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      7 Mar 90 19:01:42 GMT
From:      mcsun!inesc!habs@uunet.uu.net  (Henrique A. de Barros Silva)
To:        tcp-ip@nic.ddn.mil
Subject:   BROADCAST ADDRESS ON HP-UX.

I would appreciate some help on the following.

For a few reasons, machines running TCP/IP in our local network still use the
old BSD 4.2 broadcast address format, i.e. host portion of the address all
zeros, instead of the BSD 4.3 format, with the host portion with all ones.

The problem here is that we don't know HOW TO CHANGE the format of the
broadcast address in a HP9000 running HP-UX. We tried everything (even
ifconfig, of course), but did not succeed. What are we missing?!

Thank you for any help.
--Henrique.
-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      Thu, 08 Mar 90 08:06:30 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        vixie@wrl.dec.com
Cc:        vcerf@nri.reston.va.us, owen@dg-rtp.dg.com, scs@vax3.iti.org, ketih%spider.co.uk@relay.cs.net, tcp-ip@nic.ddn.mil, bind@ucbarpa.berkeley.edu
Subject:   re: Use Domain in Hostname or Not?

> Meanwhile, the marketplace of readability will favor those postmasters who
> remove local domain specifications from local addresses when delivering mail
> to local users.

Paul:

    My sense is that the primary reason readers read addresses is to try
to fix them because their mailer delivers an address it then won't allow
replies to.  (In this case, the unfortunate consequence of being liberal in
what is accepted, but conservative in sending -- the user gets stuck with
the mess).

    So if (pie in the sky) we could get closer to a universal address format
(user@full-domain), I don't think users would mind.

Craig
-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Thu, 08 Mar 90 08:08:45 -0500
From:      H. Craig McKee <mckee@community-chest.mitre.org>
To:        Van Jacobson <van@helios.ee.lbl.gov>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: new version of tcpdump available
  > From: Van Jacobson <van@helios.ee.lbl.gov>
  >
  >In addition, our sun4c nit gives you
  >timestamps to the resolution of the SS-1 clock (1 us) rather
  >than the lousy 20ms timestamps Sun gives you....

Van - What kind of issues/questions do you address that requires a
resolution of 1 us rather than 20 ms?   Regards - Craig

-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Mar 90 15:28:57 -0800
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        craig@NNSC.NSF.NET, vixie@wrl.dec.com
Cc:        bind@ucbarpa.Berkeley.EDU, ketih%spider.co.uk@relay.cs.net, owen@dg-rtp.dg.com, scs@vax3.iti.org, tcp-ip@nic.ddn.mil, vcerf@nri.reston.va.us
Subject:   Re: Use Domain in Hostname or Not?
Paul:

Sometimes one reads the From: and To: lines just to confirm their belief in
miracles and to justify their offerings to the Patron Saint of SMTP.  Note
the following header:

 From fyfe@yogi.enet.dec.com Thu Mar  8 08:06:12 1990
 Received: from decwrl.dec.com by WLV.IMSD.CONTEL.COM (5.61/1.25)
         id AA16755; Thu, 8 Mar 90 08:05:59 -0800
 Received: by decwrl.dec.com; id AA20013; Thu, 8 Mar 90 08:04:49 -0800
 Message-Id: <9003081604.AA20013@decwrl.dec.com>
 Received: from yogi.enet; by decwrl.enet; Thu, 8 Mar 90 08:05:11 PST
 Date: Thu, 8 Mar 90 08:05:11 PST
 From: "Doug Fyfe - IAS Engineering - DTN: 264-4872  08-Mar-1990 1059" <fyfe@yogi.enet.dec.com>
 To: mail11:;@UNKNOWN@decwrl.dec.com (@merton)
 Subject: IAS and powerfail recovery
 Status: RO

Its amazing.  I probably should have retried responding to the originator
and all recipients just to see what would happen with the fully qualified

        mail11:;@UNKNOWN@decwrl.dec.com (@merton)

My system is running 4.3bsd with sendmail 5.61.  The sendmail.cf is fairly
stock adding the necessary node and domain name for the local recipients
and originator when the message leaves the local domain.  For local recipients
the originator is only required to supply a node or subsystem name when the
recipient is not in the local flat user name space.

There is no particular benefit in responding with the correct statement of
what will happen on a reply--other than the knowledge that you are right--
or wrong.

Merton

-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Thu, 08 Mar 90 10:54:30 PST
From:      Paul A Vixie <vixie@wrl.dec.com>
To:        Craig Partridge <craig@NNSC.NSF.NET>
Cc:        vcerf@nri.reston.va.us, owen@dg-rtp.dg.com, scs@vax3.iti.org, ketih%spider.co.uk@relay.cs.net, tcp-ip@nic.ddn.mil, bind@ucbarpa.berkeley.edu
Subject:   Re: Use Domain in Hostname or Not?
Craig,

My sense is that people read addresses from the headers is to figure out
who sent the message and who else received it.  There are often subtleties
being communicated by whether the reader was listed on TO or CC, and for
that matter who else was listed on TO vs. CC.

My vision of pie in the sky has the MTA leaving FQDM's on all addresses,
and the MUA stripping them out of what it displays if it is "safe" to do
so.  Of the MUA's I know of, only Elm (a UNIX user agent written by Dave
Taylor and many others) does this intelligently.

Given the general complexity of X.400 addressing, I think this feature set
will be more common after the next Great Transition.

Paul
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 90 03:07:19 GMT
From:      nvuxr.cc.bellcore.com!ak2@bellcore.com  (Arthur Knapp)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Help on "Object identifier, Object name and Relative Distingulshed Name" needed
An object identifier is a name form specified in ASN.1 in CCITT X.208 | 
ISO 8824.  It is a globally unambiguous sequence of natural numbers which 
adhere to Annexes B, C and D of the standards.  OIDs are used to usually 
identify types or classes of information objects.

Relative distinguished names (RDNs) are specified in CCITT X.500 | ISO 
9594.  A Directory name is a Distinguished name which is a sequence of 
RDNs.  An RDN is a set of attribute value assertions (AVAs).  Each AVA 
consists of an attribute type, e.g., organziationName, and an attribute 
value, e.g., widgets unlimited.  

I'm not sure what you mean by object name.

ISO 9834-1 suggests a mapping between the two.  Hoever, CCITT has 
concluded that the mapping is politically and technically irreconcilable.

Arthur Knapp
-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      Thu 8 Mar 90 09:53:09-EST
From:      Dan Lynch <LYNCH@A.ISI.EDU>
To:        HAGGAR@BNR.CA
Cc:        tcp-ip@nic.ddn.mil, lynch@A.ISI.EDU
Subject:   Re: Job Opportunity
Haggar,  The custom on the Internet is to not have commercials put out
on it.  Job postings are not allowed except those by University based
groups.  Even that is frowned upon because of the huge clutter it
would cause on these lists.  
Dan
-------
-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 90 06:10:13 GMT
From:      amdahl!pacbell!indetech!fiver!palowoda@ames.arc.nasa.gov  (Bob Palowoda)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Interface between IP and Network provider
From article <1307@iff.rci.dk>, by hba@iff.rci.dk (Henrik Ballermann):
> I am looking for a describtion of the interface between Interactive Systems 
> implementation of IP (a STREAMS multiplexer driver) and the network provider
> linked under IP (like a ethercard driver). I know of llc.h and lihdr.h which
> defines operations and message formats, but I miss a protocol describtion.
> 
> I case you know of such document please respond by mail.

  Let me mention a new book that just hit the bookstore. 
  UNIX NETWORK PROGRAMING
  by W. Richard Stevens
  Published by the Prentice Hall           

  A good book like Douglas Comer's TCP/IP only with more details and
  examples of codeing the protocols. Very good chapter on STEAMS with
  sockets and does make references to ISC implementation. Just got 
  mine today. 

---Bob
 

-- 
Bob Palowoda  indetech!fiver!palowoda      *Home of Fiver BBS*  login: bbs
Home {sun|daisy}!ys2!fiver!palowoda            (415)-623-8809 1200/2400
Work {sun|pyramid|decwrl}!megatest!palowoda (415)-623-8806 2400/9600/19200 TB
Voice: (415)-623-7495  palowoda@fiver           Public access UNIX XBBS   
-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      Thu, 08 Mar 90 17:38:06 PST
From:      Alan Stebbens <aks@hub.ucsb.edu> <aks>
To:        Paul A Vixie <vixie@wrl.dec.com>
Cc:        dcrocker@wrl.dec.com, vcerf@nri.reston.va.us, owen@dg-rtp.dg.com, scs@vax3.iti.org, keith%spider.co.uk@relay.cs.net, tcp-ip@nic.ddn.mil, bind@ucbarpa.berkeley.edu
Subject:   Re: Use Domain In Hostname Or Not?
vixie> Unfortunately, it's a choice between seeing a message
vixie> header like:

vixie> 	From: joe
vixie> 	To: jim, steve, john, fred, al, gary, lou

vixie> and a header like:

vixie> 	From: joe@jove.pa.dec.com
vixie> 	To: jim@jove.pa.dec.com, steve@jove.pa.dec.com, john@jove.pa.dec.com,
vixie> 	    fred@jove.pa.dec.com, al@jove.pa.dec.com, gary@jove.pa.dec.com,
vixie> 	    lou@jove.pa.dec.com

vixie> Obviously this ought to be solved in the user-agent in some
vixie> way that removes ambiguity only when it won't collide with
vixie> the personal aliases of the user reading and replying to
vixie> the mail.

There's two separate issues:  seeing the first format when you are
reading the message for your own benefit is desireable, but the
second format is desireable for replies.

This is doable, if you use MH: you could write a mhl-format file
which would make the names look pretty only when they were "show"n
or "scan"ed, but kept in their original format in the file, so
that when you "repl"y, a different mhl-format could be used to
ensure full hostnames for correctness.

Read the man page for 'mhl-format' for details.

Alan Stebbens        <aks@hub.ucsb.edu>             (805) 961-3221
     Center for Computational Sciences and Engineering (CCSE)
          University of California, Santa Barbara (UCSB)
           3111 Engineering I, Santa Barbara, CA 93106

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      Thu, 08 Mar 90 18:10:06 PST
From:      Paul A Vixie <vixie@wrl.dec.com>
To:        Alan Stebbens <aks@hub.ucsb.edu>
Cc:        dcrocker@wrl.dec.com, vcerf@nri.reston.va.us, owen@dg-rtp.dg.com, scs@vax3.iti.org, keith%spider.co.uk@relay.cs.net, tcp-ip@nic.ddn.mil, bind@ucbarpa.berkeley.edu
Subject:   Re: Use Domain In Hostname Or Not?
This isn't about MH and these are the wrong places to discuss it,
but because you mentioned it and because I don't think what you
suggest will work, I'd like to follow up.

>> This is doable, if you use MH: you could write a mhl-format file
>> which would make the names look pretty only when they were "show"n
>> or "scan"ed, but kept in their original format in the file, so
>> that when you "repl"y, a different mhl-format could be used to
>> ensure full hostnames for correctness.

mhl-formal lacks the ability, so far as I know, to only print the domain
and/or subdomain if it is different or otherwise nonequivilent to the local
domain.  We couldn't very well have mhl-format strip *all* @domains, lest
we get mail from "smith" or even "John Smith <smith>" and have to wonder
which domain he came from.  One only wants to strip out the @domain if it
is "equivilent" to the mail reader's domain -- which means that the local-
parts mean the same thing (refer to the same users, mail groups, etc).

Paul Vixie
DEC WRL
-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 90 10:23:25 GMT
From:      mcsun!ukc!edcastle!adam@uunet.uu.net  (Adam Hamilton)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Packet order on LANs
In article <452@pico.oz> dean@pico.qpsx.oz (Dean Economou) writes:
:Does anyone know if there are any protocols used over LANs which assume
:that packet order is maintained at the MAC level?
:
:By this I mean, that the protocols rely on the MAC maintaining packet
:order and will fail, or have degraded performance, if order is NOT
:maintained?
:

	LLC2 (as in IEEE connection-oriented) will fail if packets are
reordered on a LAN.
	The scenario is this.  Assume we are dealing with packets 1 and 2.
Packet 2 arrives first.  The receiver assumes that packet 1 has been lost and
therefore asks for it to be retransmitted.  Packet 1 will now arrive twice.
The first occurrence (the original transmission) will be accepted, the second
will be seen as duplicate/out-of-window.  The receiver will now send a
reset (signalling loss of data).  This requires higher level protocols to
do the recovery.
	IEEE Standard 802.3 Section 2.3.2.5 says ".... the MAC sublayer
requires that the requests [to transmit frames] be serviced in a first-in-
first-out manner", i.e. no frame reordering.

	Our LLC2 implementation actually fell foul of this when one
manufacturer's Ethernet board was prepared to reorder frames.  After some
argument they fixed it.
		Adam Hamilton
-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 90 10:45:05 GMT
From:      elroy.jpl.nasa.gov!usc!cs.utexas.edu!ntvaxb!billy@decwrl.dec.com
To:        tcp-ip@nic.ddn.mil
Subject:   WIN/TCP ping problems
Hi,

I am running WIN/TCP for VMS version 5.0.  I have just noticed that users
with normal user privs (NETMBX, TMPMBX) get the error message "socket:
permission denied" whenever they try to use PING.  With full privilege
it works fine.  Questions:

1.  Is this normal?  If it isn't, any ideas on what I did wrong?

2.  If the answer to #1 is yes, what privilege do I need to install it
    with?

Thanks,

================================================================================
Billy Barron                  Bitnet : BILLY@UNTVAX
VAX system manager            THENET : NTVAXB::BILLY
University of North Texas   Internet : billy@vaxb.acs.unt.edu
                                SPAN : UTSPAN::UTADNX::NTVAXB::BILLY
================================================================================
-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 90 13:06:30 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Use Domain in Hostname or Not?


> Meanwhile, the marketplace of readability will favor those postmasters who
> remove local domain specifications from local addresses when delivering mail
> to local users.

Paul:

    My sense is that the primary reason readers read addresses is to try
to fix them because their mailer delivers an address it then won't allow
replies to.  (In this case, the unfortunate consequence of being liberal in
what is accepted, but conservative in sending -- the user gets stuck with
the mess).

    So if (pie in the sky) we could get closer to a universal address format
(user@full-domain), I don't think users would mind.

Craig

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      Thu, 8 Mar 90 21:23:53 PST
From:      estrin@usc.edu (Deborah Estrin)
To:        tcp-ip@sri-nic.arpa
Subject:   Journal of Internetworking 2nd Issue Call for Papers

JOURNAL OF INTERNETWORKING RESEARCH AND EXPERIENCE

Papers are solicited for the  second issue.  
Submission deadline is March 31, 1990.    
The first two issues will be published in 1990. 

Aims and Scope of the Journal:

Designing and implementing communication protocols that enable
heterogeneous computer systems to interoperate is extremely
difficult.  The demand for such protocols has risen sharply as
users have begun to connect diverse systems and networks
together.  For example, the federally-supported Internet in the
US has grown from a few dozen research institutions into a
worldwide network connecting tens of thousands of computers and
hundreds of thousands of users.  At the same time, the international
community is developing standards for open system interconnection
(OSI); several experimental OSI networks have been established.

Experimental research and practical experience are very important
to understanding internetworking and interoperability issues and
finding workable solutions.  Many studies of experimental nature
have been performed in the Internet environment.  The emerging
OSI networks offer a new platform for experimental research.  The
results of this work have been reported primarily in technical
reports, RFCs, and various conference proceedings.  No journal
concentrates on the research and experience in internetworking
and interoperability.

INTERNETWORKING will seek to provide a focus for original results
of research in interconnection and interoperability of computer
networks and systems; a mechanism for quality control and
verification through the refereeing process; and opportunities
for comment and debate in a public and easily accessible forum.

The journal will encourage papers on topics ranging from
architectural models to details of implementations and performance
measurements.  The emphasis will be primarily on those papers
reporting practical experience gained in designing, implementing
or using protocols, mechanisms and policies enabling
interoperability in a heterogenous internet environment.
However, papers of a more mathematical or theoretical nature that
might contribute to the development of, or better understanding
of, methods of design, construction and use of such protocols,
mechanisms and policies will also be welcomed.  Shorter,
unrefereed notes and letters may be published if they relate to
current research topics or previously published articles.

Articles may range in length from a short note (perhaps half a
page) to the length required to document a design in detail
(perhaps forty pages or more).  The goal is to provide timely
dissemination of results while maintaining a thorough review
process.

INTERNETWORKING will provide a valuable source of reference to
all who design, implement or use internet protocol software, or
who want to learn more about the technology.  Anyone involved
in the investigation of interoperability or the communication
protocols that support it should consider writing about their work
for the journal.

Submit papers to one of the three editors: R. Droms, D. Estrin, or L.
Svobodova. Addresses provided below.

Subscription information should be obtained from the publisher.
John Wiley & Sons  of  Chichester   New York   Brisbane
Toronto and Singapore. 


 Editor-in-chief:

                Professor Douglas E. Comer
                Computer Sciences Department
                Purdue University
                West Lafayette, IN 47907
                USA

                Tel: (317) 494-6009
                comer@purdue.edu


 Editors:
                Ralph A. Droms
                Computer Science Department
                Bucknell University
                Lewisburg, PA 17837
                USA
                Tel: (703) 620-8990
                rdroms@nri.reston.va.us


                Deborah L. Estrin
                Computer Science Department
                Henry Salvatori Computer Science Center
                University of Southern California
                Los Angeles, CA  90089-0782
                USA
                Tel: (213) 743-7842
                estrin@usc.edu


		Liba Svobodova
		IBM Research Division
		Zurich Research Laboratory
		Saumerstrasse 4
		8803 Ruschlikon, Switzerland
		Tel: +41 1 724 8274
		svo@ibm.com


Thank you, Deborah Estrin
-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 90 14:22:49 GMT
From:      zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!jarvis.csri.toronto.edu!utgpu!utzoo!censor!geac!alias!mark@tut.cis.ohio-state.edu  (Mark Andrews)
To:        tcp-ip@nic.ddn.mil
Subject:   new telnet and IP_TOS option
Dave Borman recently announced the release of a new version of telnet.
A section of the article follows:

>	From the README file:
>
>	CHANGES/BUGFIXES SINCE LAST RELEASE:
>		Some support for IP TOS has been added.  Requires that the
>		kernel support the IP_TOS socket option.


What is this IP_TOS socket option. Was it released with the 4.3tahoe
networking code which was available from Berkeley (or is it only
available with the 4.4 code)?

The latest networking code that I know of was made available in late
February of last year.

I'm just curious what this refers to.

------------------------------------------------------------------------------
	Mark Andrews
	Systems Programmer,
	Alias Research,
	Toronto, Canada
Phone:	(416)-362-9181
UUCP:	csri.utoronto.ca!alias!mark
-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 90 15:43:56 GMT
From:      van-bc!ubc-cs!alberta!calgary!ctycal!ingoldsb@ucbvax.Berkeley.EDU  (Terry Ingoldsby)
To:        tcp-ip@nic.ddn.mil
Subject:   Need a 327X emulator for use with TCP/IP
Sorry for posting this to several groups, but I'm not quite sure where
it belongs.

We are using TCP/IP to connect a variety of heterogeneous machines together.
This includes such diverse platforms as IBM mainframes and Intergraph Unix
workstations.  The problem I have is in emulating the IBM style terminals
from the Intergraph Unix workstations.  

Currently, the Intergraph platforms provide a VT220 type virtual terminal
window into the IBM machine.  Fortunately the TCP/IP software on the IBM
VM machine provides some conversion between the 327X EBCDIC and the 
VT220 standards.  Unfortunately many operations require multiple keystrokes
(eg. ESC 1 is PF1).  Worse yet, we are bringing up TCP/IP on an IBM MVS
machine and it has even less in the way of terminal conversion facilities.

What I need is a program that will interpret the 3270 control codes and
data stream and convert it to VT220 screen codes.  The software should
also provide some sort of translation from the VT220 keyboard to 3270
key codes (eg. use the numeric keypad for the PF keys).

Is there anything like this for sale?  Is there anything in the public
domain?  Please reply via email since I don't read all of these groups
regularly.


-- 
  Terry Ingoldsby                ctycal!ingoldsb@calgary.UUCP
  Land Information Systems                 or
  The City of Calgary       ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb
-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 90 16:52:30 GMT
From:      van-bc!ubc-cs!alberta!calgary!ctycal!frank@ucbvax.Berkeley.EDU  (Frank Lok)
To:        tcp-ip@nic.ddn.mil
Subject:   IBM MVS TCP/IP problems (host file record length too long)
We are in the process of installing IBM's MVS TCP/IP.  We have discovered
that the `hosts' file has a record length of 285 characters.  Upon
attempting to edit this file to add host id's, we are unable to do so
due to the record length.  Does anyone know how we are expected to
edit the file.  Attempts to get assistance from IBM have proved
unsuccessful to this point.


-- 
  Frank Lok                ctycal!frank@calgary.UUCP
  DPSD Communications                 or
  The City of Calgary       ...{alberta,ubc-cs,utai}!calgary!ctycal!frank
-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 90 20:13:18 GMT
From:      zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!stat!pace@tut.cis.ohio-state.edu  (Donald Pace)
To:        tcp-ip@nic.ddn.mil
Subject:   whois server

I am looking for a whois server sort of like the one running
at SRI-NIC.  I would like for it to run on a sun but any pointers
would be appreciated.

thank you
Don Pace
Florida State University Computing Center
-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      8 Mar 90 21:08:48 GMT
From:      elroy.jpl.nasa.gov!aero!xberri%arecibo.aero.org@decwrl.dec.com  (Jason E. Berri)
To:        tcp-ip@nic.ddn.mil
Subject:   lat-tcp/ip terminal servers
I know this subject has come up in the past, but now that we are in the 
market for a dual protocol server I would like to gather opinions from 
people who use the various products that are available (xyplex, datability, 
etc.).  Please *email* your responses to me and I will summarize to the net 
if there is interest.  Thanks in advance!

-Jason

Jason Berri

INTERNET: berri@aerospace.aero.org or berri@arecibo.aero.org
-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Mar 90 09:20:57 PST
From:      postel@venera.isi.edu
To:        tcp-ip@nic.ddn.mil
Cc:        solensky%interlan.interlan.com@relay.cs.net
Subject:   "TCP header prediction" pointer?
Frank:

See RFC-1144 (in PostScript).

--jon.


----- Begin Included Message -----

From tcp-ip-RELAY@NIC.DDN.MIL Thu Mar  8 21:05:57 1990
Date: Mon, 5 Mar 90 14:34:10 EST
From: Frank Solensky <solensky%interlan.interlan.com@RELAY.CS.NET>
To: tcp-ip@NIC.DDN.MIL
Subject: "TCP header prediction" pointer?

Is there some RFC / journal article that describes the TCP header prediction
algorithm and/or observed results?

Thanks in advance---		Frank Solensky
				  Racal Interlan


----- End Included Message -----

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 90 01:47:05 GMT
From:      ddk@lanl.gov  (David D Kaas)
To:        tcp-ip@nic.ddn.mil
Subject:   .netrc


	At our site we have a CRAY and several dozen UNIX workstations.
We are looking at ways of doing un-atteneded file transfers during off
hours.  We have started using ftp with .netrc files.  We do have outside
access to our network.  Now the question, is this considered a security
problem?  If so how are un-attended file transfers done?

Thank You
Dave Kaas
Boeing Computer Services Richland
D. O. E.
Richland, WA 99352
(509) 376-6386
e41126%rlvax3.lanl.gov
-- 
Dave Kaas - D.O.E. Richland, Wa.
	e41126%rlvax3.xnet@lanl.gov
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 90 01:50:32 GMT
From:      mtxinu!sybase!forrest%sybase.com@ucbvax.Berkeley.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   TCP Incompatibilities in RFC 793 vs RFC 1122?
I am wondering if anybody is concerned about an seeming incompatibility
in TCP implementations meeting RFC 793 compared to RFC 1122. From
what I can see, the meaning of the urgent pointer has changed.
(I should mention that what I am about to say was passed on to me
by someone else. I haven't actually read the RFC's except for the
passages quoted below).

RFC 793 says (page 17) that the urgent pointer points to "the sequence
number of the octet following the urgent data." . RFC 1122 says
(page 84, section 4.2.2.4) that RFC 793 is wrong and that "the urgent
pointer points to the sequence number of the LAST octet (not LAST+1)
in a sequence of urgent data.".

From what I see this means that when a TCP implementing RFC 1122
receives urgent data from a TCP implementing only RFC 793, the
receiver will always treat the first byte of regular data as
the last byte of urgent data. Or, going the other direction,
the receiver will treat the last byte of urgent data as the
first byte of regular data. (Both cases assume the presence of
urgent data).

Plus, since there is no way I know of to detect a 1122 TCP from a
793 TCP there is no way to handle the urgent pointer in a RFC-dependent
manner.

Is this an in-joke among the cognoscenti or is this something that
users of TCP should be concerned about?

----
Anything you read here is my opinion and in no way represents Sybase, Inc.

Jon Forrest WB6EDM
forrest@sybase.com
{pacbell,sun,{uunet,ucbvax}!mtxinu}!sybase!forrest
415-596-3422
-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      Fri 9 Mar 90 09:52:07-PST
From:      Ole J. Jacobsen <OLE@CSLI.Stanford.EDU>
To:        tcp-ip@sri-nic.arpa
Subject:   Is there a sTaNdArD??

Hi,

	I often have occasion to put references to host names or email
addresses in ConneXions. I'd like to keep a consistent style, but there
seems to be a variety of current practices in place:

NIC.DDN.MIL   or   nic.ddn.mil

	Sometimes there is case mixing as in Service@NIC.DDN.MIL and
sometimes not SERVICE@NIC.DDN.MIL, service@nic.ddn.mil. I am not picking
on the NIC by the way, this happens with all email addresses. Do we
have either a standard or an accepted convention for this, or should I
just pick one and try to set a trend?

oLe
-------
-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Mar 90 10:24:29 -0500
From:      sms@LONEX.RADC.AF.MIL (Steven M. Schultz)
To:        cs.utexas.edu!ut-emx!jones@tut.cis.ohio-state.edu, tcp-ip@nic.ddn.mil
Cc:        bind@ucbarpa.berkeley.edu
Subject:   Re: rlogind/named interaction?
>From: cs.utexas.edu!ut-emx!jones@tut.cis.ohio-state.edu  (William L. Jones)
>In article <48242@wlbr.IMSD.CONTEL.COM>, sms@wlv.imsd.contel.com (Steven M. Schultz) writes:
>...
>> 
>> 	the name returned by gethostbyaddr() and RES_DNSRCH is ON (by
>> 	default), so the resolving routines merrily start appending the 
>> 	various domain subcomponents and issuing queries to the 'named'.
>...
>> 	8650 a 'rlogin' has taken up to 2 minutes to complete.  A debug
>...
>
>I noticed the same problem under UNICOS 5.0 and 5.1.  It would get real grim 
>when we tried to login into the cray and our connection to NFSNET was down.
>UNICOS 5.1  is a little better since it stops the domain search at the
>top domain. At least the named traffic is local.
>
>I can't see why appending a period to the name before the 
>gethostbyname would hurt.  Does anybody know of a reason why it 
>would not.  It is the fix that I was going to send to cray
>in a spr. 

	another reply i received mentioned that the trailing dot would
	work, but probably wasn't such a good idea.

	what i've done is apply the following patch to rlogind.c, it
	works quite well and is a cleaner (i think) fix than appending
	a dot.

	Steven Schultz
	sms@wlv.imsd.contel.com
	sms@lonex.radc.af.mil


*** rlogind.c.old	Fri Oct  6 17:29:38 1989
--- rlogind.c	Thu Mar  8 10:21:14 1990
***************
*** 57,62 ****
--- 57,64 ----
  #include <netdb.h>
  #include <syslog.h>
  #include <strings.h>
+ #include <arpa/nameser.h>
+ #include <resolv.h>
  
  #ifndef TIOCPKT_WINDOW
  #define TIOCPKT_WINDOW 0x80
***************
*** 170,175 ****
--- 172,185 ----
  		 */
  		strncpy(remotehost, hp->h_name, sizeof(remotehost) - 1);
  		remotehost[sizeof(remotehost) - 1] = 0;
+ #ifdef	RES_DNSRCH
+ 		/*
+ 		 * gethostbyaddr returns a FQDN, so now the domain search
+ 		 * action must be turned off to avoid unwanted queries to
+ 		 * the nameservor.
+ 		*/
+ 		_res.options &= ~RES_DNSRCH;
+ #endif	RES_DNSRCH
  		hp = gethostbyname(remotehost);
  		if (hp)
  #ifdef h_addr	/* 4.2 hack */
-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 90 03:21:18 GMT
From:      cs.utexas.edu!ut-emx!jones@tut.cis.ohio-state.edu  (William L. Jones)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: rlogind/named interaction?
In article <48242@wlbr.IMSD.CONTEL.COM>, sms@wlv.imsd.contel.com (Steven M. Schultz) writes:
...
> 
> 	'Rlogind' does a gethostbyaddr() to look up the name of the
> 	client host, receives a successfull response, and then
> 	performs a gethostbyname() using the name returned earlier.
> 
> 	Unfortunately, there is not a trailing '.' at the end of
> 	the name returned by gethostbyaddr() and RES_DNSRCH is ON (by
> 	default), so the resolving routines merrily start appending the 
> 	various domain subcomponents and issuing queries to the 'named'.
...
> 	8650 a 'rlogin' has taken up to 2 minutes to complete.  A debug
...

I noticed the same problem under UNICOS 5.0 and 5.1.  It would get real grim 
when we tried to login into the cray and our connection to NFSNET was down.
UNICOS 5.1  is a little better since it stops the domain search at the
top domain. At least the named traffic is local.

I can't see why appending a period to the name before the 
gethostbyname would hurt.  Does anybody know of a reason why it 
would not.  It is the fix that I was going to send to cray
in a spr. 

I wonder who much this is contributing to the 15% named traffic that
NSFNET is seeing, see the the JANUARY 3-4 IAB MEETING notes?


Bill Jones
-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      Fri, 09 Mar 90 14:02:23 PST
From:      Paul Mockapetris <pvm@venera.isi.edu>
To:        Chris Tanner <01696%AECLCR.bitnet@ugw.utcs.utoronto.ca>
Cc:        TCP-IP@NIC.DDN.MIL
Subject:   Re: MX Records

***** Please note that TCP-IP is a very large, general mailing list *****

	Namedroppers@nic.ddn.mil is for general DNS issues.

	bind@ucbarpa.berkeley.edu is for BIND issues.

> We are in the process of setting up a name-server here and have a questions
> about A and MX records. I kind-of understand the difference between these
> two record types, but is it possible to say set things up so that for a
> system name such as XXX.AECL.CA, FTP's would go to one IP address, and
> SMTP (mail) would be sent (via an MX record) to another IP address.
> 
> We need this since we have a machine with FTP access, but not SMTP access,
> there is another machine on site that can send mail to this machine.
> 

FTPs will always be directed to one of the addresses in the A RRs
associated with XXX.AECL.CA.

If MX RRs are present at XXX.AECL.CA, they can direct mail elsewhere.
Unfortunately, the redirection will only work for hosts that support
MX; fortunately, they work in a lot of places.

paul

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      Fri, 09 Mar 90 16:33:57 -0600
From:      jones@hermes.chpc.utexas.edu (Bill Jones)
To:        sms@LONEX.RADC.AF.MIL (Steven M. Schultz)
Cc:        jones@cs.utexas.edu, nic.ddn.mil!tcp-ip@cs.utexas.edu, ucbarpa.berkeley.edu!bind@cs.utexas.edu
Subject:   Re: rlogind/named interaction?


Can I use your mod in my spr to cray.   I agree with you
about it being the correct solution!

Bill JOnes





-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      Fri, 09 Mar 90 20:48:54 -0800
From:      "Philip Almquist" <almquist@jessica.Stanford.EDU>
To:        Ole J. Jacobsen <OLE@CSLI.Stanford.EDU>
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Is there a sTaNdArD??
Ole,
	The model used by the domain name system for host names is that
the owner of a name gets to choose its case.  For example, CSLI's name is
correctly written as "CSLI.Stanford.EDU" because:

 - The name "EDU" is owned by the NIC, and they say it is all uppercase
 - The name "Stanford" is owned by me, and I say it's that way
 - The name "CSLI" is owned by the owners of that machine, and they
   say it's all uppercase

	Unfortunately, I know of no straightforward and foolproof way for
you to determine that, since all of the name servers which are
authoritative for CSLI.Stanford.EDU use BIND and BIND is, shall we say,
"not entirely bug free".  One heuristic method is the following:

 % host 36.9.0.46       # CSLI's address

In theory this heuristic is foolproof, but in practice it depends on the
fact that the administrator of the 36.IN-ADDR.ARPA domain (me, in this
case) has done his job properly.  One nice property of this heuristic is
that the part of the name it's most likely to get right is the part before
the first dot, which is the part that you are least likely to already
know.
						pHiLiP
-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Mar 90 15:40:02 MST
From:      cpw%snow-white@LANL.GOV (C. Philip Wood)
To:        OLE@csli.Stanford.EDU
Cc:        tcp-ip@NiC.DdN.MiL
Subject:   Re:  Is there a sTaNdArD??
Ask the DNS to resolve the network address and use that.

Phil
-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 90 08:52:17 GMT
From:      oberman@rogue.llnl.gov (Oberman, Kevin)
To:        comp.protocols.tcp-ip
Subject:   Re: MX Records

In article <90Mar5.194506est.57870@ugw.utcs.utoronto.ca>, 01696@AECLCR.BITNET (Chris Tanner) writes...
>We are in the process of setting up a name-server here and have a questions
>about A and MX records. I kind-of understand the difference between these
>two record types, but is it possible to say set things up so that for a
>system name such as XXX.AECL.CA, FTP's would go to one IP address, and
>SMTP (mail) would be sent (via an MX record) to another IP address.
> 
>We need this since we have a machine with FTP access, but not SMTP access,
>there is another machine on site that can send mail to this machine.

This is exactly how it works. For an excellent description of the logic flow of
DNS and SMTP I urge that you read RFC1123. (Everyone who deals with standard IP
applications should read it!) It is very readable and not only deatails how
things should be done but why.

MX records are normally used by MAIL only. FTP queries for A records, as do
other applications (Telnet, NTP, NNTP, ...).

One more time! If you are dealing with standard applications, get and read
RFC1123. If your are dealing with writing applications, read RFC1122. I may be
weird, but I found these documents so well written that I actually enjoyed
reading them.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything. And my speel
checker is doesn't work in NEWS!

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      Fri, 9 Mar 90 17:55:53 -0500
From:      sms@LONEX.RADC.AF.MIL (Steven M. Schultz)
To:        jones@hermes.chpc.utexas.edu, sms@lonex.radc.af.mil
Cc:        nic.ddn.mil!tcp-ip@cs.utexas.edu, ucbarpa.berkeley.edu!bind@cs.utexas.edu
Subject:   Re: rlogind/named interaction?
Bill,

>Can I use your mod in my spr to cray.   I agree with you
>about it being the correct solution!

	be my guest!  i'll probably post it to comp.bugs.2(4)bsd
	one of these days myself.

	Steven
-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 90 10:30:40 GMT
From:      mcsun!ukc!stc!root44!hrc63!mrcu!yc23@uunet.uu.net  (Trevor Wright)
To:        tcp-ip@nic.ddn.mil
Subject:   ABLE Advance TS016 Terminal Server - Sun Problems
We have one ABLE Advance Terminal Server (TCP/IP and LAT). The LAT
side works but we get numerous disconnects from the VAX-11/750 we try to
link to, together with very poor performance. We are on VAX/VMS 4.5 and
will be going to 4.7 shortly - anyone know if this is a cause of the
problems.

Main snags concern the TCP/IP side. We do not seem able to get the ABLE
box to pick up internet addresses from our local Sun Server. We know the
ABLE hasn't got Yellow Pages, but is anyone successfully using a Sun as
an ABLE name server?. Another problem concerns gateway'ing through a 
Sun to another Ethernet spur. We and Able UK think we've specified the
addresses quite correctly but no connection is possible through the
gateway.

Replies from any other ABLE users or Able US appreciated.
-- 
Trevor Wright,Computer Resources | Tel: +44 245 73331 x 3224 + Answerphone
GEC-Marconi Research Centre      | Fax: +44 245 75244 Telex: 995016 GECRES G
GEC-Marconi Ltd, Great Baddow    | uucp: <world>!mcvax!ukc!gec-mrc!wright
Chelmsford,Essex. UK CM2 8HN     | Other: wright@uk.co.gec-mrc
-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 90 15:13:47 GMT
From:      pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!sugar!ficc!peter@tut.cis.ohio-state.edu  (Peter da Silva)
To:        tcp-ip@nic.ddn.mil
Subject:   rsh(1) for System V/386, Lachman TCP/IP
Does anyone have source for the 'rsh' program for System V/386? It looks
like it should be a fairly easy program to write: just call rexec(3) and
then sit there in a loop reading and writing until the guy at the other
end goes away. But I've never done any socket hacking, and I'm not at all
sure about how to call select() (like, what happens on eof?).

Any tips or code would be appreciated.

This is for Lachman TCP/IP, if that matters. For some reason Lachman TCP/IP
doesn't come with a remote shell program that I can find anywhere... just
rlogin.
-- 
 _--_|\  `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/      \  'U`
\_.--._/
      v
-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 90 17:08:08 GMT
From:      mcsun!sunic!tut!kannel!kim@uunet.uu.net  (Oberman, Kevin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: MX Records
In article <KIM.90Mar9132516@kannel.lut.fi>, kim@kannel.lut.fi (Kimmo Suominen) writes...
>At least the sendmails I've seen first try the A record
>IP address and in case it fails, it tries for MX hosts.

If they work that way, they are BROKEN! The functional flow (See RFC1123) is to
look for MX records FIRST. Then A records.

The only sendmail I've seen that has this problem is the one with ULTRIX. DEC
has promised that it will be fixed in V4.0.

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.
-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 90 18:16:00 GMT
From:      encore!pinocchio.encore.com@husc6.harvard.edu  (Jeff "spackle-man" d'Arcy)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: rsh(1) for System V/386, Lachman TCP/IP
peter@ficc.uu.net (Peter da Silva):
> This is for Lachman TCP/IP, if that matters. For some reason Lachman TCP/IP
> doesn't come with a remote shell program that I can find anywhere... just
> rlogin.

Try nsh.  LAI couldn't call it rsh because of a name conflict with the SysV
restricted shell.  BTW, it uses rcmd(), not rexec().

Jeff d'Arcy     OS/Network Software Engineer     jdarcy@encore.com
    DISCLAIMER: I don't represent Encore any more than you do
-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 90 18:25:16 GMT
From:      mcsun!sunic!tut!kannel!kim@uunet.uu.net  (Kimmo Suominen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: MX Records
>>>>> On 6 Mar 90 00:43:00 GMT, 01696@AECLCR.BITNET (Chris Tanner) said:

Chris> Is it possible to say set things up so that for a system name such as
Chris> XXX.AECL.CA, FTP's would go to one IP address, and SMTP (mail) would be
Chris> sent (via an MX record) to another IP address.

We have records like this to hauli.lut.fi, which has telnet and ftp, but no
smtp:
	$ORIGIN lut.fi.
	hauli	IN	A	128.214.25.3
		IN	WKS	128.214.25.3 TCP TELNET FTP
		IN	HINFO	VAX-8550 VMS
		IN	MX	0	kuula
		IN	MX	10	@
		IN	MX	20	router.funet.fi.
		IN	MX	30	pilli
		IN	MX	40	it
		IN	MX	50	funet.fi.

All the mail to hauli.lut.fi will be directed to one of MX hosts and this
works just fine.  Just make sure that your machine doesn't accept smtp
connections at all.  At least the sendmails I've seen first try the A record
IP address and in case it fails, it tries for MX hosts.

Kim
--
 ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
( Kimmo Suominen        ! Lappeenranta U of Technology ! kim@kannel.lut.fi )
( "That's what I think" ! Computing Centre  *  Finland ! Funet: KUULA::KIM )
 ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 90 18:48:22 GMT
From:      jtsv16!isdserv!joe@uunet.uu.net  (Joseph Mang)
To:        tcp-ip@nic.ddn.mil
Subject:   IS IBM HLLAPI over TCP-IP exist ?

Can anyone tell me is there a product out in the world that will allow a PC
to emulate IBM3270 with HLLAPI but also will run on the Ethernet supporting
TELNET, FTP and RSH etcs.. ??????
 

--

    ======  ======  ======  ======  ==   ==  ======  | Joseph Mang
   //   // //   // //        //    //|  //  //       | Boeing Canada
  ======  //   // ======    //    // | //  //  ===   | de Havilland Division
 //   // //   // //        //    //  |//  //   //    | Garratt Blvd., Downsview
======  ======  ======  ======  ==   ==  =======     | Ontario Canada, M3K 1Y5
                                                     | uunet!jtsv16!isdserv!joe
                                                     | joe@dh.boeing.com
                                                     | (416) 633-7310 x2874

 
-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      9 Mar 90 20:59:50 GMT
From:      elroy.jpl.nasa.gov!usc!cs.utexas.edu!mailrus!umich!umeecs!itivax!vax3.iti.org!mm@decwrl.dec.com  (Michael McFarland)
To:        tcp-ip@nic.ddn.mil
Subject:   CMOT Implementations


I'm interested in knowing if there are any
implementations of CMOT around either in development
or in use. 

Are people still excited about it?

Is there a consensus on its future?
-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 90 01:04:24 GMT
From:      mmccann@hubcap.clemson.edu (Mike McCann)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Where to get POP?

Where can FTP MacPOP, PCPOP and the server POP files from?

Thanks for any help you can offer,

-- 
Mike McCann       (803) 656-3714   Internet = mmccann@hubcap.clemson.edu 
Poole Computer Center (Box P-21)     Bitnet = mmccann@clemson.bitnet
Clemson University
Clemson, S.C. 29634-2803         DISCLAIMER = I speak only for myself.

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 90 06:08:39 GMT
From:      emv@math.lsa.umich.edu (Edward Vielmetti)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Where to get POP? (RFC 1081, RFC 1082, RFC 937)

(POP, MacPOP, PCPOP?)

On the server side:

My list shows a POP3 (RFC 1081 and RFC 1082) implementation at
lilac.berkeley.edu by the name of "popper", and a POP2 (RFC 937)
implementation on ucdavis.edu by the name of "popd.tar" in the dist
directory.

MH version 6.6 has a POP3 server, from ics.uci.edu.

On the client side:

MIT just announced "TechMail", a MacTCP based POP3 client, from
net-dist.mit.edu.  The announcement should still be in comp.archives
on your site.

There's a NASA MacPOP and PC POP, POP2 based; no anonymous FTP that I
know of, but e-mail to randy@trident.arc.nasa.gov might elicit a
response.  In the Feb-90 comp.archives.  No commercial use, you
might have to do some paperwork to get them.

Stanford has a TCP/IP Mac and PC distribution which includes POP3
clients; I don't have a contact on these off hand, there are
restrictions on use & distribution.

I'm fairly sure that someone has put POP into KA9Q (NET or NOS)
but as far as I know it hasn't made it into the production release.
A pointer to these bits would be welcome.

There are no doubt others, please clue me in, I'll add them to
my RFC Implementations Guide, "already in progress".

--Ed

Edward Vielmetti, U of Michigan math dept.
emv@math.lsa.umich.edu

-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 90 09:46:39 GMT
From:      zaphod.mps.ohio-state.edu!lavaca.uh.edu!uhnix1!sugar!ficc!peter@tut.cis.ohio-state.edu  (Peter da Silva)
To:        tcp-ip@nic.ddn.mil
Subject:   Lachman TCP/IP on System V/386 has rsh, after all.
Thanks for all the help, folks. As I sort of suspected, they called it
something else to avoid conflicting with the (totally useless) restricted
shell. Unfortunately, while I was looking up "remsh" and "rshl" in the
manual and bin, I totally missed "rcmd".

One thing I noted: as installed, rexecd on the Lachman TCP/IP doesn't come up
with a very complete environment. You have to edit the rc script to set HZ.
About the only thing missing from the nifty System V inittab scheme is the
ability to easily set global environment variables for all one's daemons. Not
that I'd want to go back to a random /etc/rc file again.
-- 
 _--_|\  `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/      \  'U`
\_.--._/
      v
-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 90 13:57:47 GMT
From:      haven!uvaarpa!randall@louie.udel.edu  (Randall Atkinson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Use Domain In Hostname Or Not?
I'm with Dave Crocker and that is the way that things will be setup
on the systems whose mail I look after.  Currently it is implemented
a bit differently, but I'll be switching everything around soon.

In reponse to Paul Vixie's comments, I find that the solution is to have
the UA display the name of the sender rather than the userid@domain of
the sender.  The envelope proper always contains fully-qualified mailboxes
and so replys work just fine without troubling the user. 

I happen to use Mush, but I gather that Elm does the same thing,
and there is no reason that other mailers couldn't also do it.
-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 90 14:06:47 GMT
From:      pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!emory!emcard!wa4mei!nanovx!msa3b!kevin@tut.cis.ohio-state.edu  (Kevin P. Kleinfelter)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IBM MVS TCP/IP problems (host file record length too long)
frank@ctycal.UUCP (Frank Lok) writes:

>We are in the process of installing IBM's MVS TCP/IP.  We have discovered
>that the `hosts' file has a record length of 285 characters.  Upon
>attempting to edit this file to add host id's, we are unable to do so
>due to the record length.  Does anyone know how we are expected to
>edit the file.  Attempts to get assistance from IBM have proved
>unsuccessful to this point.

It's a hack, but...
 Write a COBOL program (hey, it IS MVS!!!) that writes this file the way
 want it.

Hack #2:
  Create a version of the file that has a shorter record length, and
  then use IEBGENER or IDCAMS (Access Method Services) to copy the
  file.
  
-- 
Kevin Kleinfelter @ Management Science America, Inc (404) 239-2347
gatech!nanovx!msa3b!kevin
-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 90 14:27:42 GMT
From:      roy@phri.nyu.edu (Roy Smith)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: Where to get POP?

mmccann@hubcap.clemson.edu (Mike McCann) writes:
> Where can FTP MacPOP, PCPOP and the server POP files from?

From one of the various anonymous ftp directories floating about:

ames.arc.nasa.gov                         mmdf, popd, sail, xfer, zmodem, AT&T 
lilac.berkeley.edu         128.32.136.12   POP3 for BSD/Ultrix/SunOS
trout.nosc.mil             26.1.0.3        X11R3, benchmarks, popd, GNU emacs
ucdavis.ucdavis.edu        128.120.2.1     dSLIP, POP2, NetHop, UCDwhois, 

	I also managed to find some pop stuff on eng.clemson.edu.  I'm
currently (as of yesterday) running popper (the pop3 server from
lilac.berkeley.edu) on my Sun-3 running SunOS-3.5.2 (if I remember
correctly, the only change needed was to comment out an #include line for
sys/inode.h) and the SU-Mac/IP 3.0 package (eagerly awaiting 4.0) on my Mac
for a pop client.

	On note of warning.  In the README file that comes with the clemson
server, they say to put:

pop-3           110/tcp                         # Post Office version 3

which I don't think is right.  Shouldn't pop be 109/tcp, or is that just
pop2 and pop3 gets a different port?  At any rate, the pop client included
in the Su-Mac/IP 3.0 package uses 109.  On very frustrating thing is that
the documentation for the Su-Mac stuff doesn't seem to say anywhere whether
it is po2 or pop3.
--
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"

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 90 14:34:13 GMT
From:      shawn@EDDIE.MIT.EDU  (Shawn F. Mckay)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: .netrc
From article <45473@lanl.gov>, by ddk@lanl.gov (David D Kaas):
> 
> 
> 	At our site we have a CRAY and several dozen UNIX workstations.
> We are looking at ways of doing un-atteneded file transfers during off
> hours.  We have started using ftp with .netrc files.  We do have outside
> access to our network.  Now the question, is this considered a security
> problem?  If so how are un-attended file transfers done?
> 
> Thank You
> Dave Kaas
> Boeing Computer Services Richland
> D. O. E.
> Richland, WA 99352
> (509) 376-6386
> e41126%rlvax3.lanl.gov
> -- 
> Dave Kaas - D.O.E. Richland, Wa.
> 	e41126%rlvax3.xnet@lanl.gov

Well, ANY time you have a clear copy of a password in a file on your
system its a security hole. Most people use rcp and its remote host
capability (i.e. .rhosts files and such). If can't use rcp, it would
not be very hard to write a server/client for your machines to do
a simple file copy.

Probably much easier than picking up the peices after someone snarfs
your .netrc file and has passwords to everything in the world.

			Hope this helps,
			   Good Luck,
			    -- Shawn
-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 90 18:19:43 GMT
From:      cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!smsc.sony.com!dce@tut.cis.ohio-state.edu  (David Elliott)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: .netrc
In article <1990Mar10.143413.16539@eddie.mit.edu> shawn@eddie.mit.edu (Shawn F. Mckay) writes:
>Probably much easier than picking up the peices after someone snarfs
>your .netrc file and has passwords to everything in the world.

How much easier is it to get someone's .netrc file than to get
someone's L.sys file, which also has passwords in it?  In both cases
the file is protected, though with the .netrc file, many (all?)
versions of ftp will not even try to use the file if it is readable or
writable by group/other.

-- 
David Elliott
dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce
(408)944-4073
"...it becomes natural, like a third sense." -- Homer Simpson
-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      10 Mar 90 21:10:02 GMT
From:      virtech!cpcahil@uunet.uu.net  (Conor P. Cahill)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Lachman TCP/IP on System V/386 has rsh, after all.
In article <1U42U.Cxds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>About the only thing missing from the nifty System V inittab scheme is the
>ability to easily set global environment variables for all one's daemons. Not
>that I'd want to go back to a random /etc/rc file again.

There is a way.  INIT reads the /etc/TIMEZONE file and processes all 
the 

	variable=value

records, placing the appropriate setting into it's (init's) environment which
will be passed to all child processes of init.

If you place too many variables into the file (and I don't know the count) 
init will just silently ignore the extra ones.

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170 
-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 90 05:01:21 GMT
From:      tank!tank.uchicago.edu!asl2@handies.ucar.edu  (Aaron "Fish" Lav)
To:        tcp-ip@nic.ddn.mil
Subject:   Mac TCP--Info??
What exactly is MacTCP?  Is it a released product?  Is it free?  
In general, if I want to write TCP/IP programs for the Mac and don't
want to reimplement
TCP/IP/UDP/etc myself, what's the recommended thing to do?
                              Thanks,
                              Aaron <><|
asl2@tank.uchicago.edu
-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 90 06:16:26 GMT
From:      bpa!cbmvax!grr@rutgers.edu  (George Robbins)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: .netrc
In article <1990Mar10.181943.23169@smsc.sony.com> dce@Sony.COM (David Elliott) writes:
> In article <1990Mar10.143413.16539@eddie.mit.edu> shawn@eddie.mit.edu (Shawn F. Mckay) writes:
> 
> How much easier is it to get someone's .netrc file than to get
> someone's L.sys file, which also has passwords in it?  In both cases
> the file is protected, though with the .netrc file, many (all?)
> versions of ftp will not even try to use the file if it is readable or
> writable by group/other.

A random sampling of .netrc files will be readable and have the passwords
of "user accounts".  Even if a L.sys file is readable, it contains only
the "uucp" passwords which almost always grant only the limited access that
the remote system has via uucp, usually a public directory and not much
else.

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)
-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      11 Mar 90 19:06:33 GMT
From:      shelby!neon!neon!gumby@decwrl.dec.com  (David Vinayak Wallace)
To:        tcp-ip@nic.ddn.mil
Subject:   .netrc: obsolete
There's no reason in this day and age still to be shipping passwords
around in cleartext.  Better to use some form of encrypted capability
`tickets' a la kerberos (to pick an example).
-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Mar 90 04:06:06 PST
From:      Van Jacobson <van@helios.ee.lbl.gov>
To:        tots!niven!tep@logicon.com (Tom Perrine)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Postscript RFCs and LazerWriters
The problem is not with the RFC:  you are the victim of your Sun's
obsolete version of Transcript.  As a work-around, change the
first line of the postscript RFC from "%!PS-Adobe..." to just "%!".
It should then print.  Attached is a message from Adobe describing
the problem.

 - Van

-------------
From: greid@adobe.com (Glenn Reid)
Newsgroups: comp.lang.postscript
Subject: %%[ Error: undefined; OffendingCommand: BEGINPAGE ]%%
Date: 17 May 89 21:43:33 GMT
Organization: Adobe Systems Incorporated, Mountain View

A few have you have reported problems printing files retrieved from the
Adobe PostScript File Server.  The symptom were either no output (if
you don't have a mechanism for catching PS errors) or the "undefined"
error on "BEGINPAGE".  I had trouble reproducing this, but I have
finally discovered what the problem is.

PROBLEM:
    You have an old version of our TranScript spooling software that
    does page reversal incorrectly.  The definitions for "BEGINPAGE"
    are not visible to the program because the "Setup" section of the
    document gets reversed to the end of the document wiht Page 1,
    which is a bug.

SOLUTION:
    The easiest thing is to add a single line to the beginning of
    the file that contains just %! (this is the same as editing out
    the "PS-Adobe-2.0" from the first line).  This will cause the
    TranScript program to believe that it is not allowed to reverse
    the pages, and the problem will go away.

    More complicated alternatives are either to turn off page reversal
    for the printer (see TranScript documentation) or to edit the
    PostScript language file to allow page reversal to work correctly.
    This means either moving %%EndProlog after the %%EndSetup comment
    (which is not strictly a good idea, but will work around the
    problem) or getting rid of all instances of either "PROLOGUE begin"
    or the corresponding calls to "end".  This still leaves the
    encoding vector at the end, in the wrong place, but I think most
    documents should print OK.  You might see "yen" symbols instead of
    bullets or other minor quirks.  It might be easier just to run
    "psrev" to reverse the pages and then hand-edit the setup section
    back to the beginning.

    Of course, you could always upgrade your version of TranScript, too.
    Send mail to "psmith@adobe" to do that, or call 1-800-344-8335.

Thanks to all of you who point it out, and sorry about the problems.

Glenn Reid
Adobe Systems
-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Mar 90 03:38:36 EST
From:      "Ralph E. Droms" <droms%sol.bucknell.edu@CORNELLC.cit.cornell.edu>
To:        tots!niven!tep@Logicon.COM
Cc:        tcp-ip@nic.ddn.MIL
Subject:   Re: Postscript RFCs and LazerWriters


   I have recently FTP'ed this Postscript RFC...

Which PostScript RFC?  The author will likely be interested so the
problem can be fixed.

   ...and have been unable to
   print it using either of our Postscript printers (LazerWriters and
   LazerWriter NTs). The printer returns an error message to the host:

     %%[ Error: undefined; OffendingCommand: SmallCapsFont ]%%
     %%[ Flushing: rest of job (to end-of-file) will be ignored ]%%

   (...)

   Just another vote for ASCII-only RFCs.

I think the consensus is that PostScript RFCs should be accompanied by
a) a hard-copy source for problems like you have encountered and b) an
ASCII version for computerized perusal (e.g., grep).


- Ralph Droms                 Computer Science Department
  droms@sol.bucknell.edu      323 Dana Engineering
  droms@bknlvms (BITNET)      Bucknell University
  (717) 524-1145              Lewisburg, PA 17837
-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Mar 90 09:31:33 PST
From:      braden@venera.isi.edu
To:        mtxinu!sybase!forrest%sybase.com@ucbvax.berkeley.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  TCP Incompatibilities in RFC 793 vs RFC 1122?
	I am wondering if anybody is concerned about an seeming incompatibility
	in TCP implementations meeting RFC 793 compared to RFC 1122. From
	what I can see, the meaning of the urgent pointer has changed.
	(I should mention that what I am about to say was passed on to me
	by someone else. I haven't actually read the RFC's except for the
	passages quoted below).

Jon,

I will resist commenting on this sentence, but some of the 1000s of other
busy people who read this list may not, so you might be prepared for
some flames from them.

	RFC 793 says (page 17) that the urgent pointer points to "the sequence
	number of the octet following the urgent data." . RFC 1122 says
	(page 84, section 4.2.2.4) that RFC 793 is wrong and that "the urgent
	pointer points to the sequence number of the LAST octet (not LAST+1)
	in a sequence of urgent data.".

The old partial-quote trick.  This is one sentence from a two sentence
paragraph. As the sentence you didn't quote makes clear, RFC-793
was AMBIGUOUS on the meaning of urgent, and the Host Requirements RFC
removes the ambiguity.  Some implementations had done it one way, so
another, so urgent has long been broken.  However, if you use reasonable
defensive programming in the Telnet use of Urgent, I think one can survive.
Hopefully, the problem will be eased as implementations compliant with
RFC-1122 gradually become dominant.

Bob Braden


-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Mar 90 10:00:02 PST
From:      tots!niven!tep@Logicon.COM (Tom Perrine)
To:        snoopy!sri-nic.arpa!tcp-ip
Subject:   Re: Postscript RFCs and LazerWriters
OOPS! My first posting to tcp-ip in over a year and I $%(^%$#-up the
subject line.

I *was* having trouble with RFC 1144. However, thanks to Van
Jacobson's note about changing "%!PS-Adobe..." to "%!", I was able to
print the RFC this morning.  Unfortunately, the machines with the
Transcript software are in "final acceptance testing" for delivery to
the government, and we can't upgrade the software :-(

Thanks to all,
Tom Perrine (tep)
Logicon (Tactical and Training Systems Division) San Diego CA (619) 455-1330
Internet: tep@tots.Logicon.COM		GENIE: T.PERRINE
UUCP: nosc!hamachi!tots!tep -or- sun!suntan!tots!tep
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Mar 90 16:46:48 -0800
From:      chris@salt.acc.com (Chris VandenBerg)
To:        snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil
Cc:        gary@salt.acc.com
Subject:   vendor MIB exchanges
Good Morning Folks!
		  For the last few months I've tried to find a way
to facilitate the exchange of various vendor-specific portions of
MIB's. I raised this at the SNMP demo group meeting for Interop and
got some positive responses that this was a GOOD THING. The attitude
seems to be " you show me yours and I'll show you mine". Understandable
that everyone wants a quid pro quo arrangement but how to do it?
		  I asked a few people about various possibilities and
truly want to thank Dave Crocker for his input. I guess Dave had attacked
the problem some months ago but it would appear that the vendor community
wasn't ready to take this step. He did send me a list of questions that
he and Phil Gross had talked about regarding the permanence of the
archive and how formal should it get. Keeping these points in mind I feel
this central MIB archive would have to:
	a. allow fairly quick archival with a minimum of administrative
	overhead and hassle.
	b. allow for change within an archived MIB without the sky
	falling.
	c. allow a semi-permanent resting place for MIB info so that
	when someone needs to check another vendors' MIB for any
	reason, they instinctively look there FIRST.
		  I would like to float a suggestion on how to solve the
problem. I have spoken with Joyce Reynolds at ISI (the lucky person who
gets to keep track of all those Enterprise numbers (:*) ) and she has
given a conditional OK to archiving MIB's online at venera.isi.edu. But
before I put her to any trouble or ask her to start the wheels turning
I'd like to know what everyone thinks of this. On the surface it would 
seem that this is a workable solution. For SNMP to realize its true
potential we must all be able to exploit the features each vendor has
built into their products. A central clearinghouse should facilitate
the exchange of this information, yet not allow any competitve advantage
to a particular vendor. ISI would seem to be about as impartial as they
come.
		  On the surface this should benefit both agent and NMS 
vendors and, most definitely, the end users. They have been 
hearing about "Standard Management" for awhile now, and this might help
provide it in a more timely manner, without running around from
vendor to vendor. Additionally, this would make the Interop SNMP demo
much easier to accomplish.
		  Please cast your vote (or send your flame) asap.
		  Thanks,
			 Chris VandenBerg (chris@salt.acc.com)
			 ACC 805-903-9431
-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 90 03:54:20 GMT
From:      att!mcdchg!laidbak!stevea@ucbvax.Berkeley.EDU  (Steve Alexander)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: rsh(1) for System V/386, Lachman TCP/IP
In article <M342BY8xds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>For some reason Lachman TCP/IP doesn't come with a remote shell program that 
>I can find anywhere... just >rlogin.

Try rcmd.  Unless your vendor removed it.
--
Steve Alexander, Software Technologies Group    | stevea@i88.isc.com
INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea
-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 90 14:35:36 GMT
From:      nisca.ircc.ohio-state.edu!hpuxa.ircc.ohio-state.edu!bobd@tut.cis.ohio-state.edu  (Bob Debula)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: fax via digital data
I have already replied directly to Cliff, but if anyone else is 
interested, I can also send you our lengthy (which is why I did not
post it here) summary of the Ohio State University FAX/Internet

bobd@hpuxa.ircc.ohio-state.edu

if you are interested and I will send you a copy of the documents
that I've written thus far.

In brief, we are creating the software to enable you to use
PCs with Quadram JT FAX 9600 FAX boards and WD8003E Ethernet boards
(also hard drives, etc.) as FAX gateways to the Internet.  We are
basing this product on a modified version of Phil Karn's KA9Q software.

==========================================================================
Bob DeBula                    | Internet:   bobd@hpuxa.ircc.ohio-state.edu
The Ohio State University     | Disclaimer: These are my views, not the U's
Davros sez:   When my Daleks compute they use X-TER-MI-NALS!
-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 90 16:57:01 GMT
From:      zaphod.mps.ohio-state.edu!uwm.edu!ogicse!littlei!leonardo.intel.com!davidl@tut.cis.ohio-state.edu  (David D. Levine)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: rsh(1) for System V/386, Lachman TCP/IP
> > This is for Lachman TCP/IP, if that matters. For some reason Lachman TCP/IP
> > doesn't come with a remote shell program that I can find anywhere... just
> > rlogin.
> 
> Try nsh.  LAI couldn't call it rsh because of a name conflict with the SysV
> restricted shell.  BTW, it uses rcmd(), not rexec().

In Intel's System V/386 v3.2 with Lachman TCP/IP, the "rsh" command is
called "rcmd".  Isn't name space pollution the pits?

- David D. Levine, Intel IMSO Tech Pubs
  davidl@leonardo.intel.com
  "Mr. LaForge, when I turned this ship over to you, it was in one piece!"
-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Mar 90 17:21:48 GMT
From:      Mills@udel.edu
To:        "H. Craig McKee" <mckee@community-chest.mitre.org>
Cc:        Van Jacobson <van@helios.ee.lbl.gov>, tcp-ip@nic.ddn.mil
Subject:   Re:  new version of tcpdump available
Craig,

Golly gee, aren't you the chap that wrote "How slow is a gigabit?" For
everything we do in the new giganet we will have to horse the decimal
point at least three places to the left. I even know of a time protocol
that can gigatick to .0002 microsecond, so be prepared for another three
or four places.

Even in today's meganet, centisecond clocks are too course. It is not
hard and with proof established by systems now ticking in the Internet to
achieve millisecond precision. We have in fact come a long way in CPU
horsepower, but have forgotten to heighten our expectation of timing
precision accordingly.

Dave
-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 90 18:07:30 GMT
From:      rti!sas!kent@mcnc.org  (Paul Kent)
To:        tcp-ip@nic.ddn.mil
Subject:   Terminate session negotiation??
In article <9003062033.AA05387@berserkly.cray.com> dab@berserkly.cray.com (David Borman) writes:
>
>Hi there.
>
>Attached is a list of all the TELNET options.  This is the list that

>         2     Reconnection                            ... 15391 yes  no
>        18     Logout                                  727 40025 yes  no

Hello, 

Thanks to responses to my first questions to this group, i now have a
client/server application that "talks" over the telnet virtual
terminal. Whats especially nice is that it supports code that has
already shipped to our users (the code thinks its talking at a RS232 
style connection)

I have noticed that the behaviour of the server (remote) process varies
from telnet to telnet, when the client (local) dies or otherwise drops
the connection.

KNET and IBM for VM systems leave the CMS session "disconected", as does
apollo AEGIS. So far, i havent found a way to reconnect to the apollo one :-)

VMS(wollongong) effectively kill the process and "logoff" the user. As do
some unixen, and MVS.


option 18(logout) is imperative. IE "LOGOUT NOW"

i dont have the text for 15391, and am wondering if it is passive, IE
"LOGOUT if the connection fails for any reason"

My application would prefer the remote session to "logoff" if the connection
is severed. Is this something that the remote session has to do for itself
once it realises the connection is gone, or can it be negotiated from the
source side? -- my remote side is already in the field, so changing it aint
as easy as adding to the source side.

or am i being too hopeful as no-one appears to honor either options.

thanks,
paul.
-- 
---- nothing ventured, nothing disclaimed ----
paul kent, SAS Institute, box 8000, cary nc 27512-8000 -- 919 467 8000
.... {seismo|mcnc}!rti!sas!kent   --or perhaps--  sas!kent@rti.rti.org
-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 90 18:50:30 GMT
From:      logicon.arpa!Makey@nosc.mil  (Jeff Makey)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Is there a sTaNdArD??
In article <9003100448.AA26049@jessica.Stanford.EDU> almquist@JESSICA.STANFORD.EDU ("Philip Almquist") writes:
>	The model used by the domain name system for host names is that
>the owner of a name gets to choose its case.

This isn't strictly true in practice.  I recently registered my
"Logicon.COM" domain and the NIC refused my request to have it listed
that way instead of as "LOGICON.COM".  While the primary and secondary
servers for this domain have the "correct" case, the root servers all
squawk upper case for both the nameserver RR and the .IN-ADDR.ARPA RR.
Thus, most of the rest of the world sees nothing but upper case.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: Logicon doesn't even know we're running news.
    Internet: Makey@Logicon.COM    UUCP: {nosc,ucsd}!logicon.com!Makey
-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      Mon, 12 Mar 90 18:34:35 +0100
From:      pansiot%isis.u-strasbg.fr@CUNYVM.CUNY.EDU (Jean-Jacques Pansiot Departement d'Informatique, Universite Louis Pasteur Strasbourg FRANCE)
To:        TCP-IP@SRI-NIC.ARPA
Subject:   broadcast storm
I know that there is a phenomenon called broadcast storm, and i thing  our
network has this kind of problem. Here is the situation:

We use a class B network (130.79) over ethernet.
>From time to time some stations (lets call them type A) send a broadcast,
with address 130.79.255.255 (I believe this is the correct Broadcast IP Address)
Currently such broadcasts are RWHO  or RIP.
Some stations (lets call them type B), retransmit the same packet(  as if they
were IP routers) on the same ethernet, with TTL decreased by one. Moreover,
they seem to receive their own retransmission, so the whole thing repeats
 itself,
until TTL is decreased from 15 to 0.

Some stations (lets call them type C), when receiving these packets,
send an ARP request for IP address
130.79.255.255. They do not recognize it as a broadcast address. I understand
that IP broadcast was formerly all 0. But why this ARP ? , as if they
wanted to route the packet  (as type B stations do ).

Fortunately, only one station (for now) is of type B. Still , for  1
(correct) broadcast, we have 15 * number of type C stations   packets.
At the end there is also some ICMP TTL Exceeded and ICMP Destination Unreach.
Very much for one broadcast. We could try to kill all rwhod, but I don't see
how to avoid RIP messages from our gateway if we wanto use routed on
our station?

Anybody to explain the behaviour of stations B and C?

Anything I can do? (Stations B and C
are mostly SunOS 3.5 , no SUNOS4.0). I do not , of course, have
the power to do upgrades on these machines, but I could recommend doing
a few changes (ifconfig....)

any help? may be this is a well known problem?

jean-jacques Pansiot, Universite Louis Pasteur, Strasbourg, France
pansiot@isis.u-strasbg.fr

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      12 Mar 90 22:53:41 GMT
From:      ladcgw!hermes!fmayhar@uunet.uu.net  (Frank Mayhar)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: new version of tcpdump available
(I sent mail.  No response.  I'll try this.)

For those poor benighted heathens (such as myself) without FTP, is this
available
for anonymous uucp anywhere?  Or, perhaps, from some mail archive server?
I have the old version of tcpdump, gotten from uunet.  It's very useful.  Looks
like the new version would be even more useful, _if_ I can get my hands on it.

Thanks in advance!
--
Frank Mayhar  fmayhar@hermes.ladc.bull.com (..!{uunet,hacgate}!ladcgw!fmayhar)
              Bull HN Information Systems Inc.  Los Angeles Development Center
              5250 W. Century Blvd., LA, CA  90045    Phone:  (213) 216-6241
-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 90 01:08:28 GMT
From:      cs.utexas.edu!usc!elroy.jpl.nasa.gov!jpl-devvax!mike@tut.cis.ohio-state.edu  (Mike Tankenson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Postscript RFCs and LazerWriters
In article <9003120838.AA01632@regulus.bucknell.edu> droms@sol.bucknell.EDU ("Ralph E. Droms") writes:

>I think the consensus is that PostScript RFCs should be accompanied by
>a) a hard-copy source for problems like you have encountered and b) an
>ASCII version for computerized perusal (e.g., grep).

I just FTP'd Van Jacobson's Compressed SL/IP RFC (in Postscript) and had a
terrible time trying to print it out.  Our Sun Laserwriters would simply
munch on the file and produce *nothing*.  No errors, no title page with
rejected file message, nada.  We finally had to copy the file to an AT (!!)
running DOS, which used a piece of TOPS software to send it to an Apple
laser printer.

I'm no Postscript expert, so I cannot tell exactly what the problem was,
but I suspect that our Sun Laserwriters do not under all the fancy fonts in
this RFC.  Could we specify that RFCs in Postscript use only standard,
well-known fonts?
-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 90 04:51:08 GMT
From:      hayes@apple.com  (Jim Hayes)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mac TCP--Info??
asl2@tank.uchicago.edu (Aaron "Fish" Lav) writes:
> What exactly is MacTCP?  Is it a released product?  Is it free?  
> In general, if I want to write TCP/IP programs for the Mac and don't
> want to reimplement
> TCP/IP/UDP/etc myself, what's the recommended thing to do?

I've posted this for others as well as Aaron instead of using E-mail.
This is not an advertisement.  This is FYI.

Officially:

	MacTCP is a software driver for the Macintosh Operating System
	that allows developers to create Macintosh applications for
	network environments that use TCP/IP.

	MacTCP is a site-licensed product for developers.  It can be 
	ordered via the Apple Software Licensing Department.

	Dunno if it costs anything.

Functionally:

	MacTCP is an implementation of TCP/IP for the native Macintosh
	OS.  It supports socketed UDP datagrams, TCP streams, ICMP
	messages, Domain Name Service (DNS) name resolution, static,
	dynamic and server based IP address assignment.   It also
	understands the "routed" routing information protocol.  It has a
	"control panel" interface.

	This is a DRIVER and not application level software.

	It is co-resident with other drivers, including AppleTalk, so you can
	use AppleTalk AND MacTCP simultaneously.

Technically:

	Programs you create that use MacTCP may pass data buffers into and
	out of the driver, or, use a scatter-gather buffer arrangement to
	eliminate buffer copying.  It uses standard driver calls like PBOpen,
	PBClose and PBControl.

	On LocalTalk (or Ethernet networks with no IP routing capabilities),
	MacTCP can encapsulate TCP/IP in AppleTalk packets for later
	decomposition at an AppleTalk/IP bridge on the destination network. 
	(I.e. Kinetics FastPath, Cayman GatorBox, etc.)

Reality:

	Writing your first program using MacTCP is like writing your first
	BSD UNIX client/server-- It hangs, it crashes, it misbehaves.  But
	once you perfect it, re-using your code is simple provided you put
	some thought into its design.

	If you are going to use it, I recommend Object Pascal or
	C++.  Make "connection objects" in which you create instances of
	TCP or UDP "connections" that have "read" and "write" methods.
	It gives you reusable code and makes good cognitive sense.  If
	you're not into objects, traditional methods work well too.


-- 
Jim Hayes, TCP/IP Weenie
Advanced Technology Group, Apple Computer Inc.

Inet: hayes@apple.com		 UUCP: {amdcad|decwrl|ames}!apple!hayes
-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 90 06:29:13 GMT
From:      steve@wattres.UUCP (Steve Watt)
To:        comp.protocols.tcp-ip
Subject:   Does anyone know of/have a spec for bootp?

Is there an RFC for bootp?  If not, does anybody know who to mail to find
out what the "proper" protocol is?

For those who don't know:  bootp is a way of telling a diskless workstation
its internet address, and (it appears from the scanty docs I have) downloading
a file to it.
-- 
Steve Watt
...!claris!wattres!steve		wattres!steve@claris.com also works
If you torture your data long enough, it'll eventually confess.

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      Tue, 13 Mar 90 22:51:39 PST
From:      Dave Crocker <dcrocker@nsl.dec.com>
To:        Ole J. Jacobsen <OLE@csli.stanford.edu>
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Is there a sTaNdArD??
Ole,

My vote(s) -- I don't think there is any absolute, so "preference'
is the best that we are likely to get --

If the string is basically a word, then standard English capitalization
rules probably are best, although there seem to be some cases in
which total lower case is best.  If the string is an acronym or a
generally random string, the world seems to prefer all caps.

PERSONALLY I FIND ALL CAPS TO BE TOO  MUCH LIKE SHOUTING, NOT TO MENTION
THAT IT LOOKS LIKE YOU ARE STUCK IN A TIME WARP, USING A TTY MODEL 30.

The all-lowercase preference, for me, applies when the string is
used in a machine-versus-human context.  Hence, I prefer my email
address to be shown as:

	Dave Crocker <dcrocker@nsl.dec.com>

rather than

	Dave Crocker <DCrocker@NSL.DEC.Com>

or somesuch.

D/ or d/
.
-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 90 15:20:17 GMT
From:      bbn.com!craig@bbn.com  (Craig Partridge)
To:        tcp-ip@nic.ddn.mil
Subject:   wrong Craig
> Craig
>
> Golly gee, aren't you the chap that wrote "How slow is a gigabit?"
> 

Dave:
    
    Wrong Craig... Unfortunately, there appear to be just enough Craigs
on the network to confuse folks.  Not as bad a problem as we have with all
these Daves on the network <Mills, Cheriton, Clark, Tennenhouse, Farber,
Sincoskie, Piscitello, ....> but apparently enough to cause trouble.

    Personally, I'm a firm believer in getting our time down to the
smallest clock tick we can.  On a giganet, a one millisecond timer
doesn't tell you a whole lot.  You'd need a few megabits of congestion
before you could be sure the timer was telling you something.

Craig (Partridge)
-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 90 15:23:18 GMT
From:      jeremy@cs.swarthmore.edu (Jeremy Brest)
To:        comp.protocols.tcp-ip
Subject:   Traceroute info wanted


I've seen a bunch of references to traceroute in discussions on this
group.  Where can I get it, and do I need kernel mods to make it work?

Thanks,

Jeremy Brest
Swarthmore College

jeremy@cs.swarthmore.edu

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 90 16:39:29 GMT
From:      emv@math.lsa.umich.edu (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Traceroute info wanted

In article <9N8FR5M@xavier.swarthmore.edu> jeremy@cs.swarthmore.edu (Jeremy Brest) writes:

   I've seen a bunch of references to traceroute in discussions on this
   group.  Where can I get it, and do I need kernel mods to make it work?

   Jeremy Brest
   Swarthmore College

There's a complete traceroute package available for ftp from
zerkalo.harvard.edu [128.103.40.201] in the file
pub/traceroute_pkg.tar.Z (I think it's on uunet as well).  This is
code from Mike Karels, Van Jacobson, and Bill Nowicki, packaged up by
Manavendra K. Thakur with instructions on how all the pieces fit
together.

If you have Suns running SunOS 4.x this will work for sure,
with some luck it won't be necessary for x >= 1.

I guess I've heard of versions of traceroute for other systems;
I know it's been done on top of KA9Q, on top of the NIT interface,
and perhaps on other systems as well.

--Ed
Edward Vielmetti, U of Michigan math dept.
emv@math.lsa.umich.edu

-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 90 18:24:36 GMT
From:      excelan!jerryh@ames.arc.nasa.gov  (Jerry Huang)
To:        tcp-ip@nic.ddn.mil
Subject:   test
This is just a test, please ignore this message.
.
-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 90 18:42:23 GMT
From:      excelan!jerryh@ames.arc.nasa.gov  (Jerry Huang)
To:        tcp-ip@nic.ddn.mil
Subject:   FTPtest
I am implementing a TCP/IP FTP client program on PC/DOS and would like
to conduct some testings against differnet FTP servers.

So far, I am not able to find any VMS host running either CMC or Fusion
FTP server to test against. If you do have either of these two FTP servers
in your environment and allow me to do Anonymous access to it, 
please let me know.

I only need to do two very simple tests:

	1. The long directory listing format.

	2. The Ascii file format downloaded using binary mode.

Your help is appreciated!

Thanks.
-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 90 19:21:20 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Postscript RFCs and LazerWriters

In article <7389@jpl-devvax.JPL.NASA.GOV> mike@jpl-devvax.JPL.NASA.GOV (Mike Tankenson) writes:
>I just FTP'd Van Jacobson's Compressed SL/IP RFC (in Postscript) and had a
>terrible time trying to print it out.  Our Sun Laserwriters would simply
>munch on the file and produce *nothing*...
>I'm no Postscript expert, so I cannot tell exactly what the problem was,
>but I suspect that our Sun Laserwriters do not under all the fancy fonts in
>this RFC...

The other side of this is that I FTPed it and printed it on our QMS PS810.
No problem.  Now, you have to understand that our spooling software is
dumb, dumb, dumb:  it just pumps the bytes out to the printer, and does
nothing to them in the process.  The PS810 is not exactly the world's
smartest PostScript printer, either.  So it seems pretty likely that it's
your software, not the document.  (For a guess, it's the known problem
with old versions of Transcript botching page reversal.)
-- 
MSDOS, abbrev:  Maybe SomeDay |     Henry Spencer at U of Toronto Zoology
an Operating System.          | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 90 21:02:39 GMT
From:      psuvm!pmw1@psuvax1.cs.psu.edu  (Peter Weiss)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IBM MVS TCP/IP problems (host file record length too long)
In article <343@ctycal.UUCP>, frank@ctycal.UUCP (Frank Lok) says:
>
>We are in the process of installing IBM's MVS TCP/IP.  We have discovered
>that the `hosts' file has a record length of 285 characters.  Upon
>attempting to edit this file to add host id's, we are unable to do so
>due to the record length.  Does anyone know how we are expected to
>edit the file.  Attempts to get assistance from IBM have proved
>unsuccessful to this point.

I allocated a RECFM=FB LRECL=255 sequential dataset and copied the
HOSTS.LOCAL file to it, since the maximum character position used was
254.  ISPF/PDF Edit was able to process this.  I then used MAKESITE
from TSO (required a _large_ region) and tried out the TSO cmd
TESTSITE.

Issue the TSO cmd H MAKESITE for add'l info.

I did NOT actually use the newly created datasets HOSTS.ADDRINFO and
HOSTS.SITEINFO in the MVS TCP/IP environment, so caveat emptor.
--
Peter M. Weiss                   |  (this line intentionally left blank)
31 Shields Bldg (the AIS people) | Don't FAX me, I'll FAX you!
University Park, PA USA 16802    | Disclaimer :1 * applies herein
-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 90 21:21:06 GMT
From:      emv@math.lsa.umich.edu (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Does anyone know of/have a spec for bootp?

(BOOT-P?)

BOOTP is described in RFC 951 and RFC 1048.

I know of publicly available code for it from
lancaster.andrew.cmu.edu (the CMU BOOTP server),
there may be other server implementations out there
for the asking.

You'll probably need to implement TFTP as well, that's
RFC 783.

--Ed
Edward Vielmetti, U of Michigan math dept.
emv@math.lsa.umich.edu

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Mar 90 11:05:39 -0800
From:      chris@salt.acc.com (Chris VandenBerg)
To:        chris@salt.acc.com, pgross@NRI.Reston.VA.US, snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil
Cc:        gary@salt.acc.com, jkrey@isi.edu
Subject:   Re: vendor MIB exchanges
Phill,
	Thanks for the additional points to keep in mind. I think Gary
Malkin at Proteon brought up the same format question right away and
I think it's something we need to hash out. I did, however, make a solemn
promise to Joyce that this wouldn't add significantly to her workload
and I feel honor-bound to keep that promise. So I will try and voice that
concern with regards to suggestions on how to do all this. 
	I'll probably wait for the end of the week to roll around then 
look at all the great ideas we've gotten to see if we can reach a concensus
on how to implement this beast.
			thanks again,
					Chris VandenBerg(chris@salt.acc.com)
PS - Keep those opinions and ideas coming in folks!
-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 90 21:49:40 GMT
From:      emv@MATH.LSA.UMICH.EDU (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Traceroute info wanted

(traceroute atop KA9Q)

Tracked this one down, here's the readme off of
ucdavis.ucdavis.edu:disk/nethop.readme

HOPCHECK (traceroute) for KA9Q Internet Software Package
 
HOPCHECK for the NOS version of KA9Q is now available
via anonymous FTP from ucdavis.ucdavis.edu in the
directory   dist/traceroute

HOPCHECK for version 871225.26 is still available
via anonymous FTP from ucdavis.ucdavis.edu in the
directory   dist


-- Katie Stevens
   dkstevens@ucdavis.edu
   Computing Services
   University of California, Davis

---and this from dist/traceroute/readme

KA9Q Internet Software Package with HOPCHECK command (02-16-90)
====================================================

Files available via anonymous FTP from ucdavis.ucdavis.edu
dist/traceroute directory:

NETHOP.ARC      -- compiled code; KA9Q with HOPCHECK
SRC.ARC         -- source code; unmodified distribution file for
                   KA9Q Internet Software Package v900124 NOS
HOPSRC.ARC      -- source code; additional files for HOPCHECK


-- Katie Stevens
   dkstevens@ucdavis.edu
   Computing Services
   University of California, Davis

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Mar 90 07:32:43 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        steve@wattres.uucp
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: Does anyone know of/have a spec for bootp?

Steve:
    
    The BOOTP specs are RFCs 951 and 1084.

    Note that there's an IETF WG led by Ralph Droms currently working
on a general host configuration protocol designed to make booting
diskless nodes easier (and safer) to do.  They expect to finish up
their protocol design this year.

Craig
-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      13 Mar 90 23:22:49 GMT
From:      thorin!brock!brock@mcnc.org  (J. Dean Brock)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: traceroute info (w/o kernel mods)

And, as mentioned before, if you want to run a traceroute on SunOS 3.5,
and now 4.0, without kernel mods, you can FTP pub/traceroute-3.5.tar.Z
or pub/traceroute-4.0.tar.Z from dopey.cs.unc.edu [128.109.136.82].

These programs use the NIT interface.  Hopefully, such extreme measures to
avoid kernel mods will become unnecessary when SunOS 4.1 is available.
-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 90 01:11:04 GMT
From:      hp-ses!hpcuhb!hpindda!dfc@hplabs.hpl.hp.com  (Don Coolidge)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: BROADCAST ADDRESS ON HP-UX.
Patches are available for the 6.5 and 7.0 releases that provide the
capability to arbitrarily ifconfig an interface's IP broadcast
address. With 8.0, that will be a supported function; no patch
will be needed. As yet, there's no such patch for 3.0.

For earlier releases (through 6.2 on the 300; through 2.1 on the 800)
I don't believe any such patch is currently planned. 

Of course, all the abovementioned releases will accept either
ones or zeroes as broadcasts on inbound packets; it's only for
outbound that they default to ones.

Caveat: Even with the ability to ifconfig a broadcast address, your
mixing of various machines can still prove to be incompatible if
they have differing levels of subnet sophistication...


- Don Coolidge
------------------------------------------------------------------------------
Usual Disclaimer: I'm speaking for myself, not necessarily for HP
------------------------------------------------------------------------------
-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Mar 90 08:40:01 EST
From:      "Phillip G. Gross" <pgross@NRI.Reston.VA.US>
To:        Chris VandenBerg <chris@salt.acc.com>, snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil
Cc:        gary@salt.acc.com, jkrey@isi.edu
Subject:   Re: vendor MIB exchanges
Chris,

Let me cast a vote in favor of your suggestion to make MIB information 
widely available.

A couple suggestions -

- you may want to consider a common format and presentation of the MIB
info.  The format you choose might depend on what audience you wish to
reach (eg, developers may be comfortable reading ASN.1, but end users
would probably prefer a text description).

- you might consider taking an approach similar to that taken by the
folks who put together the NOC Tools catalog in the IETF.  They developed
a template to insure that the information was presented in a consistent
and common format across all entries. Then they organized the various 
entries into categories, and supplied some additional descriptive 
boilerplate information.  In the end, they produced a very complete 
and useful document.  

This may be a larger task than you had planned.  However, since Joyce 
Reynolds is also the chair of the IETF User Services Working Group and 
keeper of the F.Y.I. series of informational RFCs, you might ask her 
if she would be willing to help organize such an effort.

In any case, I encourage and applaud your suggestion.

Phill Gross
-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 90 09:06:00 EST
From:      "HQEIS::MCDANIEL" <mcdaniel%hqeis.decnet@hqafsc-vax.af.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   RE: is there a STANDARD
Andrews AFB

                  I N T E R O F F I C E   M E M O R A N D U M

                                        Date:     14-Mar-1990 08:48am EST
                                        From:     Mr Rodney McDaniel
                                                  MCDANIEL
                                        Dept:     HQ AFSC/SCXP
                                        Tel No:   AV 858-7909 COMM 981-7909
                                        Owner:    Mr Rodney McDaniel

TO:  _MAILER!                             ( _DDN[TCP-IP@NIC.DDN.MIL] )


Subject: RE: is there a STANDARD


Can't speak for the INTERNET world, however in milnet DDN world
Mil-Std 1781 SMTP applies which under paragraph 4.1.3 gives you 
the choice of either UPPER or lower case mailbox user names.
However host names are not case sensitive.

Reviewing alot of email on a daily basis (50 or more) most host 
names are reflected in the lower case, when received.  Really 
don't see this as an issue whether you use UPPER or lower case 
host names but rather an individual host administrator or systems 
manager preference, and besides if I receive the email message it 
doesn't matter what text case is used for the host name but 
getting the information is the important part.

PERSONALLY, I PREFER UPPER CASE BUT WE ALL HAVE OUR PERFERENCES 
and some things really don't need to be standardized and HOST 
NAMES DOESN'T SEEM TO HAVE ANY IMPACT ON HOW THE MAIL IS 
DELIVERED, WHICH IS THE BOTTOM LINE.  GETTING THE INFORMATION FROM 
POINT A TO POINT B.

Also is this really a TCP-IP issue???


RODNEY A. MCDANIEL
AFSC DDN PROGRAM MANAGER
ANDREWS AFB MD
EMAIL ADDRESS: mcdaniel@hqafsc-vax.af.mil or 
               mcdaniel@HQAFSC-VAX.AF.MIL 


-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Mar 90 09:38:00 EST
From:      <FILLMORE%EMRCAN.bitnet@ugw.utcs.utoronto.ca>
To:        tcp-ip@NIC.DDN.MIL
Subject:   NJE-over-TCP (Bitnet II) software for Sun?

The subject line pretty well sums it up:  is anyone aware of a product
or product under development which implements the NJE protocols used by
Bitnet over TCP/IP, running under the SunOS environment?
________________________
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
-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 90 04:45:03 GMT
From:      uhccux!munnari.oz.au!kaukau.comp.vuw.ac.nz!comp.vuw.ac.nz!massey!GMoretti@ames.arc.nasa.gov  (Giovanni Moretti)
To:        tcp-ip@nic.ddn.mil
Subject:   Need POPUP messages for PC-NFS, HOW?
We are running a Campus net based on PC-NFS and need for our users (and
our) peace of mind, to be able to send them messages from the server,
such as 

   "Server going down in 10 minutes - air conditioning failed ..."

which will cause a dialog box to pop up in the middle of whatever they're
doing and wait for an acknowledgement.  I've just started using the
appointments feature in PCTools v 5.1 and it does exactly this, as long
as the PCTools DESKTOP is resident, but it's designed for appointments
not comms through a network.

I know such things never happen and therefore this service will never be
used :-) but has anyone written something like this for PCNFS ?

It's a nasty feeling to try and save a file after working for a while and
finding that the server's disappeared out from under you.

It would also be useful for NEW MAIL ARRIVED ... 

Hopefully yours
Giovanni

-- 
-------------------------------------------------------------------------------
|   GIOVANNI MORETTI, Consultant     | EMail: G.Moretti@massey.ac.nz          |
|Computer Centre,  Massey University | Ph 64 63 69099 x8398, FAX 64 63 505607 |
|   Palmerston North, New Zealand    | QUITTERS NEVER WIN, WINNERS NEVER QUIT |
-------------------------------------------------------------------------------
-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Mar 90 09:45:18 EST
From:      "Bill Rubin" <RUBINM%YKTVMV.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: IBM MVS TCP/IP problems (host file record length too long)
Apologies if this is a duplicate message, I believe it was rejected
when I tried yesterday, the cryptic message was not particularly clear.

gatech!nanovx!msa3b!kevin (Kevin Kleinfelter) writes:

>frank@ctycal.UUCP (Frank Lok) writes:
>
>>We are in the process of installing IBM's MVS TCP/IP.  We have discovered
>>that the `hosts' file has a record length of 285 characters.  Upon
>>attempting to edit this file to add host id's, we are unable to do so
>>due to the record length.  Does anyone know how we are expected to
>>edit the file.  Attempts to get assistance from IBM have proved
>>unsuccessful to this point.
>
>It's a hack, but...
> Write a COBOL program (hey, it IS MVS!!!) that writes this file the way
> want it.
>
>Hack #2:
>  Create a version of the file that has a shorter record length, and
>  then use IEBGENER or IDCAMS (Access Method Services) to copy the
>  file.
>
>--
> Kevin Kleinfelter @ Management Science America, Inc (404) 239-2347
> gatech!nanovx!msa3b!kevin

The problem is that ISPF, the TSO editor, does not support lines of
greater than 255 characters.  The solution to this is to create a
version of the hosts file with lines of less than 256 characters.  This
can be done in the following way:  create a dataset with RECFM=VB,
LRECL=259 (255+4 bytes for the length fields).  Then use ISPF 3.3 to
copy the original hosts dataset to this new dataset.  You will get a
warning that the dataset attributes are incompatible, but you should
ignore this and allow the copy to continue.  You'll then end up with
an editable dataset.  The truncated data won't cause any problems for
the MVS TCP/IP product, because it only looks at the node names and
addresses, anyway, and they do not go that far out of the line.

By the way, there is a Bitnet mailing list dedicated to the IBM TCP/IP
products, IBMTCP-L@CUNYVM.CUNY.EDU.  To subscribe, send mail to
LISTSERV@CUNYVM.CUNY.EDU, with a line in the body of your mail
'SUBSCRIBE IBMTCP-L' followed by your name.  Please don't send requests
to IBMTCP-L-Request, it will only truncate the userid and send the
request to the whole list.

Bill Rubin
IBM TJ Watson Research
-------
-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Mar 90 12:59:51 PST
From:      Paul Mockapetris <pvm@venera.isi.edu>
To:        Dave Crocker <dcrocker@nsl.dec.com>
Cc:        "Ole J. Jacobsen" <OLE@csli.stanford.edu>, tcp-ip@NIC.DDN.MIL
Subject:   Re: Is there a sTaNdArD??/Up against the wall fascist pigs!
The right policy is:

Let people express their preferred capitalization in their own data
supplied to the DNS.  Thus the NIC gets to decide between EDU and edu
for everybody, but Berkeley gets to pick BERKELEY, berkeley, Berkeley,
etc. in Berkeley.EDU (or whatever)

Match case-insensitively.

Preserve the case of data you get.

paul
-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Mar 90 15:12:56 PST
From:      Dave Crocker <dcrocker@nsl.dec.com>
To:        pvm@venera.isi.edu
Cc:        "Ole J. Jacobsen" <OLE@csli.stanford.edu>, tcp-ip@nic.ddn.mil
Subject:   Re: Is there a sTaNdArD??/Up against the wall fascist pigs!
Paul,

I vote in favor of your rule-set.
-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Wed 14 Mar 90 16:46:29-PST
From:      William "Chops" Westfield <BILLW@MATHOM.CISCO.COM>
To:        tcp-ip@NIC.DDN.MIL
Subject:   XNS protocol types...
Does anyone have a list of XNS protocol types and/or socket numbers in
common use? (similar to the assigned numbers tcp document, or the list
of ethernet typecodes that gets requested periodically.)

Yes, I know this has little to do with tcp-ip, but this IS where the
experts tend to "hang out".

Thanks
Bill W
-------
-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Wed 14 Mar 90 14:07:14-EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        dcrocker@nsl.dec.com
Cc:        OLE@csli.stanford.edu, tcp-ip@NIC.DDN.MIL
Subject:   Re: Is there a sTaNdArD??
Dave--

Presumably, you wouldn't want your name to be all lowercase if the system
your mailbox was on expected some (or even, historically, all) of the
letters to be uppercase.  Since there are still some systems which WOULDN'T
treat "DCrocker" the same as "dcrocker" (even after the much lamented demise
of MIT-MULTICS), I suggest that a better approach would be as follows:

Conservation of Therbligs dictates that Host names be represented in lowercase
(especially since an RFC long about 822 dictated that Host names should be
case-"insensitive"/-irrelevant, as you doubtless recall better than I), but
user/mailbox-name components of netmail "addresses" must be whatever casing
they must be.

(I won't mention how long ago it was that we first went 'round and 'round
on case considerations if you won't--but if you think it's less than 16
years you're wrong, since it was while I was still at MIT....)

    cheers, map

P.S. The years do mellow one somewhat: in case "therbligs" is obscure, it's
from industrial engineering/time-and-motion-studies and has to do with
minimal/quantizable human motions/movements.  (Named after one Gilbreth, who
"invented" 'em, as I recall.)  Thus, another way of putting the "rule" is:

Be shiftless where it doesn't matter, but not where it does.
-------
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 90 12:32:43 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: Does anyone know of/have a spec for bootp?


Steve:
    
    The BOOTP specs are RFCs 951 and 1084.

    Note that there's an IETF WG led by Ralph Droms currently working
on a general host configuration protocol designed to make booting
diskless nodes easier (and safer) to do.  They expect to finish up
their protocol design this year.

Craig

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 90 14:06:00 GMT
From:      mcdaniel%hqeis.decnet@HQAFSC-VAX.AF.MIL ("HQEIS::MCDANIEL")
To:        comp.protocols.tcp-ip
Subject:   RE: is there a STANDARD

Andrews AFB

                  I N T E R O F F I C E   M E M O R A N D U M

                                        Date:     14-Mar-1990 08:48am EST
                                        From:     Mr Rodney McDaniel
                                                  MCDANIEL
                                        Dept:     HQ AFSC/SCXP
                                        Tel No:   AV 858-7909 COMM 981-7909
                                        Owner:    Mr Rodney McDaniel

TO:  _MAILER!                             ( _DDN[TCP-IP@NIC.DDN.MIL] )


Subject: RE: is there a STANDARD


Can't speak for the INTERNET world, however in milnet DDN world
Mil-Std 1781 SMTP applies which under paragraph 4.1.3 gives you 
the choice of either UPPER or lower case mailbox user names.
However host names are not case sensitive.

Reviewing alot of email on a daily basis (50 or more) most host 
names are reflected in the lower case, when received.  Really 
don't see this as an issue whether you use UPPER or lower case 
host names but rather an individual host administrator or systems 
manager preference, and besides if I receive the email message it 
doesn't matter what text case is used for the host name but 
getting the information is the important part.

PERSONALLY, I PREFER UPPER CASE BUT WE ALL HAVE OUR PERFERENCES 
and some things really don't need to be standardized and HOST 
NAMES DOESN'T SEEM TO HAVE ANY IMPACT ON HOW THE MAIL IS 
DELIVERED, WHICH IS THE BOTTOM LINE.  GETTING THE INFORMATION FROM 
POINT A TO POINT B.

Also is this really a TCP-IP issue???


RODNEY A. MCDANIEL
AFSC DDN PROGRAM MANAGER
ANDREWS AFB MD
EMAIL ADDRESS: mcdaniel@hqafsc-vax.af.mil or 
               mcdaniel@HQAFSC-VAX.AF.MIL 

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 90 14:45:18 GMT
From:      RUBINM@YKTVMV.BITNET ("Bill Rubin")
To:        comp.protocols.tcp-ip
Subject:   Re: IBM MVS TCP/IP problems (host file record length too long)

Apologies if this is a duplicate message, I believe it was rejected
when I tried yesterday, the cryptic message was not particularly clear.

gatech!nanovx!msa3b!kevin (Kevin Kleinfelter) writes:

>frank@ctycal.UUCP (Frank Lok) writes:
>
>>We are in the process of installing IBM's MVS TCP/IP.  We have discovered
>>that the `hosts' file has a record length of 285 characters.  Upon
>>attempting to edit this file to add host id's, we are unable to do so
>>due to the record length.  Does anyone know how we are expected to
>>edit the file.  Attempts to get assistance from IBM have proved
>>unsuccessful to this point.
>
>It's a hack, but...
> Write a COBOL program (hey, it IS MVS!!!) that writes this file the way
> want it.
>
>Hack #2:
>  Create a version of the file that has a shorter record length, and
>  then use IEBGENER or IDCAMS (Access Method Services) to copy the
>  file.
>
>--
> Kevin Kleinfelter @ Management Science America, Inc (404) 239-2347
> gatech!nanovx!msa3b!kevin

The problem is that ISPF, the TSO editor, does not support lines of
greater than 255 characters.  The solution to this is to create a
version of the hosts file with lines of less than 256 characters.  This
can be done in the following way:  create a dataset with RECFM=VB,
LRECL=259 (255+4 bytes for the length fields).  Then use ISPF 3.3 to
copy the original hosts dataset to this new dataset.  You will get a
warning that the dataset attributes are incompatible, but you should
ignore this and allow the copy to continue.  You'll then end up with
an editable dataset.  The truncated data won't cause any problems for
the MVS TCP/IP product, because it only looks at the node names and
addresses, anyway, and they do not go that far out of the line.

By the way, there is a Bitnet mailing list dedicated to the IBM TCP/IP
products, IBMTCP-L@CUNYVM.CUNY.EDU.  To subscribe, send mail to
LISTSERV@CUNYVM.CUNY.EDU, with a line in the body of your mail
'SUBSCRIBE IBMTCP-L' followed by your name.  Please don't send requests
to IBMTCP-L-Request, it will only truncate the userid and send the
request to the whole list.

Bill Rubin
IBM TJ Watson Research
-------

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      Wed, 14 Mar 90 17:20:05 -0100
From:      Philippe Prindeville <philipp@Gipsi.Gipsi.Fr>
To:        mckee@community-chest.mitre.org
Cc:        TCP-IP <tcp-ip@nic.ddn.mil>
Subject:   Re: new version of tcpdump available
	Van - What kind of issues/questions do you address that requires a
	resolution of 1 us rather than 20 ms?   Regards - Craig

Yeah, at 1us resolution, your position on the network cable
becomes more critical than the resolution of your clock...

-Philip
-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 90 17:14:42 GMT
From:      ogicse!zephyr.ens.tek.com!orca.wv.tek.com!nevermore!alanj@decwrl.dec.com  (Alan Jeddeloh;685-2991;61-201;292-9740;orca)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Does anyone know of/have a spec for bootp?
In article <EMV.90Mar13162106@duby.math.lsa.umich.edu> emv@math.lsa.umich.edu (Edward Vielmetti) writes:
-(BOOT-P?)

-BOOTP is described in RFC 951 and RFC 1048.

RFC1048 has been superceded by RFC1084.  (The only difference that I
see is the addition of a few more "standard" Vendor Information fields.)

Vanilla BOOTP provides a way for a diskless node to discover its internet
address, the server IP address, a gateway IP address (for cross-gateway
booting), the server host name and the boot file name/path.  RFC951 provides
for additional "Vendor Specific Information" fields.

RFC's 1048/1084 define some "standard" vendor information fields, such as
the subnet mask, time offset, lists of gateways and servers (name servers,
print servers, etc) and other information.

BOOTP does not specify the method of file transfer, although the RFC's
imply the next step after getting the BOOTP reply is to transfer the file
using TFTP.  I suppose you could also use NFS, but TFTP is usually a simpler
task. ( :-) )

The other method for determining the internet address is to use Reverse
ARP (RARP).  All RARP gives you is the internet address, so you have to
have some pre-arranged idea of where the server is located and what the
file name is.  A common assumption is that the file server is the same
as the host that replied to the RARP request, and that the file name is
some known or computable value, such as the internet address expressed
in hex.

Both BOOTP and TFTP sit on top of UDP, so you need at least a rudimentary
UDP/IP stack to handle booting.

    -Alan Jeddeloh      (503) 685-2991
    Tektronix ITD Networking; D/S 60-180; PO Box 1000; Wilsonville, OR 97070
    UUCP: {decvax|ucbvax}!tektronix!orca!nevermore!alanj
    INTERNET: alanj@nevermore.wv.tek.com       Quoth the printer, "Nevermore!"
-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 90 17:38:06 GMT
From:      csusac!unify!antares!bob@ucdavis.ucdavis.edu  (Bob Paauwe)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: rsh(1) for System V/386, Lachman TCP/IP
In article <M342BY8xds13@ficc.uu.net>, peter@ficc.uu.net (Peter da Silva) writes:
> Does anyone have source for the 'rsh' program for System V/386?
> Any tips or code would be appreciated.
> 
> This is for Lachman TCP/IP, if that matters. For some reason Lachman TCP/IP
> doesn't come with a remote shell program that I can find anywhere... just
> rlogin.

I have Lachman and Wallongong.  There is a command in Lachman called 'rcmd'
and one in Wallongong called 'remsh'.  These both allow remote execution
of commands.  Is this what you are looking for?  The syntax for 'rcmd' is
  $ rcmd remote_node -l user -n command
The -n tells the rcmd to use /dev/null as standard input.

-- 
Bob Paauwe                 ________________________    Any resemblence to a
bpaauwe@folsm1.intel.com               |      REAL opinion is unintentional.
/-----------------___________________/---\___________________-----------------\
!ames!pacbell!sactoh0!mcdre3!bpaauwe \___/      I'd rather be Gliding!!!!!
-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 90 19:17:43 GMT
From:      eru!luth!sunic!bmc!bio.embnet.se!mats@bloom-beacon.mit.edu  (Mats Sundvall)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mac TCP--Info??
In article <39441@apple.Apple.COM>, hayes@Apple.COM (Jim Hayes) writes:
> asl2@tank.uchicago.edu (Aaron "Fish" Lav) writes:
> Reality:
> 
> 	Writing your first program using MacTCP is like writing your first
> 	BSD UNIX client/server-- It hangs, it crashes, it misbehaves.  But
> 	once you perfect it, re-using your code is simple provided you put
> 	some thought into its design.
> 
> 	If you are going to use it, I recommend Object Pascal or
> 	C++.  Make "connection objects" in which you create instances of
> 	TCP or UDP "connections" that have "read" and "write" methods.
> 	It gives you reusable code and makes good cognitive sense.  If
> 	you're not into objects, traditional methods work well too.
> 

So, do I have to write the connection objects myself, or has anyone
done it?

> 
> -- 
> Jim Hayes, TCP/IP Weenie
> Advanced Technology Group, Apple Computer Inc.
> 
> Inet: hayes@apple.com		 UUCP: {amdcad|decwrl|ames}!apple!hayes

	Mats Sundvall
	University of Uppsala
	Sweden
-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      14 Mar 90 22:27:47 GMT
From:      elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!wuarchive!kuhub.cc.ukans.edu!jian@decwrl.dec.com
To:        tcp-ip@nic.ddn.mil
Subject:   Where are RFCs??
Would anyone tell me where I can get RFCs on the public domain. Thanks in
advance.
                                            Jian
                                            jian@kuhub.cc.ukans.edu
-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 90 02:50:12 GMT
From:      agate!berkeley.edu!austins@ucbvax.Berkeley.EDU  (Austin Shelton)
To:        tcp-ip@nic.ddn.mil
Subject:   POP3 Server Version 1.5 Available
Version 1.5 of the Berkeley POP3 server is available for
testing.  This server implements the Post Office Protocol
version 3 and extensions as described in RFCs 1081 and 1082.
This package also includes a POP3 HyperCard client for the
Macintosh.

The server can be obtained via anonymous ftp to 
lilac.Berkeley.EDU (128.32.136.12).  It is in compressed
tape format as "popper.tar.Z" in the "pub" directory.
Please retrieve this during off-hours since this computer
is already over-worked.  Thank you.

Austin Shelton
Data Communication and Network Services
University of California at Berkeley
-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Mar 90 08:49:00 EST
From:      mpm@proteon.com (Mike P. McDonough)
To:        elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!wuarchive!kuhub.cc.ukans.edu!jian@decwrl.dec.com, tcp-ip@nic.ddn.mil
Subject:   Re:  Where are RFCs??
FTP sri-nic.arpa (10.0.0.51)
userid: anonymous
passwd: "any id"

ftp>get rfc:rfcXXXX.txt

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 90 04:46:58 GMT
From:      cbmvax!grr@uunet.uu.net  (George Robbins)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: new version of tcpdump available
In article <1990Mar12.225341.19966@ladc.bull.com> fmayhar@hermes.ladc.bull.com writes:
> 
> For those poor benighted heathens (such as myself) without FTP, is this
> available
> for anonymous uucp anywhere?  Or, perhaps, from some mail archive server?
> I have the old version of tcpdump, gotten from uunet.  It's very useful.  Looks
> like the new version would be even more useful, _if_ I can get my hands on it.

The new version is now on uunet as: ~/networking/tcpdump.tar.Z

-- 
George Robbins - now working for,     uucp:   {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing:   domain: grr@cbmvax.commodore.com
Commodore, Engineering Department     phone:  215-431-9349 (only by moonlite)
-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Mar 90 15:38:47 -0500
From:      H. Craig McKee <mckee@smiley.mitre.org>
To:        tcp-ip@nic.ddn.mil
Cc:        bashmore@mwvm.mitre.org
Subject:   pcnfs driver
A colleague needs a PC/NFS driver for a UB NIC-PS/2 card on 
a PC running MS-DOS.  Anybody have something close/exact?

Thanks - Craig  (703)883-5505
-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Mar 90 14:15:00 EST
From:      Haggar (H.) Alsaleh <HAGGAR@BNR.CA>
To:        tcp-ip@nic.ddn.mil
Subject:   ANSI Doc.
Greetings,
could some one tell me how/where can I get

      IEEE Documents

      ISO  Documents

through the internet.


          Thanks in advance......Haggar@bnr.ca

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Mar 90 15:12:34 -0100
From:      Philippe Prindeville <philipp@Gipsi.Gipsi.Fr>
To:        BILLW@MATHOM.CISCO.COM
Cc:        TCP-IP <tcp-ip@nic.ddn.mil>
Subject:   Re:  XNS protocol types...
From Appendix D of my Grey Book (which is never out of
my reach [call me sentimental]):

	Assigned well-known socket numbers

	Routing Information		1
	Echo				2
	Router Error			3
	Experimental		    40-77

From Appendix E of same:

	Assigned internet packet types

	Routing Information		1
	Echo				2
	Error				3
	Packet Exchange			4
	Sequenced Packet		5
	Experimental		    20-37

Beware of IPX, which does not heed the Xerox number space.

-Philip
-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Mar 90 15:16:42 -0100
From:      Philippe Prindeville <philipp@Gipsi.Gipsi.Fr>
To:        pvm@venera.isi.edu
Cc:        TCP-IP <tcp-ip@nic.ddn.mil>
Subject:   Re: MX Records
Is it time yet to decree that A records should not be used in
lieu of the MX records when delivering mail?  It would seem
that the "transition" period is well commenced, and it is
time to cut-over...

-Philip
-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Mar 90 15:24:11 -0100
From:      Philippe Prindeville <philipp@Gipsi.Gipsi.Fr>
To:        jones@emx.cs.utexas.edu
Cc:        TCP-IP <tcp-ip@nic.ddn.mil>
Subject:   Re: rlogind/named interaction?
	I wonder how much this is contributing to the 15% named traffic that
	NSFNET is seeing, see the the JANUARY 3-4 IAB MEETING notes?

You know, I was wondering (and I daresay loosing some sleep) about
this, where this fantastic amount of traffic was coming from.  Now
I know, it's those scores of Crays that keep eating up bandwidth...

-Philip
-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Thu, 15 Mar 90 20:18:00 EST
From:      Haggar (H.) Alsaleh <HAGGAR@BNR.CA>
To:        tcp-ip@nic.ddn.mil
Subject:   IEEE/ISO Doc.
Greetings,
could some one tell me how/where can I get

      IEEE Documents

      ISO  Documents

through the internet.
PS: thanks for the response on the ANSI Doc.(which can not
be retrieved through internet).
          Thanks in advance......Haggar@bnr.ca

-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 90 19:49:27 GMT
From:      austins@berkeley.edu (Austin Shelton)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   POP3 Docs in Alternate Formats

Some people have expressed a desire to get the POP3 server
documentation in formats other than MS Word 4.0.  So I
have saved it in MS Word 3.0, MacWrite and Text formats and
saved the popper diagram in MacPaint and PICT formats (the
original was done using Canvas).  These are all in an
archive called "MacPOP.sit.hqx" in the "pub" directory
accessible via anonymous ftp to lilac.berkeley.edu
(128.32.136.12).  Again, please try to retrieve this
during off-hours.  Thanks,

Austin Shelton

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      15 Mar 90 20:14:09 GMT
From:      zaphod.mps.ohio-state.edu!samsung!umich!ox.com!sendai!rich@tut.cis.ohio-state.edu  (K. Richard Magill)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mac TCP--Info??
Before you get your hopes up...

In article <39441@apple.Apple.COM> hayes@Apple.COM (Jim Hayes) writes:

   Functionally:

	   It is co-resident with other drivers, including AppleTalk,
	   so you can use AppleTalk AND MacTCP simultaneously.

This isn't quite true.  Somehow there are collisions on a number of
annoying things on my se30 with a dove ether board.  I don't know
whose fault they are, (maybe mine), but when using net at all, (even
over ether), you can't configure your printer port to do much of
anything.  Also, you really have to reconfigure and reboot if you want
to use a) macTCP things vs b) old style ncsaTelnet vs well, you get
the idea.

   Technically:

	   On LocalTalk (or Ethernet networks with no IP routing
	   capabilities), MacTCP can encapsulate TCP/IP in AppleTalk
	   packets for later decomposition at an AppleTalk/IP bridge
	   on the destination network.  (I.e. Kinetics FastPath,
	   Cayman GatorBox, etc.)

But not vice verse.  ie, appletalk in ip, a la kip, so you would still
need a gateway to do CAP.
-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 90 01:09:16 GMT
From:      ubvax!csr@uunet.uu.net  (Chris Ranch)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mac TCP--Info??
In article <RICH.90Mar15151409@sendai.sendai.ann-arbor.mi.us> rich@sendai.ann-arbor.mi.us writes:
>Before you get your hopes up...
>
>In article <39441@apple.Apple.COM> hayes@Apple.COM (Jim Hayes) writes:
>
>   Functionally:
>
>	   It is co-resident with other drivers, including AppleTalk,
>	   so you can use AppleTalk AND MacTCP simultaneously.
>
>This isn't quite true.  Somehow there are collisions on a number of
>annoying things on my se30 with a dove ether board.  I don't know
>whose fault they are, (maybe mine), but when using net at all, (even
>over ether), you can't configure your printer port to do much of
>anything.  Also, you really have to reconfigure and reboot if you want
>to use a) macTCP things vs b) old style ncsaTelnet vs well, you get
>the idea.

I must say that you can have MacTCP _AND_ AppleTalk operate concurrently
at full speed.  This is the way it's designed.  Personally I've tried,
successfully, to be downloading a file from applelink using a Shive Netmodem,
logged on to 3 different IP hosts over MacTCP, 'cat'ting big files to the
emulation windows, and printing BIG files to a laserwriter, all at the
same time at reasonable performance.  This is with Apple's EtherTalk card,
AppleTalk configured to EtherTalk Phase 2, and MacTCP configured to use
the Ethernet directly.

Well written software should do this.

Regards,


-- 
Chris Ranch
Ungermann-Bass, Inc
(408)562-7957      csr@ubvax.ub.com
-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Mar 90 09:13:49 PST
From:      tkostan@trwind.TRW.COM (Tyson Kostan)
To:        elroy.jpl.nasa.gov!usc!cs.utexas.edu!mailrus!umich!umeecs!itivax!vax3.iti.org!mm@decwrl.dec.com, tcp-ip@nic.ddn.mil
Subject:   Re:  CMOT Implementations

I can give you a DoD view on the subject.  I work for TRW and we are the 
supplier of TCP/IP componants to the Air Force under the ULANA (Unified
Local Area Network Architecture) contract -- a requirements contract which
will soon spread across all of the DoD.  The Air Force has decided (or maybe
better put, not decided) that they will do both.  Under our contract, we will
have to provide a manager which can speak both CMOT and SNMP.  Our initial
feeling on this subject was that this requirement came about due to 3COM's
support of CMOT and not SNMP.  I'm not too sure about this view at this time.

3COM claimed that it would have CMOT agents for all of its devices, but I'm
not sure how far they have come with that.  Now they are touting SNMP.

DEC claims to be an ISO shop, and will be providing managers which support
both CMOT and SNMP capabilities.

I was reciently at COM-Net '90, and I didnt see any support for CMOT, where
support for SNMP was everywhere, either in the form of managers, agents or
proxy devices.

In my opinion, ever since CMOT and SNMP went their own seperate ways (when the
MIB split), SNMP has completely taken center stage, and bumped CMOT to the 
shadows.  Only time will tell...

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 90 03:40:35 GMT
From:      imagen!atari!portal!portal!cup.portal.com!Scott_A_Dalrymple@ucbvax.Berkeley.EDU
To:        tcp-ip@nic.ddn.mil
Subject:   RFCs via auto email
In response to a request for how to get RFCs online:
Here are two ways to get RFCs:

I. via 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.
HOST xxx        Returns information about host xxx.  WHOIS xxx can
                also be used to get more details about a host.
IEN nnn         nnn is the IEN number or the word INDEX.
NETINFO xxx     xxx is a file name or the word INDEX.
RFC nnn         nnn is the RFC number or the word INDEX.
SEND xxx        xxx is a fully specified file name.
WHOIS xxx       Returns information about xxx from the WHOIS service.
                Use "WHOIS HELP" for information on how to use WHOIS.

Example SUBJECT lines:

    HELP
    RFC 822
    RFC INDEX
    NETINFO DOMAIN-TEMPLATE.TXT
    SEND RFC:ASSIGNED-NUMBERS.TXT
    HOST SRI-NIC.ARPA
    WHOIS LOTTOR, MARK

I recommend you start with a subject of
RFC INDEX

No text is needed in the actual body of the email message.
This way, you can pick and choose what you want.

Another good subject is:
SEND NETINFO:00NETINFO-INDEX.TXT

This will give you a list of non-RFC documents that are available.

II. via cic:

Send mail to: info-server@sh.cs.net
No subject is necessary.

In the body of the message:
REQUEST: INFO
TOPIC: HELP

This will tell you how to do it.  In a nutshell, this is:

Send mail to: info-server@sh.cs.net
No subject is necessary.

In the body of the message:
REQUEST: RFC
TOPIC: RFC123
TOPIC: RFC1000
 ...etc...
REQUEST INFO
TOPIC: ???
TOPIC: ???
 ...etc...

 etc...

REQUEST: END


This should do you...

Scott Dalrymple          Scott_A_Dalrymple@cup.portal.com
Computer Sciences Corp.  * DISCLAIMER:  If CSC ever found out what I've *
Hanover, MD  21076       * I've said here, they would probably deny it! *
-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 90 04:29:37 GMT
From:      eru!luth!sunic!dkuug!freja.diku.dk!rimfaxe.diku.dk!shotokan@bloom-beacon.mit.edu  (Kim H|glund)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Where are RFCs??
jian@kuhub.cc.ukans.edu writes:
>Would anyone tell me where I can get RFCs on the public domain. Thanks in
>advance.

They are available for anonymous ftp from ftp.diku.dk (129.142.96.1)
in /pub/rfc.

Enjoy,
  Kim

_____
Kim Hoeglund				E-mail: shotokan@diku.dk
Systems Administrator
Univ of Copenhagen Comp Sci Dept
-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 90 05:14:22 GMT
From:      hayes@apple.com  (Jim Hayes)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Mac TCP--Info??
This topic is being moved to comp.sys.mac.programmer.  My apologies
for wasting comp.protocols.tcp-ip bandwidth.

rich@sendai.ann-arbor.mi.us writes:
>Before you get your hopes up...
>
>In article <39441@apple.Apple.COM> hayes@Apple.COM (Jim Hayes) writes:
>
>   Functionally:
>
>	   It is co-resident with other drivers, including AppleTalk,
>	   so you can use AppleTalk AND MacTCP simultaneously.
>
>This isn't quite true.  Somehow there are collisions on a number of
>annoying things on my se30 with a dove ether board.  I don't know
>whose fault they are, (maybe mine), but when using net at all, (even
>over ether), you can't configure your printer port to do much of
>anything.  Also, you really have to reconfigure and reboot if you want
>to use a) macTCP things vs b) old style ncsaTelnet vs well, you get
>the idea.

1) Printer port problems:  Check with Dove.  My guess is that it's their
   driver doing it.  We havn't seen those problems.  The EtherTalk driver 
   allows attaching and detaching of protocol handlers (based on the "type"
   field in the packet) to the card so multiple protocols can be processed
   simultaneously.
2) NCSA Telnet 2.3 supports MacTCP.  Earlier versions of NCSA Telnet
   do not follow Apple's guidelines for accessing the EtherTalk driver and
   as such may interfere with MacTCP, AppleTalk, etc.

>   Technically:
>
>	   On LocalTalk (or Ethernet networks with no IP routing
>	   capabilities), MacTCP can encapsulate TCP/IP in AppleTalk
>	   packets for later decomposition at an AppleTalk/IP bridge
>	   on the destination network.  (I.e. Kinetics FastPath,
>	   Cayman GatorBox, etc.)
>
>But not vice verse.  ie, appletalk in ip, a la kip, so you would still
>need a gateway to do CAP.

1) It works both ways.  The Kinetics FastPath will RE-ENCAPSULATE IP back
   into AppleTalk so it may return to the source.  
2) CAP does not require "gateways" (what the author defines as a gateway)
   because it looks like an ordinary AppleTalk device.


-- 
Jim Hayes, TCP/IP Weenie
Advanced Technology Group, Apple Computer Inc.

Inet: hayes@apple.com		 UUCP: {amdcad|decwrl|ames}!apple!hayes
-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 90 07:47:30 GMT
From:      munk@cstw69.prl.philips.nl (Harm Munk)
To:        phil.comm,comp.dcom.lans,comp.os.vms,comp.protocols.tcp-ip
Subject:   rsh for VAX/VMS ?


Hi Netlanders,

I wonder if you can shed some light on the following problem. We're re-working
an application, which is currently available on VAX/VMS and Unix, to work in
multiplatform fashion, i.e. we have a bunch of machines , some running Unix,
others VAX/VMS and maybe a number of PC's running MS-DOS or OS/2 and PCSA or PC-NFS, and we want our application to run on all these platforms. For it be able
to run properly, we must be able to start applications across platform
boundaries. Now, for Unix, we do this with rsh. However, we have not yet found
a way to do this on VAX/VMS, on which we have TCP/IP running. Do you have a
solution ? We're looking for suggestions that do not require us to program on
the socket or connection level. Rather, we're looking for a VAX/VMS-
implementation of rsh. But, then again, all suggestions are welcome.

Thanks in advance.

I'll post a sumary in four weeks from today (March 15, 1990)

--------------------------------------------------------------------------
Harm Munk.                                       |Standard Disclaimer:
Centre for Software Technology, Philips Eindhoven| file not found.
PO BOX 80000                                     |
5600 JA  EINDHOVEN                               |
The Netherlands                                  |
--------------------------------------------------------------------------

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 90 08:19:01 GMT
From:      eru!luth!sunic!ericom!erix.ericsson.se!eua.ericsson.se!euarrd@bloom-beacon.mit.edu  (Richard Rosenlund)
To:        tcp-ip@nic.ddn.mil
Subject:   Crypto equipment for serial lines
I am looking for information about equipment that can provide
crypto services for serial lines (V35 and T1).

If you have relevant information, please reply by E-mail.

Thank You.

+-------------------------------------------------------+
!    P Richard G Rosenlund                              !
!    Networking group                                   !
+-------------------------------------------------------+
!    Ellemtel Telecommunications Systems Laboratories   !
!    S-125 25 STOCKHOLM Sweden                          !
!    Phone   : +46 8 727 3000  Fax  : +46 8 47 82 76    !
+-------------------------------------------------------+
!    E-mail  : Richard.Rosenlund@eua.ericsson.se        !
+-------------------------------------------------------+
-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Mar 90 16:21:52 PST
From:      sjvdp@water.ca.gov (San Joaquin Valley Drainage Program)
To:        tcp-ip@nic.ddn.mil
Subject:   RARP
	We are integrating a number of PC's onto our building-wide Ethernet.
We are using NCSA Telnet as the user platform on the PC's, but do not want
to get stuck in the position of having to install an individual configuration
file on each PC.  We also do not want to have users swapping the config
files with each other, thus misdirecting us as to which user logged onto
which PC did what.  (I.E., for security reasons, we want each PC to have
one Internet number assigned to it).

	On the side of the larger systems, we currently have 4 VAXes of
various sizes running VMS and a number of UNIX systems, (SUN, Apollo, Plexus).
would like to have RARP on at least one of these systems so we can keep
a centralized database of Ethernet to Internet number conversions.

	Any pointers to a RARP server would be greatly appreciated.

-HWM

----------
Henry W. Miller
Assistant Systems Manager, Mid Pacific Region
U.S. Bureau of Reclamation
2800 Cottage Way MP1100
Sacramento, CA 95825
(916) 978-5108 / FTS 460-5108
Inet:	"sanj!henrym@caldwr.water.ca.gov"
BITNET:	"hmiller@scu"
UUCP:	"...caldwr!sanj!henrym"

"Bad guys abuse public land, good guys save it."
-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 90 08:22:37 GMT
From:      bywater!acheron!archet!larouch!yozzo@uunet.uu.net  (Ralph Yozzo)
To:        tcp-ip@nic.ddn.mil
Subject:   What makes the NFS Nfsd's and Biod's fast?
I was wondering what allows the Biod's and Nfsd's
to speed up NFS performance. 

Since each Nfsd's is a separate process,
do each Nfsd have their own Mount Protocol Client pointer
and NFS protocol Client pointer?
 
 This would add up to a lot of UDP connections 
 if the machine mounts a lot of other machines. 
  
I assumes that one possible benefit of parallel RPC 
requests is to parallelize the XDR functions.
But I looked at the XDR functions for READ encode
and READ decode and they are very small and 
do not take a long time to execute. 
 
 Could someone set me straight on this
 or direct me to a good reference? 



==Ralph E. Yozzo == 
==Arpanet: yozzo@ibm.com==
==Bitnet: yozzo@yktvmx.bitnet==
==Home: ..!uunet!bywater!acheron!larouch!yozzo ===Ph:(914)945-3634 or 564-4731
-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 90 16:54:31 PST (Friday)
From:      Herbst.ESAE@Xerox.COM
To:        tcp-ip@nic.ddn.MIL
Cc:        herbst.ESAE@Xerox.COM
Subject:   Level-of-Service Metrics papers or comments
Hello -
I am attempting to develop metrics to be used in network engineering for
multiprotocol LANs and WANs.   These metrics would help define
Level-of-Service commitments, identify performance problem areas, and
confirm problem resolution.
I assume that the metrics would have to be statistically based, due to the
contention based networks and protocols in use.  

The networks to be engineered are Ethernets with routers and point to point
serial connections.  The protocols are mainly XNS and TCP/IP with some
DECNet and IPX. Many of the LANs have large amounts of NFS traffic.  There
are vast amounts of data that can be captured from cisco routers, Sun
servers, Sniffers, and such, but no formal process for interpreting it.

Pointers to any published papers would be appreciated, as would any
comments or recommendations.

thank you -

tom 
-----------------------------------------
Thomas Herbst
Network Consultant
Xerox Corporation
El Segundo, CA
herbst.esae@xerox.com
-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      Fri, 16 Mar 90 23:17:22 -0500
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        tkostan@trwind.TRW.COM (Tyson Kostan)
Cc:        usc!cs.utexas.edu!mailrus!umich!umeecs!itivax!vax@elroy.jpl.nasa.gov, 3.iti.org!mm@decwrl.dec.com, tcp-ip@nic.ddn.mil
Subject:   Re: CMUT Implementations

Keep it in perspective, when you bring a full grown Bengal Tiger out
on stage it is pretty clear that it is going to knock off a paper tiger.

Now the question is will SNMP knock out CMIP itself in the area of NMS/agent
management within the OSI stack.  Despite the denials of Mr. Crocker
who represents both DEC and the ISEG/IETF collegium, thank goodness
we at least have the safety net of meer rationality,
market forces, user demand, and other standards
groups to work within to give us the possability of useful mechanisms
to manage OSI networks in parallel with tcp/ip networks for the 20-30
years.

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

> In my opinion, ever since CMOT and SNMP went their own seperate ways (when the
> MIB split), SNMP has completely taken center stage, and bumped CMOT to the 
> shadows.  Only time will tell...

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 90 19:06:48 GMT
From:      elroy.jpl.nasa.gov!zardoz.cpd.com!dhw68k!fedeva!bill@decwrl.dec.com  (Bill Daniels)
To:        tcp-ip@nic.ddn.mil
Subject:   XENIX TCP/IP - Bad Hertz Value
I have a problem that is present on 386-PC running Xenix 2.3.2 and the 
streams-based TCP-IP extension.  When I "rsh" any command to the Xenix
box from an DEC Ultrix Ver. 3.1. system, the Xenix unit seems to perform
whatever task that I ask of it but when it finishes a message "Bad Hertz
Value" is printed on the controlling tty on the DEC.  Any clues?

bd
-- 
bill daniels
federal express, memphis, tn
{hplabs!csun,mit-eddie!premise}!fedeva!wrd3156
-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      16 Mar 90 22:16:47 GMT
From:      mmccann@hubcap.clemson.edu (Mike McCann)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Cap5.0 ftp site?

I know that cunixc.cc.columbia.edu has the tar file for CAP5.0 but this
version still has some bugs in it from what I have heard.  Is there a
FTP archive somewhere that has CAP5.0 with all the patches already
installed?  I don't want to do it just in case I miss a few.

Thanks for any help you can offer...please e-mail to me...I don't wish
to clutter up the Net too much.

-- 
Mike McCann       (803) 656-3714   Internet = mmccann@hubcap.clemson.edu 
Poole Computer Center (Box P-21)     Bitnet = mmccann@clemson.bitnet
Clemson University
Clemson, S.C. 29634-2803         DISCLAIMER = I speak only for myself.

-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      17 Mar 90 06:26:19 GMT
From:      dsl.pitt.edu!dsl.pitt.edu!sean@PT.CS.CMU.EDU  (Sean McLinden)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: CMOT Implementations
In article <9003170417.AA26725@psi.com> schoff@PSI.COM ("Martin Lee Schoffstall") writes:
>
>Now the question is will SNMP knock out CMIP itself in the area of NMS/agent
>management within the OSI stack.

I sincerely hope not. SNMP is probably adequate for the task of network
management of networks and the full implementation of CMIP is, most likely,
overkill for what are basic network management tasks, but when you start
talking about the management of network objects that represent the
state of the real world (I mean, the computers are there to support
more than their network connections!) is when you see the real power
of a protocol like CMIP.

At the risk of sounding heretical, my personal opinion is that an
implementation of CMOT would make TCP/IP sufficiently robust as to
make it an attractive competitor to OSI (at least until we run
out of addresses). To put this another way, the real appeal of
OSI (and there are a lot of unappealing things about it), is not
the market hype but what is the OSI concept of information as it
exists in communities (an idea retrofitted to TCP/IP with such tools
as XDR, RPC, Threads...). With a generalized interface to what is
network information a la CM{IP,OT} you have a pretty powerful system
which has the advantage of being widely available across multiple
architectures. Until full implementations of the OSI stack
become widely available CMOT would extend the functionality of TCP/IP
as an OSI prototyping tool for, at least, the next few years, allowing
for the applications to be developed in parallel with the network.

Sean McLinden
Decision Systems Laboratory
University of Pittsburgh
-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      Sat, 17 Mar 90 14:57:21 EST
From:      Doug Nelson <08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu>
To:        Jean-Jacques Pansiot Departement d'InformatiqueUniversite Louis, Pasteur Strasbourg FRANCE <pansiot%isis.u-strasbg.fr@CUNYVM.CUNY.EDU>, TCP-IP@SRI-NIC.ARPA
Subject:   Re: broadcast storm
>I know that there is a phenomenon called broadcast storm, and i thing  our
>network has this kind of problem. Here is the situation:
>
>We use a class B network (130.79) over ethernet.
>>From time to time some stations (lets call them type A) send a broadcast,
>with address 130.79.255.255 (I believe this is the correct Broadcast IP
>Address)
>Currently such broadcasts are RWHO  or RIP.
>Some stations (lets call them type B), retransmit the same packet(  as if they
>were IP routers) on the same ethernet, with TTL decreased by one. Moreover,
>they seem to receive their own retransmission, so the whole thing repeats
> itself,
>until TTL is decreased from 15 to 0.
>
>Some stations (lets call them type C), when receiving these packets,
>send an ARP request for IP address
>130.79.255.255. They do not recognize it as a broadcast address. I understand
>that IP broadcast was formerly all 0. But why this ARP ? , as if they
>wanted to route the packet  (as type B stations do ).
>
>Fortunately, only one station (for now) is of type B. Still , for  1
>(correct) broadcast, we have 15 * number of type C stations   packets.
>At the end there is also some ICMP TTL Exceeded and ICMP Destination Unreach.
>Very much for one broadcast. We could try to kill all rwhod, but I don't see
>how to avoid RIP messages from our gateway if we wanto use routed on
>our station?
>
>Anybody to explain the behaviour of stations B and C?
>
>Anything I can do? (Stations B and C
>are mostly SunOS 3.5 , no SUNOS4.0). I do not , of course, have
>the power to do upgrades on these machines, but I could recommend doing
>a few changes (ifconfig....)
>
>any help? may be this is a well known problem?

Yes, this is a well known problem.  The hosts requirements RFCs address
this problem in a couple respects.  First, an end system shouldn't be
trying to redirect a packet.  Second, no system should send a broadcast
in response to an Ethernet broadcast, even if the broadcast IP address is
wrong.

What you want to do is to ask each system administrator to add
"broadcast 130.79.255.255" to their "ifconfig" commands.  You especially
want to have it fixed on the type B stations.

I haven't seen the type of behavior you refer to (type B) in quite a while.
And when I have, it normally involves two or more stations, where each hears
the other's rebroadcast.

One last point:  You should check to make sure there are no IP broadcasts
on a different address (e.g. 130.79.0.0).  Otherwise, you will have the
same problem for those broadcasts when the ifconfig changes are done on
the type B and C stations.  If you do find such broadcasts, be sure to
contact their system administrators as well.

Doug Nelson
Manager of Network Software
Michigan State University
-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      Sat, 17 Mar 90 18:07:24 PST
From:      LiBai!tinker@ames.arc.nasa.gov (Don Tinker)
To:        pansiot%isis.u-strasbg.fr@ames!CUNYVM.CUNY.EDU
Cc:        TCP-IP@SRI-NIC.ARPA
Subject:   broadcast storm

Odd thing, I was about to post a HELP for much the same problem: we
had a Class C net (130.200.14) containing some Suns (Sun4/SunOS4.0.3)
and some VAX- and DEC-stations (I'm not sure what the differences
between the two are); the Suns are on a segment connected to a
repeater connected to a segment where the VAXen are.  Everything was
fine until we added another interface for the Suns (130.200.15), like:

	DEC |				| Sun  |
	DEC |---------Repeater -------  | Sun  |   130.200.15
	DEC |         130.200.14	| Sun  |
	DEC |				| Sun  |

As soon as we make the Suns aware of 130.200.15, and change all the
route masks to 130.200.X.255 (on both DECs and Suns), every 30 seconds
the following happens:

	1.  Some DEC sends what looks like an RWHO packet to
130.200.14.255.
	2.  Every Sun resends the packet to 130.200.14.255.
	3.  Every Sun sends an ICMP redirect message to the DEC
telling it to send packets for 130.200.14.255 to 130.200.14.255!

As you said, TTLs eventually wind down and the storm ends.  My confusion is:

	a) Why are the DECs sending packets to X.X.X.255? Is there
some way to stop this?
	b) Who's responsible for enabling the ICMP redirect?  Is there
any way to tell it to shut up?
	c) With SunOS 4.0.3 the route to X.X.15 is automatically
entered in the route table when ifconfig is run.  Seems to me that if
we could disable the route on the Suns that the Suns would stop
resending these broadcast packets.  Is that right?  Is there some way
to do this (short of not running the routed)?

Any help will be greatly appreciated!


Don Tinker				tinker@ultra.com
Senior Field Support Engineer		{core}!ames!ultra!tinker
UltraNetwork Technologies Inc. 		(703) 821-8393
-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      Sun, 18 Mar 90 10:14:55 -0800
From:      chris@salt.acc.com (Chris VandenBerg)
To:        snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil
Cc:        gary@salt.acc.com
Subject:   YES to MIB repository!
Good morning everyone,
			Last week I sent a message outlining a mechanism to
allow vendors to deposit their MIB's in a central(read anonymous FTP) site
to facilitate interoperability among the NMS community and all the agents
out there. The response has been very positive and I truly thank everyone for
their well-considered comments. It would seem that keeping submissions in
an RFC-1065 conformant format is generally agreed to be essential. Marshall
Rose has magnanimously offered to verify MIB's to ensure this compliance. I
am in the process of working out the logistics of this with him and if anyone
has any comments on how to facilitate this please let me know. I think the
only way this can be kept workable and fairly painless is if we all agree
on how it can most easily be accomplished. I am striving to have mechanism
in place and containing a few MIBs by the time the Interop SNMP demo group
meets in Boston on April 24th. Please feel free to contact me if you have
any ideas or time to contribute to the effort.
		Thanks very much,
				Chris VandenBerg(chris@salt.acc.com)
				805-963-9431
-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 90 04:18:00 GMT
From:      ddk@lanl.gov  (David D Kaas)
To:        tcp-ip@nic.ddn.mil
Subject:   print/batch jobs to MVS


  I am looking for some information on TCP/IP running on MVS.

Are there any implementations of lpr?  If not are there any other
ways of tranferring print/plot files to an MVS machine with TCP/IP from
a UNIX machine?

Are there any programs that allow jobs to be submitted to an MVS machine
over TCP/IP from a UNIX machine?
 
Thanks in advance.

Dave Kaas
Boeing Computer Services Richland
D. O. E. 
Richland, WA 99352
(509) 376-6386
e41126%rlvax3.lanl.gov
ddk@beta.lanl.gov

-- 
Dave Kaas - D.O.E. Richland, Wa.
	e41126%rlvax3.xnet@lanl.gov
-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      18 Mar 90 08:05:33 GMT
From:      sco!wattres!steve@uunet.uu.net  (Steve Watt)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: RARP
In article <9003170021.AA27209@caldwr.water.ca.gov> sjvdp@WATER.CA.GOV (San Joaquin Valley Drainage Program) writes:
>
>	We are integrating a number of PC's onto our building-wide Ethernet.
[ Info about systems and why this is needed ]

>	Any pointers to a RARP server would be greatly appreciated.
>
>-HWM
>
>----------
>Henry W. Miller
>Assistant Systems Manager, Mid Pacific Region

I would suggest using BOOTP instead...  It is much more robust, and can be
used to tell the PC many more interesting things than just its IP address...

In fact, the CMU implementation allows you to specify (per PC)::
Subnet mask, Default gateway, Domain name server, IEN-116 name server,
Time server, Cookie server (fortunes, I think), IMPress server, log server,
lpr server, etc etc etc etc...

If you would like, I could mail you a (slightly fixed) version.  It is also
available via anonymous FTP from lancaster.andrew.cmu.edu (128.2.13.21),
without the bug fixed.  One of these days I'm going to mail back the bug fix.
(Just found it today:  Watch what it passes to report() when the bind fails
or the getsockname fails!)

It has been tested with FTP Software's BOOTP client, and seems to work.

Just a satisfied user.

Oh yeah....  IMPress is probably a copyright of Imagen Corp.
-- 
Steve Watt
...!claris!wattres!steve		wattres!steve@claris.com also works
If you torture your data long enough, it'll eventually confess.
-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Mar 90 08:16:48 -0800
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        sean@dsl.pitt.edu (Sean McLinden)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: CMOT Implementations
Well, I haven't seen the message you have replied to, but I guess I
should speak up.  If, for the moment, we forget the rather tainted
history of CMIP in the Internet, the politics, failures, and so on,
the issue still boils down to one of technical credibility.

If you start comparing OSI application services and protocols (MHS, DS,
FTAM, VT, CMIP), you see that the skill set is all over the board.
Things like message handling and directory, whilst ambitious, work
because they are basically solid protocols well-suited for a particular
domain.  In those two cases, I think the argument of "let's get it fully
implemented and it will work out".  In the case of FTAM and VT, their
scope of focus is simply too large to be workable, e.g., the most charitable
thing I've heard said about FTAM is that "it's both a dessert topping
and a floor wax".  The dessert topping part refers to record access (NFS-like)
features and the floor wax part refers to bulk transfer (FTP-like)
features. 

SNMP works well at network management because it is well-suited towards
the task.  When you need to cast lightning bolts, you conduct it through gold
(SNMP) not paper (CMIP).  This is akin to saying that SNMP is a network
management protocol, and *perhaps* CMIP is a system management protocol,
though I have no confidence in the latter portion since all the CMIP
proponents I cross swords with keep talking about doing both, so they
have fallen into the dessert topping/floor wax trap.  As you might
guess, anything that can be used as a floor wax probably doesn't taste
too good, and anything that can be used as a dessert topping probably
doesn't clean too well.  But, that's CMIP for you.

/mtr
-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Mar 90 08:21:33 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   CCR Bibliography and SIGCOMM '90 Dates

For those people interested in an electronic copy of the SIGCOMM bibliography
on computer communication, the bibliography included in the April issue of
Computer Communication Review is now on-line on NNSC.NSF.NET in
~ftp/CCR/apr90/apr90.refer.  Note: The postscript source for the articles
in the issue (where available) will not go on-line until sometime after
the April issue hits the streets.

Also, yet again, let me remind folks that there is an error in IEEE Computer
and Communications of the ACM, and that SIGCOMM '90 is being held September
24-27, NOT the August dates shown in the magazines.  The erroneous entries
should be cleared out by May.  My apologies for the nuisance.

Craig
-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 90 01:46:44 GMT
From:      uvaarpa!murdoch!bimbo!boyter@mcnc.org  (Maj Brian Boyter)
To:        tcp-ip@nic.ddn.mil
Subject:   DDN Link for SunOS

Is there anyone out there in net-land who has attached a
sun workstation to a PSN (IMP) using Sun's DDN-Link
product???  (especially someone in the Wash DC area)

Would you be available to field a few questions or
offer some suggestions????

Thanks in advance....
Brian Boyter


-- 
---------------------------------------------------------------
   Maj. Brian A Boyter
   US Army Foreign Science & Technology Center
   Charlottesville, Va 22901                         __
   off: (804)980-7362                              (    )
   home:     973-9440                             {      }
   FAX:      973-9047                              (    )
   boyter%bimbo.uucp@virginia.acc.virginia.edu       ||
                                                     ||
   Noriega Who??? Ortega Who???  Libya Next.._______<  >_______
-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Mar 90 08:13:47 EST
From:      "Louis A. Mamakos" <louie@sayshell.umd.edu>
To:        "Bill Rubin" <RUBINM%YKTVMV.BITNET@cunyvm.cuny.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: IBM MVS TCP/IP problems (host file record length too long)
It seems to me that the correct way to solve this problem with long lines
in the host table is to just get rid of the host table and use the 
domain name system instead.

louie
-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 90 04:20:18 GMT
From:      dan@kfw.COM (Dan Mick)
To:        comp.protocols.tcp-ip,comp.sources.wanted,alt.sources.wanted
Subject:   TCP sources

Some of you may remember I was asking about TCP/IP sources recently (in
particular 4.2BSD sources) to splice into SunOS 3.2.

I've since heard from several folks that the 4.2BSD TCP stuff is probably
not much better than the Sun stuff, if at all; while it'd still be nicer
to have sources to modify, I guess I have to agree.

However:  Some kind soul sent me mail about the prospect of getting some
sort of in-progress kit of 4.3 TCP sources; perhaps something generated
by Van Jacobsen et. al. in the process of doing the protocol rewrite.  In
any event, this person described it as "designed to fit into SunOS 3.0-5;
in fact, I've used it in just that way" or words to that effect.

I immediately replied "Yes, yes, send them, please!" and then foolishly
deleted the mail message.

Well, the sources never arrived, so this is a public plea to the original
offeror...please repeat your offer!  I'm still desperate for this source..

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Mar 90 10:41:58 CST
From:      MAINT@ASNTSU.asn.net
To:        tcp-ip@sri-nic.arpa
Does anyone know if there is a Post Office Protocol (POP) Server available
for VMS running Wollengong TCP/IP and if so where I might find it? Please
respond directly to me as I am not a subscriber to this list. Thanks in
advance.

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

       +---------------------+
       |UNA           A&M    |
       |NFDC-------C--UAH    |
       |          / \        |
       |          | |     JSU|
       |   _____UAB-+----/   |
       | UA         |        |
       |            | ____AU |
       |          DSMD       |
       |        ASU | \      |
       |           /  TSU    |
       |         /           |
       |       /             |
       |     /               |
       |  _USA---------------+
       |/  \_|
-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Mar 90 10:14:40 EST
From:      "Bill Rubin" <RUBINM%YKTVMV.BITNET@CUNYVM.CUNY.EDU>
To:        louie@sayshell.umd.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: IBM MVS TCP/IP problems (host file record length too long)
"Louis A. Mamakos" <louie@sayshell.umd.edu> writes:

> It seems to me that the correct way to solve this problem with long lines
> in the host table is to just get rid of the host table and use the
> domain name system instead.
>
> louie

Absolutely!  And we do provide a name server with our MVS product.  But
we still support host tables for backup (except SMTP) and because some
people still prefer to use them.

Bill Rubin
IBM TJ Watson Research
-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 90 12:30:00 MST
From:      "2645 Pierson, Lyndon G." <lgpiers@sandia.gov>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   RFC 1072 Implementations Needed
RFC 1072 represents a significant improvement in the performance 
of TCP in communication environments with high delay-bandwidth product
(geosynchronous satellite links at T1 and above) and moderate error rates.

Does anyone know of a full implementation of TCP which incorporates
the RFC 1072 window scaling, selective acknowledgements, and rtt
estimator?  (or even a planned implementation?)

L. G. Pierson (505)-845-8212,  LGPIERS@SANDIA.GOV


-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Mar 90 15:48:04 PST
From:      christopher raczka <raczka@gldoa.enet.dec.com>
To:        "tcp-ip@nic.ddn.mil"@11221.enet.dec.com
Subject:   RE: Where are RFCs??

    There are a couple places... but the BEST service comes from
    sending your request via mail to service@nic.ddn.mil

chris

--
christopher raczka
raczka@gldoa.enet.dec.com
-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 90 13:21:33 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   CCR Bibliography and SIGCOMM '90 Dates


For those people interested in an electronic copy of the SIGCOMM bibliography
on computer communication, the bibliography included in the April issue of
Computer Communication Review is now on-line on NNSC.NSF.NET in
~ftp/CCR/apr90/apr90.refer.  Note: The postscript source for the articles
in the issue (where available) will not go on-line until sometime after
the April issue hits the streets.

Also, yet again, let me remind folks that there is an error in IEEE Computer
and Communications of the ACM, and that SIGCOMM '90 is being held September
24-27, NOT the August dates shown in the magazines.  The erroneous entries
should be cleared out by May.  My apologies for the nuisance.

Craig

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Mar 90  19:44:34 EST
From:      "Roger Fajman" <RAF@CU.NIH.GOV>
To:        FILLMORE%EMRCAN.BITNET@CU.NIH.GOV
Cc:        tcp-ip@SRI-NIC.ARPA.NIC.DDN.MIL
Subject:   Re:  NJE-over-TCP (Bitnet II) software for Sun?
> The subject line pretty well sums it up:  is anyone aware of a product
> or product under development which implements the NJE protocols used by
> Bitnet over TCP/IP, running under the SunOS environment?

There's an enhancement to UREP.  Contact Scott Bradner,
sob@harvunxw.harvard.edu for more information.

I've also heard of an Israeli product, but don't have the
contact handy.

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 90 15:14:40 GMT
From:      RUBINM@YKTVMV.BITNET ("Bill Rubin")
To:        comp.protocols.tcp-ip
Subject:   Re: IBM MVS TCP/IP problems (host file record length too long)

"Louis A. Mamakos" <louie@sayshell.umd.edu> writes:

> It seems to me that the correct way to solve this problem with long lines
> in the host table is to just get rid of the host table and use the
> domain name system instead.
>
> louie

Absolutely!  And we do provide a name server with our MVS product.  But
we still support host tables for backup (except SMTP) and because some
people still prefer to use them.

Bill Rubin
IBM TJ Watson Research

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      Mon, 19 Mar 90 20:50:00 EST
From:      Haggar (H.) Alsaleh <HAGGAR@BNR.CA>
To:        tcp-ip@NIC.DDN.MIL
Subject:   re:Where are RFCs??
Jian,
RFCs can be received through e-mail from
(service@nic.ddn.mil).
For full instruction, type HELP on the subject line.

Haggar Alsaleh            Haggar@bnr.ca
Network Engineer          214 997-4806.
1150 E. Arapaho Rd.
Richardson TX 75081.
USA.

P.S I'm a free man, I speak for my self and no body else.
-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 90 16:40:52 GMT
From:      nisca.ircc.ohio-state.edu!hpuxa.ircc.ohio-state.edu!bobd@tut.cis.ohio-state.edu  (Bob Debula)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Where are RFCs??
They are also available from "nisca.ircc.ohio-state.edu"
in "pub/rfc".

==========================================================================
Bob DeBula                    | Internet:   bobd@hpuxa.ircc.ohio-state.edu
The Ohio State University     | Disclaimer: These are my views, not the U's
Davros sez:   When my Daleks compute they use X-TER-MI-NALS!
-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 90 16:41:58 GMT
From:      MAINT@ASNTSU.ASN.NET
To:        comp.protocols.tcp-ip
Subject:   (none)

Does anyone know if there is a Post Office Protocol (POP) Server available
for VMS running Wollengong TCP/IP and if so where I might find it? Please
respond directly to me as I am not a subscriber to this list. Thanks in
advance.

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

       +---------------------+
       |UNA           A&M    |
       |NFDC-------C--UAH    |
       |          / \        |
       |          | |     JSU|
       |   _____UAB-+----/   |
       | UA         |        |
       |            | ____AU |
       |          DSMD       |
       |        ASU | \      |
       |           /  TSU    |
       |         /           |
       |       /             |
       |     /               |
       |  _USA---------------+
       |/  \_|

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 90 17:57:09 GMT
From:      auspex!ntrlink!walt@uunet.uu.net  (Walter Johnson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: print/batch jobs to MVS
In article <46207@lanl.gov> ddk@lanl.gov (David D Kaas) writes:
>
>  I am looking for some information on TCP/IP running on MVS.
>
>Are there any implementations of lpr?  

Yes.  ACCES/MVS from ACC includes a print server for the UNIX lpr
command.

>Are there any programs that allow jobs to be submitted to an MVS machine
>over TCP/IP from a UNIX machine?

ACCES/MVS supports an ftp server that allows data transfers to MVS to be 
submitted as a batch job to MVS via the JES Internal Reader facility.

For more information, contact ACC (try (301)290-8100).
-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 90 17:59:00 GMT
From:      logicon.com!Makey@nosc.mil  (Jeff Makey)
To:        tcp-ip@nic.ddn.mil
Subject:   Internet break-in in the news
I saw a brief blurb on CNN's Headline News last night (18 March 1990)
about some hacker(s) [sic] stealing files from Internet sites.  Does
anyone know any details?

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: Logicon doesn't even know we're running news.
    Internet: Makey@Logicon.COM    UUCP: {nosc,ucsd}!logicon.com!Makey
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 90 19:30:00 GMT
From:      lgpiers@SANDIA.GOV ("2645 Pierson, Lyndon G.")
To:        comp.protocols.tcp-ip
Subject:   RFC 1072 Implementations Needed

RFC 1072 represents a significant improvement in the performance 
of TCP in communication environments with high delay-bandwidth product
(geosynchronous satellite links at T1 and above) and moderate error rates.

Does anyone know of a full implementation of TCP which incorporates
the RFC 1072 window scaling, selective acknowledgements, and rtt
estimator?  (or even a planned implementation?)

L. G. Pierson (505)-845-8212,  LGPIERS@SANDIA.GOV

-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      19 Mar 90 20:16:59 GMT
From:      ncrlnk!ncrcce!mercer@uunet.uu.net  (Dan Mercer)
To:        tcp-ip@nic.ddn.mil
Subject:   what does and ICMP redirect message mean
We have a TCP-IP LAN with a WellFleet Router gating to a second LAN
with a single PC on it (running WIN/TCP-IP).  The main LAN is
comprised mostly of SUNs.  One of the SUNs acts as a router.  Our
WellFleet router is receiving a message from the SUN router,
an ICMP-redirect,  every 30 secs.  Unfortunately,  I cannot find
out what the message means or what I need to do to make it stop.
Please don't ask me to RTFM.  What manuals I have access to
either don't mention the redirect message at all or do not
indicate what the problem really is or how to correct it.

-- 

Dan Mercer
Reply-To: mercer@ncrcce.StPaul.NCR.COM (Dan Mercer)
-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 90 00:18:49 GMT
From:      logicon.com!Makey@nosc.mil  (Jeff Makey)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Internet break-in in the news
For Usenet sites, article <9003192042.AA07699@cert.sei.cmu.edu> in
comp.security.announce goes into detail, but apparently this is
nothing more than "several persistent attempts on systems using known
security vulnerabilities."  TCP-IP readers without Usenet access can
retrieve CERT Advisory 90:02 via anonymous FTP from cert.sei.cmu.edu
(128.237.253.5) or can request it by mail from cert@cert.sei.cmu.edu.

Thanks also to Brian Kantor and J. Paul Holbrook for mailing the
article to me, and to Karl Kleinpaste for his own view of the
situation.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: Logicon doesn't even know we're running news.
    Internet: Makey@Logicon.COM    UUCP: {nosc,ucsd}!logicon.com!Makey
-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 90 00:36:02 GMT
From:      phoenix!cucumber!viktor@princeton.edu  (Viktor Dukhovni)
To:        tcp-ip@nic.ddn.mil
Subject:   Subnetted subnets implemented!

	A while I go I sent a query to this list asking for comments
on the feasibility of further subnetting subnets in 4.3BSD like systems,
and proposed a hypothetical algorithm for doing this.

	I got just two responses both were of the "let me know what
you find variety".  I have finally had time to try this out,  and found
a small deficiency in the original scheme,  and a clean solution.
I am sending this message from a happy sub-subnetted network. The main
point was to realize that there are two parameters determining the
interpretation of an interface address:  the first is the subnetmask,
which defines the granularity of the subnet,  and the second is the netmask(!)
which defines the size of the network attached to the interface.  

	When subnetting Class B networks,  this information is gratis,
the Class B net has 256^2 addresses.  What really makes sub-subnetting
possible is a mechanism for specifying the kernel netmask of an interface.
We can also dispense with the SUBNETSARELOCAL hack,  as one can now
fine tune the local network size by changing the netmask.
(There is some confusion on this point since what is a subnetmask
to the kernel is a "netmask" to ifconfig,  so I will use the kernel notation.)

Having added two new SIOC ioctls to define the interface "netmask"
(I had to call them SIOC?IFCLASSMASK,  since NETMASK was already (ab)used :-( )
There were only a few trivial mods to netinet/in.c to get the whole show on
the road.  I also have an ifconfig.c that sets and reports the new parameter.

	I think this code can prove useful for adding slip subnets behind
serial line concentrators on departmental without changing the outside
world to treat these as separate subnets.

	If there is enough interest I will make it available via anonymous
ftp,  please let me know if you want use use this code or have done something
similar.

	What remains to be done is a version of routed or gated that
undestands the new netmask parameter and correctly recognizes host vs.
network routes.   I am looking at gated-1.9.1.7 as a base,  but I seem
to have problems with even on "standard" 4.0.3 suns,  it readvertises
all routes back to the source net,  and acquires some bogus ones,  I am
having better luck with Suns in.routed.

-- 
	Viktor Dukhovni <viktor@math.princeton.edu>	: ARPA
		<...!uunet!princeton!math!viktor>	: UUCP
	Fine Hall, Washington Rd., Princeton, NJ 08544  : US-Post
		+1-(609)-258-5792		 	: VOICE
-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Mar 90 08:43:20 PST
From:      tkostan@trwind.trw.com (Tyson Kostan)
To:        logicon.com!Makey@nosc.mil, tcp-ip@nic.ddn.mil
Subject:   Re:  Internet break-in in the news
We here at TRW had a major break-in a few weeks ago.  The "bit-thief" as we 
call him (or her?) was arrogant, and thurough.  One of our employees cought
him on one of our systems, and the bit-thief ignored warnings, TFTP'd many
files (including password files, etc) and cleaned up on his way out.  

For mor info, contact bullard@trwind.ind.TRW.COM.

Since the break-in, we have severely restricted internet access to our networks.
The problem would not have happened if employees followed password procedures
which should be followed in any UNIX shop.  

I believe that we have notified the FBI, because several files that were
removed are licensed source code from third parties.  

Be careful out there!!!
-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Mar 90 09:14:03 PST
From:      postel@venera.isi.edu
To:        logicon.com!Makey@nosc.mil
Cc:        tcp-ip@nic.ddn.mil
Subject:   Internet break-in in the news

Jeff Makey:

See the NY Times article of Monday 3/19/90 by John Markoff.

Also change your password.

--jon.
-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Mar 90 10:00:40 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   SIGCOMM Network Simulation Column

Hi folks:

    I wanted to let you know that SIGCOMM Computer Communication Review
has added a column on network simulation.  Lixia Zhang is our new
simulations editor.

    Lixia's announcement of the new column is below.  People interested
in submitting simulation papers should contact Lixia.

Craig



	      Announcing the Network Simulation Column


	 Because it is not always feasible, or even possible, to
    conduct  experiments  or performance evaluation in real net-
    works, the role of simulation  is  becoming  more  and  more
    important  in network protocol design, analysis, and perfor-
    mance evaluation.  In recent  years  substantial  simulation
    efforts have been conducted.  However, little of the results
    has been published.  In most cases  the  results  were  only
    shared  among  a  few colleagues, occasionally propagated by
    mouth or email to a few other interested parties.   We  have
    increasingly  felt  the need for a place to provide a timely
    exchange of the results among experimenters,  analysts,  and
    network practitioners.

	 Thanks to the  Computer  Communication  Review  editor,
    Craig  Partridge, for providing the precious space in CCR to
    meet this need, a special column on  Network  Simulation  is
    now  opened on CCR and publications will start from the next
    issue of CCR, July 1990.

	 The purpose of this column is to provide a timely  dis-
    semination of simulation experimental results and to provide
    a forum for comment and debate among  the  network  research
    community.   The  publications  are  expected to be informal
    exchanges about  current  efforts,  therefore  we  emphasize
    timeliness over formality.

	 The column encourages  submissions  on  topics  ranging
    from  studies  of existing networks and protocols to perfor-
    mance evaluation of proposed new protocols, congestion  con-
    trol and routing algorithms.  The emphasis will be primarily
    on those reporting practical experience gained from  simula-
    tion  experiments  and  work-in-progress.   Submissions of a
    more mathematical or theoretical nature that may  contribute
    to  better  understanding of the simulation results are also
    welcome.   Discussions on simulation  methodology,  however,
    will not be our primary concern.

	 Submissions may range  in  length  from  a  short  note
    (perhaps  half a page) to no more than 5 pages.  Manuscripts
    should be sent to me at XEROX PARC, 3333 Coyote  Hill  Road,
    Palo  Alto,  CA  94304.   Authors  may also submit documents
    electronically to lixia@parc.xerox.com, following  the  same
    requirements  as  specified  in  the  CCR  ``Information for
    Authors.''

	 I am looking forward to serving you as the  editor  for
    this  new  Network  Simulation  Column.   The success of the
    column will depend on your contributions.

    Lixia Zhang
-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Mar 90 13:35:46 est
From:      rhott@relay.nswc.navy.mil
To:        tcp-ip@nic.ddn.mil
Cc:        rhott@relay.nswc.navy.mil, tdrake@relay.nswc.navy.mil, vbarnes@relay.nswc.navy.mil
Subject:   Routing problems
We are having problems reaching various locations on the Internet.
We use a Cisco gateway (running EGP).  When we try to get to host
ornl.gov (for example), no go!  I ran a traceroute and the following
are the results:
$ traceroute 128.219.128.17
traceroute to 128.219.128.17 (128.219.128.17), 30 hops max, 38 byte packets
 1  cisco1 (128.38.48.15)  80 ms  20 ms  20 ms
 2  26.20.0.17 (26.20.0.17)  240 ms  200 ms  260 ms
 3  * 26.6.0.103 (26.6.0.103)  700 ms  900 ms
 4  * * 26.21.0.104 (26.21.0.104)  1640 ms
 5  26.6.0.103 (26.6.0.103)  2320 ms 26.20.0.17 (26.20.0.17)  800 ms *
 6  26.6.0.103 (26.6.0.103)  2120 ms 26.20.0.17 (26.20.0.17)  1460 ms 26.21.0.104 (26.21.0.104)  2140 ms
 7  26.21.0.104 (26.21.0.104)  2060 ms  2060 ms  1720 ms
 8  26.20.0.17 (26.20.0.17)  1540 ms  1520 ms  2440 ms
 9  arpanet^3.0.5 (10.3.0.5)  1840 ms  1240 ms  2080 ms
10  26.21.0.104 (26.21.0.104)  1380 ms  1900 ms  1460 ms
11  26.20.0.17 (26.20.0.17)  2020 ms  2420 ms  3720 ms
12  * arpanet^3.0.5 (10.3.0.5)  1960 ms *
13  * * arpanet^3.0.5 (10.3.0.5)  3880 ms
14  * arpanet^3.0.111 (10.3.0.111)  6760 ms  2700 ms
15  * arpanet^3.0.5 (10.3.0.5)  2520 ms  4140 ms
16  * arpanet^3.0.111 (10.3.0.111)  5780 ms  2580 ms
17  arpanet^3.0.5 (10.3.0.5)  2320 ms arpanet^6.0.20 (10.6.0.20)  1320 ms !N  1000 ms !N


  It looks to me as though there are some routing problems on the Internet??

On one of our "Milnet only" hosts, it has a route (I guess from the invocation
of routed) for 128.219 via 26.16.0.162, and all works fine!

Any guidance would be appreciated!

Bob Hott
NSWC
Networks Branch
Dahlgren, VA 22448
(703) 663-7745

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Mar 90 13:48:42 EST
From:      Tony D'Amato <NAD100T@ODUVM.CC.ODU.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Internet break-in in the news
On Mon, 19 Mar 90 17:59:00 GMT Jeff Makey said:
>I saw a brief blurb on CNN's Headline News last night (18 March 1990)
>about some hacker(s) [sic] stealing files from Internet sites. ...
            ======  <<== arg!

Am I the only one left from the "old type" hacker school, when the
term "hacker" only meant someone who liked to play with and inside
computers, not "computer criminal!"

I guess I'm just angry at the media taking the term }hacker" and using it
in a derogatory manner.

Pardon the flame, but...isn't there any of us left ?

Thanks for letting me air my gripe...

|========================================================================|
| Tony D'Amato                     |                                     |
| Computer Systems Engineer        | "Deesclaimer! I don't neeed no      |
| Old Dominion University          |  steenkin' deesclaimer!"            |
| E-Mail: NAD100T@ODUVM.BITNET     |                                     |
| -or-    nad100t@oduvm.cc.odu.edu |   -- with apologies to Mel Brooks   |
|========================================================================|
-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Mar 90 14:42:19 EST
From:      doc Urbaniak <urbaniak@BBN.COM>
To:        sun-nets@umiacs.umd.edu, tcp-ip@nic.ddn.mil
Cc:        urbaniak@BBN.COM
Subject:   SunLink/DDN and Class B IP over X.25
If you are aware of a version of SunLink/DDN which can operate
with Class B IP addresses on an X.25 network, please contact me
directly (urbaniak@bbn.com).

We need a version of SunLink/DDN which maps Class B IP addresses to X.25
addresses as net.net.hostport.psn, as well as (or even as opposed to)
mapping Class A IP addresses as net.hostport.0.psn.

We do not currently own sources to SunLink/DDN (either 5.0 or 6.0).
If you can provide SunLink/DDN object files (either 5.0
or 6.0 or both) enhanced for Class B operation, this would help us.
If only the affected object file were available, that would help.
If we could receive only the affected source file (x25manager?),
that would help.

If a patch were available, that would help, even if that patch replaced
Class A mapping with Class B mapping (as opposed to dispatching by case).
If you have sources and would be interested in working together toward
adding this feature, that would help.
If you know someone or some organization which has sources to SunLink/DDN,
please let me know.

Thanks for your time and consideration.

Walter "doc" Urbaniak.
BBN Corporate Telecommunications.

Please reply directly:

urbaniak@bbn.com (617)873-3671

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      Tue, 20 Mar 90 18:21:36 PST
From:      adelman@TGV.COM (Kenneth Adelman)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Terminate session negotiation??
> Thanks to responses to my first questions to this group, i now have a
> client/server application that "talks" over the telnet virtual
> terminal. Whats especially nice is that it supports code that has
> already shipped to our users (the code thinks its talking at a RS232
> style connection)

> I have noticed that the behaviour of the server (remote) process varies
> from telnet to telnet, when the client (local) dies or otherwise drops
> the connection.

> KNET and IBM for VM systems leave the CMS session "disconected", as does
> apollo AEGIS. So far, i havent found a way to reconnect to the apollo one :-)

> VMS(wollongong) effectively kill the process and "logoff" the user. As do
> some unixen, and MVS.

    MultiNet fakes the VMS terminal driver into thinking that a modem
hangup has occurred when the connection is closed or an error occurs
on it; I would venture to guess that most other VMS TCP/IP
implementations do the same.  It is up to the VMS application to catch
this signal and logoff; this is usually done by DCL on behalf of the
users' application.  If VMS is configured with virtual terminals
(VTAs) then the physical terminal (NTY) is disconnected from the
virtual terminal and the connection logged out without a hangup being
delivered to the application.

> My application would prefer the remote session to "logoff" if the connection
> is severed. Is this something that the remote session has to do for itself
> once it realises the connection is gone, or can it be negotiated from the
> source side? -- my remote side is already in the field, so changing it aint
> as easy as adding to the source side.

    Under VMS just don't do anything special to try to trap the hangup
signal from being processed by DCL.

							Kenneth Adelman
							TGV, Inc.
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 90 15:00:40 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM Network Simulation Column


Hi folks:

    I wanted to let you know that SIGCOMM Computer Communication Review
has added a column on network simulation.  Lixia Zhang is our new
simulations editor.

    Lixia's announcement of the new column is below.  People interested
in submitting simulation papers should contact Lixia.

Craig



	      Announcing the Network Simulation Column


	 Because it is not always feasible, or even possible, to
    conduct  experiments  or performance evaluation in real net-
    works, the role of simulation  is  becoming  more  and  more
    important  in network protocol design, analysis, and perfor-
    mance evaluation.  In recent  years  substantial  simulation
    efforts have been conducted.  However, little of the results
    has been published.  In most cases  the  results  were  only
    shared  among  a  few colleagues, occasionally propagated by
    mouth or email to a few other interested parties.   We  have
    increasingly  felt  the need for a place to provide a timely
    exchange of the results among experimenters,  analysts,  and
    network practitioners.

	 Thanks to the  Computer  Communication  Review  editor,
    Craig  Partridge, for providing the precious space in CCR to
    meet this need, a special column on  Network  Simulation  is
    now  opened on CCR and publications will start from the next
    issue of CCR, July 1990.

	 The purpose of this column is to provide a timely  dis-
    semination of simulation experimental results and to provide
    a forum for comment and debate among  the  network  research
    community.   The  publications  are  expected to be informal
    exchanges about  current  efforts,  therefore  we  emphasize
    timeliness over formality.

	 The column encourages  submissions  on  topics  ranging
    from  studies  of existing networks and protocols to perfor-
    mance evaluation of proposed new protocols, congestion  con-
    trol and routing algorithms.  The emphasis will be primarily
    on those reporting practical experience gained from  simula-
    tion  experiments  and  work-in-progress.   Submissions of a
    more mathematical or theoretical nature that may  contribute
    to  better  understanding of the simulation results are also
    welcome.   Discussions on simulation  methodology,  however,
    will not be our primary concern.

	 Submissions may range  in  length  from  a  short  note
    (perhaps  half a page) to no more than 5 pages.  Manuscripts
    should be sent to me at XEROX PARC, 3333 Coyote  Hill  Road,
    Palo  Alto,  CA  94304.   Authors  may also submit documents
    electronically to lixia@parc.xerox.com, following  the  same
    requirements  as  specified  in  the  CCR  ``Information for
    Authors.''

	 I am looking forward to serving you as the  editor  for
    this  new  Network  Simulation  Column.   The success of the
    column will depend on your contributions.

    Lixia Zhang

-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 90 15:13:57 GMT
From:      fltk!dnb@uunet.uu.net  (David Buonomo)
To:        tcp-ip@nic.ddn.mil
Subject:   Request for copy of "Introduction to the Internet Protocols"
Does anyone have a copy of "Introduction to the Internet Protocols" by
Charles L. Hedrick of Rutgers?  My hardcopy has every other page missing
and I cannot locate the original.  Thanks in advance.

David Buonomo
...!uunet!fltk!dnb
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 90 15:53:53 GMT
From:      cica!sol.ctr.columbia.edu!emory!hubcap!ncrcae!ncrlnk!ncrwic!sfc!chas@tut.cis.ohio-state.edu  (Charles Binford)
To:        tcp-ip@nic.ddn.mil
Subject:   Help w/internet address & subnets

We are trying to figure out how to setup our internet address with
the proper subnets.  If you are will to give some hints and advice 
please send email and I'll send the specifics of our situation.

Thanks, Charles.Binford@Wichita.NCR.COM
-- 
Charles Binford, Automation Engineering, NCR PPD Wichita
    <C.Binford@Wichita.NCR.COM>
    <uunet!ncrlnk!ncrwic!c.binford>
-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 90 17:41:27 GMT
From:      manta!psm@nosc.mil  (Scot Mcintosh)
To:        tcp-ip@nic.ddn.mil
Subject:   RDP implementation
Anyone know of an FTP site where I can get a copy of
an implementation of the Reliable Datagram Protocol
(or anything functionally similar)?
I posted a query on the comp.sources.wanted, but no
response.

-- 
----
Scot McIntosh
Internet: psm@helios.nosc.mil
UUCP:     {ihnp4,akgua,decvax,decwest,ucbvax}!sdscvax!nosc!psm
-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 90 18:20:32 GMT
From:      psuvm!pmw1@psuvax1.cs.psu.edu  (Peter Weiss)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Request for copy of "Introduction to the Internet Protocols"
Anonymous FTP topaz.rutgers.edu
          get pub/tcp-ip-docs/tcp-ip.intro.doc  local.name


local.name is your local file to be created.
--
Peter M. Weiss                   |  (this line intentionally left blank)
31 Shields Bldg (the AIS people) | advertize here, reach Mega populi
University Park, PA USA 16802    | Disclaimer :1 * applies herein
-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 90 18:27:36 GMT
From:      psuvm!pmw1@psuvax1.cs.psu.edu  (Peter Weiss)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Request for copy of "Introduction to the Internet Protocols"
Anonymous FTP topaz.rutgers.edu
          get pub/tcp-ip-docs/tcp-ip-intro.doc  local.name


local.name is your local file to be created.
--
Peter M. Weiss                   |  (this line intentionally left blank)
31 Shields Bldg (the AIS people) | advertize here, reach Mega populi
University Park, PA USA 16802    | Disclaimer :1 * applies herein
-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 90 18:35:46 GMT
From:      rhott@RELAY.NSWC.NAVY.MIL
To:        comp.protocols.tcp-ip
Subject:   Routing problems

We are having problems reaching various locations on the Internet.
We use a Cisco gateway (running EGP).  When we try to get to host
ornl.gov (for example), no go!  I ran a traceroute and the following
are the results:
$ traceroute 128.219.128.17
traceroute to 128.219.128.17 (128.219.128.17), 30 hops max, 38 byte packets
 1  cisco1 (128.38.48.15)  80 ms  20 ms  20 ms
 2  26.20.0.17 (26.20.0.17)  240 ms  200 ms  260 ms
 3  * 26.6.0.103 (26.6.0.103)  700 ms  900 ms
 4  * * 26.21.0.104 (26.21.0.104)  1640 ms
 5  26.6.0.103 (26.6.0.103)  2320 ms 26.20.0.17 (26.20.0.17)  800 ms *
 6  26.6.0.103 (26.6.0.103)  2120 ms 26.20.0.17 (26.20.0.17)  1460 ms 26.21.0.104 (26.21.0.104)  2140 ms
 7  26.21.0.104 (26.21.0.104)  2060 ms  2060 ms  1720 ms
 8  26.20.0.17 (26.20.0.17)  1540 ms  1520 ms  2440 ms
 9  arpanet^3.0.5 (10.3.0.5)  1840 ms  1240 ms  2080 ms
10  26.21.0.104 (26.21.0.104)  1380 ms  1900 ms  1460 ms
11  26.20.0.17 (26.20.0.17)  2020 ms  2420 ms  3720 ms
12  * arpanet^3.0.5 (10.3.0.5)  1960 ms *
13  * * arpanet^3.0.5 (10.3.0.5)  3880 ms
14  * arpanet^3.0.111 (10.3.0.111)  6760 ms  2700 ms
15  * arpanet^3.0.5 (10.3.0.5)  2520 ms  4140 ms
16  * arpanet^3.0.111 (10.3.0.111)  5780 ms  2580 ms
17  arpanet^3.0.5 (10.3.0.5)  2320 ms arpanet^6.0.20 (10.6.0.20)  1320 ms !N  1000 ms !N


  It looks to me as though there are some routing problems on the Internet??

On one of our "Milnet only" hosts, it has a route (I guess from the invocation
of routed) for 128.219 via 26.16.0.162, and all works fine!

Any guidance would be appreciated!

Bob Hott
NSWC
Networks Branch
Dahlgren, VA 22448
(703) 663-7745

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 90 18:48:42 GMT
From:      NAD100T@ODUVM.CC.ODU.EDU (Tony D'Amato)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet break-in in the news

On Mon, 19 Mar 90 17:59:00 GMT Jeff Makey said:
>I saw a brief blurb on CNN's Headline News last night (18 March 1990)
>about some hacker(s) [sic] stealing files from Internet sites. ...
            ======  <<== arg!

Am I the only one left from the "old type" hacker school, when the
term "hacker" only meant someone who liked to play with and inside
computers, not "computer criminal!"

I guess I'm just angry at the media taking the term }hacker" and using it
in a derogatory manner.

Pardon the flame, but...isn't there any of us left ?

Thanks for letting me air my gripe...

|========================================================================|
| Tony D'Amato                     |                                     |
| Computer Systems Engineer        | "Deesclaimer! I don't neeed no      |
| Old Dominion University          |  steenkin' deesclaimer!"            |
| E-Mail: NAD100T@ODUVM.BITNET     |                                     |
| -or-    nad100t@oduvm.cc.odu.edu |   -- with apologies to Mel Brooks   |
|========================================================================|

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 90 19:42:19 GMT
From:      urbaniak@BBN.COM (doc Urbaniak)
To:        comp.protocols.tcp-ip
Subject:   SunLink/DDN and Class B IP over X.25

If you are aware of a version of SunLink/DDN which can operate
with Class B IP addresses on an X.25 network, please contact me
directly (urbaniak@bbn.com).

We need a version of SunLink/DDN which maps Class B IP addresses to X.25
addresses as net.net.hostport.psn, as well as (or even as opposed to)
mapping Class A IP addresses as net.hostport.0.psn.

We do not currently own sources to SunLink/DDN (either 5.0 or 6.0).
If you can provide SunLink/DDN object files (either 5.0
or 6.0 or both) enhanced for Class B operation, this would help us.
If only the affected object file were available, that would help.
If we could receive only the affected source file (x25manager?),
that would help.

If a patch were available, that would help, even if that patch replaced
Class A mapping with Class B mapping (as opposed to dispatching by case).
If you have sources and would be interested in working together toward
adding this feature, that would help.
If you know someone or some organization which has sources to SunLink/DDN,
please let me know.

Thanks for your time and consideration.

Walter "doc" Urbaniak.
BBN Corporate Telecommunications.

Please reply directly:

urbaniak@bbn.com (617)873-3671

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 90 20:46:45 GMT
From:      daemon@iuvax.cs.indiana.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Using 3Com 503 Boards
Have any of you out there had any experience using 3Com 503 boards on 
PS/2 Model 25's?  I've been trying to run NCSA Telnet on them for
quite some time (with the Clarkson packet drivers v5 and 5A), and I've
tried just about every IO Address and Shared Memory Address and Interrupt
possible.  I seem to get a lockup every single time. (on different 
machines, on different branches of the Network, on both TP Ethernet and
Thin Ethernet).  

Any ideas? 

Thanks in advance!

Geoffrey McKim
University Computing Services
Indiana University

mckimg@ucs.indiana.edu (Internet)
mckimg@IUBACS (BITNET)
-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      20 Mar 90 23:01:26 GMT
From:      silver!hughes@iuvax.cs.indiana.edu  (larry hughes)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: print/batch jobs to MVS
In article <2897@ntrlink.UUCP> walt@ntrlink.UUCP (Walter Johnson) writes:
>In article <46207@lanl.gov> ddk@lanl.gov (David D Kaas) writes:
>>
>>  I am looking for some information on TCP/IP running on MVS.
>>
>>Are there any implementations of lpr?  
>
>Yes.  ACCES/MVS from ACC includes a print server for the UNIX lpr
>command.
>

We too have the ACCES/MVS software, but we find the lpr server
almost unusable because of insufficient ID information on the
resulting banner pages (i.e. each lpr print job appears to be
owned by user "acces/mvs").

Has anybody else gotten lpr to work with better ID information
on banner pages?

 //=========================================================================\\
||       Larry J. Hughes, Jr.        ||        hughes@ucs.indiana.edu        ||
||        Indiana University         ||                                      ||
||   University Computing Services   ||   "The person who knows everything   ||
||    750 N. State Road 46 Bypass    ||      has a lot to learn."            ||
||      Bloomington, IN  47405       ||                                      ||
||         (812) 855-9255            ||   Disclaimer: Same as my quote...    ||
 \\==========================================================================//
-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 90 00:19:37 GMT
From:      logicon.com!Makey@nosc.mil  (Jeff Makey)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Is there a sTaNdArD??/Up against the wall fascist pigs!
In article <9003142059.AA14097@venera.isi.edu> pvm@venera.isi.edu (Paul Mockapetris) writes:
>Preserve the case of data you get.

BIND 4.8 fails to do this.  For example, if I request an A record for
"logicon.com" the answer returned has "logicon.com" in it, even though
the database has it listed as "Logicon.COM".  I actually once found
the piece of code responsible for this behavior, but it did not look
easy to fix.

Followups should probably be directed to the bind@ucbarpa.berkeley.edu
mailing list.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: Logicon doesn't even know we're running news.
    Internet: Makey@Logicon.COM    UUCP: {nosc,ucsd}!logicon.com!Makey
-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Mar 90  07:19:52 EST
From:      "Steve D'Angona" <SOD@CU.NIH.GOV>
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  (larry hughes) Re:  print/batch jobs to MVS
> MAIL VIA INTERNET FROM tcp-ip-RELAY@NIC.DDN.MIL  TUESDAY  03/20/90  11:12:53 P.M.
>
> Received: from CU.NIH.GOV by NIHCU (Mailer) id 6847;
>               Tue, 20 Mar 90  23:12:53 EST
> Received: from NIC.DDN.MIL by CU.NIH.GOV
>     with TCP; Tue, 20 Mar 90 23:12:48 EST
> Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Tue, 20 Mar 90
>  15:15:16 PST
> Received: by ucbvax.Berkeley.EDU (5.61/1.41)
>        id AA08447; Tue, 20 Mar 90 15:05:16 -0800
> Received: from USENET by ucbvax.Berkeley.EDU with netnews
>        for tcp-ip@nic.ddn.mil (tcp-ip@nic.ddn.mil)
>        (contact usenet@ucbvax.Berkeley.EDU if you have questions)
> Date: 20 Mar 90 23:01:26 GMT
> From: silver!hughes@iuvax.cs.indiana.edu  (larry hughes)
> Organization: Indiana University, Bloomington
> Subject: Re: print/batch jobs to MVS
> Message-Id: <39110@iuvax.cs.indiana.edu>
> References: <46207@lanl.gov>, <2897@ntrlink.UUCP>
> Sender: tcp-ip-relay@nic.ddn.mil
> To: tcp-ip@nic.ddn.mil
>
> In article <2897@ntrlink.UUCP> walt@ntrlink.UUCP (Walter Johnson) writes:
> >In article <46207@lanl.gov> ddk@lanl.gov (David D Kaas) writes:
> >>
> >>  I am looking for some information on TCP/IP running on MVS.
> >>
> >>Are there any implementations of lpr?
> >
> >Yes.  ACCES/MVS from ACC includes a print server for the UNIX lpr
> >command.
> >
>
> We too have the ACCES/MVS software, but we find the lpr server
> almost unusable because of insufficient ID information on the
> resulting banner pages (i.e. each lpr print job appears to be
> owned by user "acces/mvs").
>
> Has anybody else gotten lpr to work with better ID information
> on banner pages?
>
>  //=========================================================================\\
> ||       Larry J. Hughes, Jr.        ||        hughes@ucs.indiana.edu        ||
> ||        Indiana University         ||                                      ||
> ||   University Computing Services   ||   "The person who knows everything   ||
> ||    750 N. State Road 46 Bypass    ||      has a lot to learn."            ||
> ||      Bloomington, IN  47405       ||                                      ||
> ||         (812) 855-9255            ||   Disclaimer: Same as my quote...    ||
>  \\==========================================================================//
>
>
>

We use ACCESMVS's lpr interface with the understanding that the
first line of the file sent contain accounting information in a
predefined way.  ACCESMVS takes this lpr job and outputs it as a
JES2 spun dsn to a sysout class we can define.  This would
ordinarily get printed with ACCESMVS banner page and would not
get charged to the user ( nor would operations know where to put
the output.) However, we have a started task that is really a
JES2 external reader that picks up these lpr jobs from this
sysout class and fetches the job, interprets the command line and
uses the info on the command line to resubmit the print job with
that information to JES2.  The result is a print job with the
users accounting information for chargeback and distribution.

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      Wed, 21 Mar 90 12:53:44 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        philipp@gipsi.gipsi.fr
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: MX Records

> Is it time yet to decree that A records should not be used in
> lieu of the MX records when delivering mail?  It would seem
> that the "transition" period is well commenced, and it is
> time to cut-over...

Philip:

    Which of the following two cases are you proposing we stamp out?

    (1) Mailers that never look for MX RRs?  [I think these folks
    have plenty of incentive to fix this -- their mailers can't
    get certain places otherwise].

    (2) Mailers that follow RFC 974 and look for an A RR if an
    MX RR doesn't exist. [There are folks who say this is a convenient
    shorthand, that spares them the need to enter all those MX
    RRs when they aren't needed].

Craig
-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 90 12:23:43 GMT
From:      oberman@rogue.llnl.gov (Oberman, Kevin)
To:        comp.protocols.tcp-ip
Subject:   Re: MX Records

In article <9003151416.AA13535@Gipsi.Gipsi.Fr>, philipp@GIPSI.GIPSI.FR (Philippe Prindeville) writes...
>Is it time yet to decree that A records should not be used in
>lieu of the MX records when delivering mail?  It would seem
>that the "transition" period is well commenced, and it is
>time to cut-over...

What exactly do you mean by "in lieu of MX records"? RFC-1123 does not talk
about any transition period. It only describes the sequence of DNS queries and
how they should be responded to. Certainly any mailer should make use of MX
records. But I have never seen any suggestion that some magic "transition" will
ever take place when A records will simply be ignored.

Or am I mis-understanding the point?

					R. Kevin Oberman
					Lawrence Livermore National Laboratory
					Internet: oberman@icdc.llnl.gov
   					(415) 422-6955

Disclaimer: Don't take this too seriously. I just like to improve my typing
and probably don't really know anything useful about anything.

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 90 17:53:44 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: MX Records


> Is it time yet to decree that A records should not be used in
> lieu of the MX records when delivering mail?  It would seem
> that the "transition" period is well commenced, and it is
> time to cut-over...

Philip:

    Which of the following two cases are you proposing we stamp out?

    (1) Mailers that never look for MX RRs?  [I think these folks
    have plenty of incentive to fix this -- their mailers can't
    get certain places otherwise].

    (2) Mailers that follow RFC 974 and look for an A RR if an
    MX RR doesn't exist. [There are folks who say this is a convenient
    shorthand, that spares them the need to enter all those MX
    RRs when they aren't needed].

Craig

-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 90 21:14:42 GMT
From:      usenet.ins.cwru.edu!cwjcc!ncoast!fmsystm!macy@tut.cis.ohio-state.edu  (Macy Hallock)
To:        tcp-ip@nic.ddn.mil
Subject:   Need info on Bridge CS/1
In setting up our thick ethernet tcp/ip lan, we have been given
a brand new Bridge Communications CS/1 to use that is not complete.
We have the manuals (even the registration card) but not the software
for use with a Unix host. Everything else looks like it's there.

Frankly, I have never seen or used one of these before and I'm
not real sure how/what/when to go about setting one of these units.

Any descriptions and help you can give me would help much
(the job you save may be my own....).  I really have no idea
how to go about setting up and using this unit.  I'm not even sure what
it does, but I'm a quick study...  Of course we need the software, too.

 Macy M. Hallock, Jr.     macy@NCoast.ORG         uunet!aablue!fmsystm!macy
  F M Systems, Inc.      {uunet!backbone}!cwjcc.cwru.edu!ncoast!fmsystm!macy
 150 Highland Drive      Voice: +1 216 723-3000 Ext 251  Fax: +1 216 723-3223
Medina, Ohio 44256 USA   Cleveland:273-3000 Akron:239-4994 (Dial 251 at tone)
(Please note that our system name is "fmsystm" with no "e", .NOT. "fmsystem")
-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      21 Mar 90 22:38:28 GMT
From:      pollux!ccruss@ucdavis.ucdavis.edu  (Russ Hobby)
To:        tcp-ip@nic.ddn.mil
Subject:   High Schools on the Internet
During  the past six months UC Davis has been doing a joint project with 
Pacific  Bell and the Davis High School  to see how high school students 
can use the resources of the Internet. The connection to the high school 
consists  of a 56k link and router  to tie their local AppleTalk network 
to the Internet. 

Some  of the uses have  been to tie into  various library card catalogs, 
obtaining  online  information  on  programs  and  requirements  at some 
colleges  and universities,  ftping software  from many  sites, and,  of 
course, reading USENET. In all it has been very rewarding. 

Now  the question:  Are there  any other  high schools  connected to the 
Internet?  The Davis High students would like to share their experiences 
with  other  high  school  students  and  find  out  if  there are other 
resources  in which they  would be interested.  Perhaps we can  set up a 
mail  list or newsgroup for discussions. I think that it would be a real 
education  for  high  school  students  to  talk  to others in different 
environments  and share some of lifes problems and solutions experienced 
during  a particularly confusing  time in life.  (remember when you were 
that age? ;-) 

Russ
                                Russell Hobby               
                         Data Communications Manager 
     U. C. Davis                 
     Computing Services      INTERNET: rdhobby@ucdavis.edu  
     Davis Ca 95616          BITNET:   RDHOBBY@UCDAVIS  
     (916) 752-0236          UUCP:     ...!ucbvax!ucdavis!rdhobby 
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 90 01:33:55 GMT
From:      glf@iconix.assco.oz.au (Giuseppe Fiusco)
To:        comp.sources.wanted,comp.sys.hp,comp.protocols.tcp-ip
Subject:   SLIP running on HPUX machines


I am trying to locate a version of slip that will run on HP9000
boxes running HPUX.

I was wondering if anyone out there knows of the existance of such a beast.

If you know something could you please send mail as I do not get to read
the news as frequently as I would like.

Giuseppe Fiusco

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 90 04:42:09 GMT
From:      joel@arizona.edu  (Joel M. Snyder)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: ANSI Doc.
You can't get :

ANSI
CCITT
ISO

documents through the Internet.  These are all
copyright by their respective standards bodies,
and are not available--IN FINAL FORM--except
from authorized distributors (we call these "bookstores"
in the real world). 

However, you can get copies of DRAFT documents from
the document editor or from the BNR representative
to the aprporpriate committees, subject to whatever
agreement you can make with that person.

BNR is quite well represented (via the Northern Telecom
connection); if you inquire (enquire for you Canadians)
in your own organization (organisation), it is likely
that you will find good copies of everything in the
datacomm standards area.

Joel Snyder
Member, ANSI X3S3.7 et al.
-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 90 05:16:33 GMT
From:      asleeman@waikato.ac.nz
To:        comp.protocols.tcp-ip
Subject:   Network Monitoring with PC-Clone (info wanted ?)

Gidday. I am looking for assistance in setting up a PC-Clone with a WD8003e
Ethernet Card to operate in a permissive mode to operate as a traffic 
logger / network stat's collector. If you know of any code that 
already does this sort of thing or have the info on the WD8003 card which
would let me do it myself I would be grateful if you would share it with me.
E-Mail responses prefered.

Thanks.
    Andrew Sleeman

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      Thu, 22 Mar 90 18:57:53 -0500
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        intercon!news@uunet.uu.net (Amanda Walker)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Who is the SNMP enterprise subtree czar?

> I know this is more appropriate for the SNMP mailing list, but since I've
> never succeeded in being added to that list, I'm asking a wider audience.

One of the problem that I've seen is that replying to your
mail is problematic since it drops into a black hole or
better yet bounces for a myriad of
reasons. I'm now responding
to the user id "news", which seems broken to me but you can
call yourself anything you want.  Many times it has been
suggested I use a more appropriate id like "bear" (or bjorn when
I travel in Sweden).

> Who is the object ID czar for "enterprise" subtrees (vendor-specific
> information) in the SNMP MIB?  I seem to remember that it was someone besides
> the NIC, but now that I need the information, I can't find it :-).

jkrey@isi.edu is the person to talk to, and her email always works.

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

 --
 Amanda Walker
 InterCon Systems Corporation

 "Many of the truths we cling to depend greatly upon our own point of view."
 	--Obi-Wan Kenobi in "Return of the Jedi"
-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 90 11:35:46 GMT
From:      sunrise!weber@husc6.harvard.edu  (Bob Weber)
To:        tcp-ip@nic.ddn.mil
Subject:   POP on IBM Mainframe?
Does anyone know of an implementation of POP for an IBM	
mainframe running VM/CMS? (Yes, I know, why bother
yes i'd rather see it on a Unix box).

Thanks 
Bob Weber


------------------------------------------------------------------
Bob Weber                    | Voice (617) 495-3744
Sr. Technology Consultant    | Fax   (617) 495-0500
Harvard University/OIT       | Bitnet: weber@harvarda
50 Church St., 4th Floor     | Internet: weber@sunrise.harvard.edu
Cambridge, MA 02138          |           weber@popvax.harvard.edu
------------------------------------------------------------------
-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 90 14:33:52 GMT
From:      cs.dal.ca!aucs!850323l@uunet.uu.net  (Andrew Lavigne)
To:        tcp-ip@nic.ddn.mil
Subject:   Info on FTP

  I have to do a project dealing with FTP for my Operating Systems course. 
This is really my first time even at this kind of thing (TCP/IP, network
architecture, etc), so I am looking for a *brief* overview, with emphasis
on how FTP relates to the network.  
 
  More specifically, I'm wondering what *exactly* happens when one does a
file transfer with FTP - How the data is transmitted, through what layers
(services?), what kind of error checking and error recovery there is, etc.
 
Perhaps someone could briefly explain what happens, say, in an
example file transfer.  

Any help is greatly appreciated.  Please Email me at my address.

Thanks, Andrew

-- 
Andrew Lavigne  | UUCP :{uunet|watmath|utai|garfield}!cs.dal.ca!aucs!850323l
914 Crowell Twr | BITNET   : 850323l@Acadia
Wolfville, NS   | INTERNET : 850323l@AcadiaU.CA
CANADA, B0P 1X0 | Phone    : (902) 542-9966
-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 90 17:59:43 GMT
From:      xberri@arecibo.aero.org (Jason E. Berri)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   summary of responses: LAT-TCP/IP Terminal Servers

Well, here is MY summary of responses to my query on TCP/IP-LAT terminal
servers!  First of all, thanks to all those who replied to my query a few
weeks ago.  I didn't get as many replies as I would of liked, but beggars
can't be choosers, eh? 

Here is some background information on our site.  Currently, we have 4
DecServer 200's on a LAN consisting of Vaxen, Suns, PC's, and MAC's (pretty
typical I suspect).  The DecServer users are restricted to LAT connections
to our VMS Vaxen and a few direct connections to Non-LAT hosts (suns) via
DecServer ports.  I would like to give them the capability of connecting to
*any* TCP/IP host as well as any LAT host with out changing the DecServer
200 interface they are used to.  So I set out in search of either a
dual-protocal server to replace my DecServer 200's or one of the new
"protocol servers" that sit on the network and translate between TCP/IP and
LAT. 

I managed to get two demo units to evaluate so far: a Xyplex Maxserver 1800 
and an Able NPS/100.  As stated in the other summary, the Xyplex unit is a 
16 port dual protocol server that self-loads from a 3.5 inch floppy (the 
Maxserver 1500 loads from a vax via MOP protocol, ala the DecServer 200).  
Impressions: nice unit, command interface virtually identical to the 
DecServer, software appears mature, requires I replace my DecServers to gain 
the dual-protocol functionality I want.  The Able NPS/100 is a network 
protocol server that sits on the network and translates between LAT and 
TCP/IP.  Impressions: just out of beta-test thus software is immature, 
non-decserver command line interface, poor documentation, difficult to 
configure the software, requires you log into the unit to use the protocol 
translation.

Based on the replies to my query and the discussion so far on comp.os.vms, I 
will try to obtain a Datability VCP-1000 next.  Looks like this box does 
exactly what I want (i.e. Allows my current DecServers to connect to TCP/IP
hosts).

Here are the replies I received, enjoy.

-Jason

Jason Berri

INTERNET: berri@aerospace.aero.org or berri@arecibo.aero.org

-----
From: J.James Belonis II <belonis@milton.u.washington.edu>

I use Xyplex 1500 and am satisfied.
Its DCL-like command line editing is nice.
Features seem to be increasing nicely with
new versions of software.

J.James Belonis II, U of Washington Physics Computer Cost Center Manager
belonis@phast.phys.washington.edu
-----
From: "Terry M. Combs" <COMBSTM%APPSTATE.BITNET@ncsuvm.ncsu.edu>

We are using the DATABILITY terminal servers at present.  We have a couple of
servers with the dual functionality.  The servers (128 port and 32 port) are
primarily used for LAT and are not exactly stable.  DATATBILITY is looking at
the problems, and I feel will soon fix the problem of the server crashing once
or twice a day.  The original DATABILITY server software was rock solid, but
the introduction of LAT made the server a little less stable.

I am not slamming the product, only telling you how it is at present.  Our
direction has been to standardize on DATABILITY as our comm vendor.  The box
loads/boots in 5 seconds, since it has all software on board the server.  It is
also 1/3 the price of a comparable configuration in DECserver 200s.   The TCP
supports routing, nameservice, and TELNET, with printer support to follow in a
couple of months.  We feel this is a good way to go, since it makes us less
dependent on DEC and their fickle approach toward trying to corner the market.

The service so far has been very good.
                                                                              .

- Terry
  Bitnet:    COMBSTM@APPSTATE
  Internet:  COMBSTM@Conrad.Appstate.Edu
-----
From: skaggs@nsslsun.gcn.uoknor.edu (Gary Skaggs)

Jason, we've had a Datability Vista VCP-1000 terminal server here since 
last summer.  The LAT part of the server works very, very well.  In
talking with the Datability people during the fall regarding a very 
annoying problem (this server is not without faults), I was told that
they will *real soon now* be releasing a dual protocol chip.  We needed
badly to unload our VAX that is serving as the TCP/IP gateway so I ordered
the upgrade chips.  When I received them (Version 2.17), I installed them
late in the evening and all went well until about noon the following day.
At that time, I received an error message that I'd never seen before, the
server rebooted and cleared all users.  NOT GOOD!

I called my good contact at Datability and told her what happened.  She then
told me that the software people had called and told her that whenever anyone 
mistypes and enters a destination resource, it will reboot the system.  Big 
hole in software!  They said that the fix (Version 2.18) will be out *real
soon now*.  It's been two weeks.  Oh, well.  

It still does what we need for it to do and the price is reasonable.
We've made this bed and we're going to lie in it.  Will let you know how
it goes when the fix comes in.
______________________________________________________________________________
Gary Skaggs 			Internet: skaggs@nssl.gcn.uoknor.edu
National Severe Storms Laboratory (The Tornado People)
"The Government can speak for itself (usually), and NO, I don't want to be
     like Gary England (Amway(tm) salesman and 'meteorologist') !"
-----
From: mpm@proteon.com (Mike P. McDonough)

Jason,

I just wanted to express my interest in the results of your query regarding
multi-protocol servers. I am quite familiar with the Interlan NTS's running
LAT/TCP but as a recent Interlan (Racal Interlan this year) employee I won't
comment on the product.


Mike McD

mpm@proteon.com
-----
From: "Larry MacNeill - UCHSC Medical Computing Ctr, 303-270-5166"
 <LARRY%FIJI@VAXF.Colorado.EDU>

We, too, are shopping for dual protocol terminal servers (with a faint
hope of finding OSI supported as well).  I speak for at least one group
expressing interest in the opinions you gather.  Will you post a summary?
-----
From: rwWright@lbl.gov (Russ Wright)

We are using 6 Hughs Lan Systems 4208 terminal servers.  They are cheap 
(under $1600 list) and seem to work well for both TCP and LAT.

The only number I have is our local sales person, Mike McMahan - 
(415)966-6153.


Russ Wright
Lawrence Berkeley Laboratory
rwWright@lbl.gov
-----
From: uunet!amdcad!pepsi!remaker@CS.UCLA.EDU (Phillip A. Remaker)

cisco is doing one soon.  And we love their terminal servers, so you may want 
to check with them, depending on how soon you need it.

They'll be glad to give you a sales pitch at 1800553nets.

-P
-- 
Phillip A. Remaker A.M.D. M/S 167 P.O. Box 3453 Sunnyvale, CA 94088-3000
remaker@amdcad.amd.com  Cutting Edge Networking...Close to the Jugular...
"It's only work if someone makes you do it."  -Calvin
-----
From: Jeff Carroll <carroll@atc.boeing.com>

	I have just bought some dual-protocol servers from Lantronix and am
pleased with them despite the problems I have had. The first two died within
24 hrs of power up, but Lantronix shipped me new ones in next day UPS (insist
on it). The hardware I have now works well, is smaller than any other on the
market, and is much cheaper than any other dual-protocol server on the 
market (at $1500 for 8 ports).
	The software I have is not quite mature, but there is a new release
which I don't have yet (new releases are available via Kermit xfer at up
to 9600 baud from their VAX; they're working on FTP access).
	If you don't need a huge number of ports in one location, this
is a very attractive product. The server is light enough to hang on a
wall (desk, partition) from a couple of Velcro strips (not included).
	I have the phone number at the office. Email me if you need it.

	Jeff Carroll
	carroll@atc.boeing.com
-----
From: Avri Doria <avri@interlan.interlan.com>

I would be intersted in  the results of your query.

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
-----
From: Mark Towfigh <towfiq%interlan.interlan.com@RELAY.CS.NET>

Racal InterLan makes one.  I use it every day, and I'm quite satisfied.
You can find out more from our pre-sales staff at 1-800-LAN-TALK.

Hope this helps,
Mark
-----
From: "Richard DeJordy, x4029" <RAD@math.ams.com>

Hi,

I was wondering if you could either post or mail me a summary of the information
you receive regarding TCP/Ip LAT terminal servers.

Thanks.
Richard DeJordy                  American Mathematical Society
Systems Programmer               P.O. Box 6248
                                 Providence, RI 02940
RAD@MATH.AMS.COM                 (401) 455-4029
-----
From: Bob Albrightson <bob@jvncb.csc.org>

cisco Systems of Menlo Park CA makes a miltiprotocol terminal server that
runs lat and rlogin/tcp and telnet/tcp.

 -bob
-----
From: <NADI%VUVAXCOM.BITNET@CORNELLC.cit.cornell.edu>

We are currently using the VISTA box ( VCP-1000 ) from DATABILITY which solved
some of our connectivity problems. We have it configured with 2 NPT cards
(Network Protocol Translator). This gives us 32 lines for protocol conversion
from LAT  to TCP/IP (on either direction).
This box is used to show and provide access to all the TCP/IP services you want
terminals connected to your LAT DECservers to access.

We are still using "Reverse LAT" between some of our DECservers (LAT) and
3COM servers (TCP/IP) to access the TCP/IP hosts.

The DATABILITY VCP-1000 has been running for about a month in our site.
We are very pleased with it. The other good points about it are:

    Your users can access the TCP/IP services like any LAT service.
    You will have a clean disconnect (not guaranteed with Reverse LAT).
    A single box can give you up to 64 LAT<--->TCP/IP translation lines.
    An excellent technical support.

Nadi Najib
nadi@vuvaxcom      (bitnet)
nadi@villanova.edu (csnet)
(215) 645 4852     (AT&T)
-----
From: John Dorn <graphon@gpu.utcs.utoronto.ca>

Try lantronix in Laguna Hills California.
ther make a 8 and a 16 line LAT/tcp/ip box it is small and inexpensive.
list is $1695 and $2495.
Works good too.
-----

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 90 19:08:06 GMT
From:      intercon!news@uunet.uu.net  (Amanda Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Who is the SNMP enterprise subtree czar?
I know this is more appropriate for the SNMP mailing list, but since I've
never succeeded in being added to that list, I'm asking a wider audience.

Who is the object ID czar for "enterprise" subtrees (vendor-specific
information) in the SNMP MIB?  I seem to remember that it was someone besides
the NIC, but now that I need the information, I can't find it :-).

Thanks to anyone who can help,

--
Amanda Walker
InterCon Systems Corporation

"Many of the truths we cling to depend greatly upon our own point of view."
	--Obi-Wan Kenobi in "Return of the Jedi"
-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 90 20:03:11 GMT
From:      ico!ism780c!kirkd@handies.ucar.edu  (Kirk Davis)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP header compression
Hi All,
   Does someone out there know where I could perhaps pick a spec or
code examples of the SLIP header compression I hear talked about from
time to time??? I've looked here and there on the net, and all versions
I've run across don't seem to implement it. It would be nice to be
compatable with someone...

pls email on any interesting SLIP sites/info. I'll summarize (so help me...)

tnx,
Kirk Davis	Interactive Systems	(kirkd@ism.isc.com)
-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 90 21:49:51 GMT
From:      m2c!seqp4!seqp4.uucp!markr@husc6.harvard.edu  (Mark Roddy,)
To:        tcp-ip@nic.ddn.mil
Subject:   print servers

I know this has been around before, but I'm sorry, I didn't
pay attention. Is there a formal or informal definition of
a TCP print service? If yes, does there exist a public domain
source code implementation of same?

Reply by e-mail would be appropriate.
-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 90 22:32:07 GMT
From:      austins@garnet.berkeley.edu (Austin Shelton)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   POP3 Server Version 1.6 Available

Version 1.6 of the Berkeley Post Office Protocol (version 3)
server is now available.  This version has these changes:

(1) It corrects a bug that causes the server to dump core on 
SunOS version 4.0.

(2) It uses varargs and vsprintf (if it exists) for the 
pop_msg and pop_log functions.  A new CFLAG option
"HAVE_VSPRINTF" has been introduced to control whether
or not vsprintf is used.

(3) It includes some extra "reality checking" in pop_init
for systems that use BSD 4.3 bind.  It does a cannonical
name lookup on the name returned by gethostbyaddr and 
searches the returned address list for the address of
the client, logging a warning message if it is not found.
A CFLAG option "BIND43" turns on this feature.

(4) All those includes in popper.h have been removed and
distributed (as needed) throughout the program files.
The "<inode.h> not found" problem is corrected by this.

(5) The installation guide has been moved to (and will remain
as) the README file.  The Macintosh versions are discontinued.

(6) The sources files have be editted to be displayable on
an 80-column terminal and the tabs converted to spaces.  Sigh.

I want to thank Viktor Dukhovni of Princeton University
for diagnosing and correcting the problems described
above.  Viktor is still working with me to add RPOP
support and correct certain file contention and
integrity problems that can affect the maildrop.  I hope
to have a version out soon with these fixes.  However, I
thought an interim release with the above fixes might be
useful.  Caveat:  I haven't had much time to test this release.
All I know is that it compiles, starts up and finishes 
gracefully on BSD 4.3, Ultrix, SunOS 3.5 and 4.0.

The distribution is now in two parts:  popper.tar.Z (a
compressed tape archive) and MacPOP.sit.hqx (a Macintosh
StuffIt archive that has been BinHexed).  The latter 
is all of the Archive.sit.hqx stuff that used to be
included in popper.tar but excludes the documentation.

The distribution is still available via anonymous ftp to
lilac.berkeley.edu (128.32.136.12) and both parts are
in the pub directory.  As usual, please retrieve it during
off-hours.

Thank you,
	Austin Shelton
	U.C. Berkeley

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      22 Mar 90 23:07:28 GMT
From:      ogicse!blake!mrc%Tomobiki-Cho.CAC.Washington.EDU@uunet.uu.net  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   Consider IMAP instead of POP

Recently there have been a lot of messages on TCP-IP asking about
POP-based software.  There is an alternative to POP, IMAP, described
in RFC-1064.  The IMAP protocol is technically superior to POP; it
provides significantly more advanced server functionality (including
server-based RFC-822 parsing and a server-based search engine) which
allows for simpler, yet more powerful, clients.

We've been chary about advertising, since we're actively working on
various IMAP-based tools and don't want people to get the wrong idea
about our software based on incomplete development versions.  However,
that doesn't mean that IMAP is vapor; it's been in use at Stanford
University, the University of Washington, NTT, and other organizations
for years.

A beta IMAP distribution is available for anonymous FTP as
pub/imap.tar.Z from Internet host ftphost.CAC.Washington.EDU, IP
address [128.95.112.1].  On Unix, the commands "uncompress imap.tar.Z"
followed by "tar xf imap.tar" will give you an IMAP directory.

This distribution includes:
 (1) IMAP client for Xerox Lisp (no further development planned)
 (2) IMAP server for DEC-20/TOPS-20 (no further development planned)
 (3) IMAP server for BSD Unix (contact yeager@SUMEX-AIM.STANFORD.EDU
			       for updates; this software is under
			       active development)
 (4) Portable IMAP client library in C, with OS-dependent interfaces
     for BSD Unix, TOPS-20, Macintosh, and MS-DOS.
     (4a) portable "test" IMAP client
     (4b) BSD Unix IMAP client with MM-like interface
     (4c) NeXT GUI client in advanced and stripped-down form (contact
				me for updates; this software is being
				changed daily)

Sources to everything except for (4c) are included.  In addition,
Stanford University has developed a Macintosh client; contact
yeager@SUMEX-AIM.STANFORD.EDU for information on how to obtain a beta
copy.  I have been contacted by various individuals who are developing
MS-DOS clients; I don't know if any have been released yet.

The main thrust of my recent efforts has been in the NeXT client.  I
should caution that the NeXT GUI client is still in beta test and that
one functionality (the address book) doesn't work at all.  However, it
has been operable enough for me to use as my primary mail UA for a
year now.
-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Mar 90 08:48:18 -0500
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        dsl.pitt.edu!dsl.pitt.edu!sean@PT.CS.CMU.EDU (Sean McLinden)
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: CMOT Implementations

> I sincerely hope not. SNMP is probably adequate for the task of network
> management of networks and the full implementation of CMIP is, most likely,
> overkill for what are basic network management tasks, but when you start
> talking about the management of network objects that represent the
> state of the real world (I mean, the computers are there to support
> more than their network connections!) is when you see the real power
> of a protocol like CMIP.

But what is the basis of the "real power"?  Wallpaper diagrams?  When
I think of the "real world" I start thinking about "real time", where issues
like low latency become critical.  Real world means that my refrigerator
that has a Z88 microprocessor in it might be controlled through an
appliance network, will I put CMIP and its stack in the Z88, not really.
Given the limitations of the protocol as it accesses its MIB I probably
can't even ask if the light is on and if my beer is cold in the same
operation, something that the "real power" of SNMP detergent can handle.

> At the risk of sounding heretical, my personal opinion is that an
> implementation of CMOT would make TCP/IP sufficiently robust as to
> make it an attractive competitor to OSI (at least until we run
> out of addresses). To put this another way, the real appeal of
> OSI (and there are a lot of unappealing things about it), is not
> the market hype but what is the OSI concept of information as it
> exists in communities (an idea retrofitted to TCP/IP with such tools
> as XDR, RPC, Threads...). With a generalized interface to what is
> network information a la CM{IP,OT} you have a pretty powerful system
> which has the advantage of being widely available across multiple
> architectures. Until full implementations of the OSI stack
> become widely available CMOT would extend the functionality of TCP/IP
> as an OSI prototyping tool for, at least, the next few years, allowing
> for the applications to be developed in parallel with the network.

This is positively orwellian.  Not to confuse facts with fiction but
OSI is right now unsuccessfully trying to compete with tcp/ip as
a technical solution and market issue.  When the trading companies
of NY and banking are using tcp/ip I don't know how much more button
down it gets.

And this is all despite a number of ivory towered bureaurcrats who
are trying to make their professional objecives by saddling their
peers with non-useful GOSIP.

Lastly, you think of XDR/RPC as retrofit, I see the Internet reference
model and all of its practical mechanisms as fully supporting added
functionality as the state of the art for information technology
evolves.  RPC's I would use as a counter argument.

Marty
-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      Fri, 23 Mar 90 09:51:23 PST
From:      Nachum Shacham <shacham@itstd.sri.com>
To:        tcp-ip@nic.ddn.mil
Cc:        shacham@itstd.sri.com
Subject:   IEEE INFOCOM '91: Call For Papers



			     IEEE INFOCOM '91
		The Conference on Computer Communications

			  Networking in the 90's
	   April 7-11, 1991  Sheraton Bal Harbor, Miami Florida

 +--------------------------------------------------------------------+
 |                           CALL FOR PAPERS			      |
 |      	     Tenth Annual Joint Conference of the             |
 |      	  IEEE Computer and Communications Societies	      |
 |      						              |
 |Sponsored by the Technical Committees for Computer Communications   |
 |of the Societies						      |
 +--------------------------------------------------------------------+
Authors are invited to submit full papers on recent advances in computer
communications.  Areas of interest include, but are not limited to:

   Integrated Services Networks           Network applications
   Metropolitan and Wide Area Networks    Host interface Architecture
   Local Area Networks                    Photonics in Communications
   Network Management                     ISDN Technology
   Communication Protocols                Broadband ISDN
   Distributed Network Algorithms         Network Interconnection
   Network Modeling and Analysis          Network Reliability
   Satellite Networks                     Network Routing and Addressing
   Wireless Data Networks                 Computer Security and Privacy
   Networks Design and Planning           Multimedia Information Systems
   Switch Processor Architecture          Network Standards

				 SCHEDULE
		  Full paper (5 copies) -- August 1, 1990
	      Notification of Acceptance -- October 31, 1990
		   Camera Ready Copy --December 15, 1990
		      Conference -- April 7-11, 1991
		       Tutorials -- April 5-6, 1991

Submit papers to:
Dr. N. Shacham, Technical Program Chairman, IEEE INFOCOM'91
SRI International,  333 Ravenswood Ave, Menlo Park, CA. 94025
Telephone (415) 859-5710   Email: Shacham@sri.com



-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 90 07:32:53 GMT
From:      uhccux!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!yarra!melba.bby.oz.au!leo!gnb@ames.arc.nasa.gov  (Gregory N. Bond)
To:        tcp-ip@nic.ddn.mil
Subject:   xntp?  What is it?
I have seen some references in comp.sys.sun to using xntp for time
management.  I know and run ntp (patchlevel 13 89/05/18).

What extra facilities/changes/improvements does xntp give?

Or am I barking up the wrong tree entirely?

Greg.
--
Gregory Bond, Burdett Buckeridge & Young Ltd, Melbourne, Australia
Internet: gnb@melba.bby.oz.au    non-MX: gnb%melba.bby.oz@uunet.uu.net
Uucp: {uunet,pyramid,ubc-cs,ukc,mcvax,prlb2,nttlab...}!munnari!melba.bby.oz!gnb
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      Fri 23 Mar 90 14:24:17-EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        schoff@psi.com
Cc:        dsl.pitt.edu!dsl.pitt.edu!sean@PT.CS.CMU.EDU, tcp-ip@nic.ddn.mil
Subject:   Re: CMOT Implementations
Marty (et al.) --

The Z88-in-the-frig image is delightful and can, I think, lead to a potentially
quite useful insight into (oh, dear) "networking style".

Consider: The approach we took with the Network Virtual Terminal notion in
Telnet was essentially to require the common features and allow for the
negotiation of uncommon ones.  The intersection of feature sets, if you will.
However, the OSI style -- particularly evident in FTAM, which I just happen
to have forced myself to stare at yesterday, but apparently also the case
w/r/t CMboth -- seems to be to specify the intersection of all known (and
maybe some unknown, in the sense of not existing in any known implementation
but "a good idea" to someone) feature sets, and then in the fine print require
only something like the common subset.  That is, they at least appear to be
dealing with the union (or more) of features -- and don't appear to offer
as "clean" as mechanism as Telnet WON'Ts and DON'Ts for demurrers.  (Indeed,
I haven't probed deeply enough to be sure that they always have a means avail-
able to indicate "I couldn't possibly do THAT for you".)

So from the perspective of a maybe not all that hypothetical Z88-in-a-frig
programmer, the style of protocol based on "from each according to his ability"
would certainly seem to be more attractive than that of a protocol based on
"from each according to OUR needs", even if, to bring in another analogy, you
can go through a somewhat tedious process to get an abatement of the abritrary
property taxes you've been billed for.  (At least, with any luck at all you
can get the abatement; I'm still not sure the FTAM "virtual filestore" you're
expected to front your native filesystem with doesn't have to be bigger than
your native filesystem, for just about all values of native filesystem.)

That might all be a bit cryptic, I suppose, but since They won't be listening
and We still tend to do it right, I'll let it go at mentioning that a very
wise bridge writer once said that the trouble with the Unlucky Expert is that
he always tries for the best possible result instead of the best result
possible....

     cheers, map

Afterthought:  Gee, if "Politics is the art of the possible" maybe the ISO
isn't all that political after all.  (Or have I said that before?)
-------
-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 90 13:15:48 GMT
From:      mcsun!hp4nl!gouldnl!ted@uunet.uu.net  (Ted Lindgreen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: broadcast storm
In article <9003121734.AA22356@ISIS.U-STRASBG.FR> pansiot@isis.u-strasbg.FR (Jean-Jacques Pansiot Departement d'Informatique Universite Louis Pasteur Strasbourg FRANCE) writes:
>
>Anything I can do? (Stations B and C
>are mostly SunOS 3.5 , no SUNOS4.0).

Best solution is to upgrade the old operating systems, also
possible it to go back to the old style broadcast address on
all systems and routers.
Of course, upgrading might take some time and effort, and
going back is a bad thing to do.

A quick hack to get rid of the ARP's and most ICMP's is to add a
bogus ARP entry on the systems that don't understand the correct
broadcast address (in your case 130.79.255.255) to point at some
non-existing ethernet address:
 /etc/arp -s 130.79.255.255 0.1.2.3.4.5
or add
 130.79.255.255 0.1.2.3.4.5
to /etc/rarp.hosts if "/etc/arp -f /etc/rarp.hosts" is invoked
at boottime.

Of course, this does not help the ancient systems to recognize
rwho and router messages, but it does help to get rid of your
broadcast storms.
-- 
| Ted Lindgreen                                      ted@encore.nl |
| Encore Unix Centre Europe          ...!mcsun!hp4nl!encore.nl!ted |
| Maarssenbroek, The Netherlands       (USA) tlindgreen@encore.com |
-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 90 13:30:53 GMT
From:      amdahl!fai!ljb@ames.arc.nasa.gov  (Larry Boggis FAI N.C.)
To:        tcp-ip@nic.ddn.mil
Subject:   Telnet Socket
Can anyone send me a sample program that sets up a socket connection to
a telnet port on a 3COM cs200 terminal server which has an IP address
assigned to it?  (Wow that was a mouthful :-)

-----
  Larry Jay Boggis, Computer/Network Operations, Fujitsu Network Switching
  4403 Bland Road  Raleigh, North Carolina 27609
  E-mail:ljb@fai.fai.com  (Phone:919-790-2211 Ext. 3364) FAX:919-790-8376
-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      Fri 23 Mar 90 20:15:03-EST
From:      Michael Padlipsky <PADLIPSKY@A.ISI.EDU>
To:        schoff@psi.com
Cc:        dsl.pitt.edu!dsl.pitt.edu!sean@PT.CS.CMU.EDU, tcp-ip@nic.ddn.mil
Subject:   Correct previous message
OOPS!  Never could proofread on Friday morning.  When I looked at the BCC I'd
sent myself of this morning's message, I noticed a fairly fundamental typo.
What the garbled sentence SHOULD have said (with the one after it, for
context) is:

However, the OSI style -- particularly evident in FTAM, which I just happen
to have forced myself to stare at yesterday, but apparently also the case
w/r/t CMboth -- seems to be to specify the *SUPERSET* of all known (and
maybe some unknown, in the sense of not existing in any known implementation
but "a good idea" to someone) feature sets, and then in the fine print require
only something like the common subset.  That is, they at least appear to be
dealing with the union (or more) of features -- and don't appear to offer
as "clean" as mechanism as Telnet WON'Ts and DON'Ts for demurrers.

Sorry about that.  My Freud probably slipped because I was busy resisting the
temptation to hearken back to my old warcry about implementors designing
better protocols than standardscommitteepersons, which in turn would have
forced me to acknowledge that Marshall Rose phrased the distinction more
neatly with his Doers vs. Goers image, and of course I'd never say a thing
like that in public.  (Heh, heh.)

    re-cheers, map
-------
-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 90 15:49:23 GMT
From:      aecom!naftoli@uunet.uu.net  (Robert N. Berlinger)
To:        tcp-ip@nic.ddn.mil
Subject:   Broadcasting Adreess and Subnets
Which RFC would explain the proper way to configure broadcast
addresses when using subnets?  For example, for a class B address, 8-bit
subnet on subnet 1, would the broadcast address be XXX.XXX.255.255
or XXX.XXX.1.255?
-- 
Robert N. Berlinger                 |Domain: naftoli@aecom.yu.edu        
Supervisor of Systems Support       |UUCP: ...uunet!aecom!naftoli
Scientific Computing Center         |CompuServe: 76067.1114@compuserve.com
Albert Einstein College of Medicine |AppleLink: D3913@applelink.apple.com
-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 90 16:22:26 GMT
From:      bu.edu!polygen!bill@husc6.harvard.edu  (Bill Poitras)
To:        tcp-ip@nic.ddn.mil
Subject:   Using SLIP with SCO Xenix/Unix
Does anyone know if there is a way to run a SLIP program on a IBM computer
running SCO Xenix/Unix, with a multi-port serial board.  I want to be able to
allow multiple users dial into the serial ports and then run a package that 
supports SLIP running MS-DOS such as FTP's PC/TCP, or a public package, such
as PCIP.  The Xenix/Unix will most likely be running Excelan's LAN Workplace forXenix/Unix, for TCP/IP software.  Any help would greatly be appreciated.

 
+-----------------+---------------------------+-----------------------------+
| Bill Poitras    | Polygen Corporation       | {princeton mit-eddie        |
|     (bill)      | Waltham, MA USA           |  bu sunne}!polygen!bill     |
|                 |                           | bill@polygen.com            |
+-----------------+---------------------------+-----------------------------+
-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      Sat, 24 Mar 90 10:04:08 -0800
From:      chris@salt.acc.com (Chris VandenBerg)
To:        snmp@nisc.nyser.net, tcp-ip@nic.ddn.mil
Cc:        gary@salt.acc.com
Subject:   please send mibs in!
Good morning everyone!
		Many of you responded to my request for opinions about
submitting MIBs to a central repository on the net and, I'm very happy
to say, all replies were quite positive. So know I guess it's time to
get the ball rolling. Joyce Reynolds at ISI will make sure they get
put into a public directory at ISI BUT(and I can't emphasize this enough)
she doesn't want MIB's flooding into her mailbox. So it looks like I'm
elected to collect the MIBs and send her one big submission a week. As
previously discussed on the lists all MIBs MUST be in RFC1065 format(and
you could include a text mib if you wish). Info at the top should include
date of submission, company name, point of contact and any notes you
feel would be helpful. I will be putting ACC's mib and whatever I receive
by next Thursday in a message to Joyce on Friday the 30th of March. Joyce
has stated that she and Jon Postel will look them over and consult with
Marshall Rose as needed to verify compliance with the various ASN.1 compilers
out there. This should greatly ease the burden on incorporating mibs from
other vendors and should allow us all to better serve our users.
		I would also ask that you put "mib" somewhere in the subject`
line of the message when you send it to me. If you would rather that I
anonymous FTP your mibs just drop me mail.
		If you have questions or comments please feel free to call or
drop me mail.
		Thanks very much,
				Chris VandenBerg(chris@salt.acc.com)
				805-963-9431
-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 90 20:50:28 GMT
From:      elroy.jpl.nasa.gov!zardoz.cpd.com!durin!frankh@ames.arc.nasa.gov  (Frank Halsema)
To:        tcp-ip@nic.ddn.mil
Subject:   NCSA Telnet on a 3c503
I am trying to set up the 3c503 driver for NCSA telnet. I can get it to work
if I set up the board for shared memory and use thin net. Unfortunately, I
have a thick net cable plant and I need to support PCNFS on this machine.
PCNFS doesn't seem to work if the 3c503 is set up for shared memory. Nothing
in the manuals discuss using the shared memory options on the board. 

What I am looking for is one of the following solutions:

    1)  run NCSA telnet on the 3c503 with thick net and shared memory
        disabled
    2)  run NCSA telnet on the 3c503 with thick net and set up PCNFS to
        run with shared memory at DC000

You may wonder why I am using NCSA Telnet and PCNFS. The PCNFS is what the
staff normally uses. NCSA Telnet is needed to support the development of a
UNIX Librarian product. If I can't fix my problem by reconfiguring the
software, I will have to set up a system just for product testing or
reconfigure the PCNFS system every time I want to test. These are not nice
solutions.

Thanks for the help!!



-- 
Frank Halsema                           UUCP: durin!frankh             
SPARTA, Inc.                   		ARPA: frankh@durin.sparta.com
23041 de la Carlota, Suite 400
Laguna Hills Ca, 92653     (714) 768-8161 EXT 339  (714)583-9114 FAX
-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 90 21:07:36 GMT
From:      snorkelwacker!usc!trwind!venice!gay@bloom-beacon.mit.edu  (Lance Gay)
To:        tcp-ip@nic.ddn.mil
Subject:   IPACP of CMUTEK 6.4 aborting
We are running Version 6.4 of the CMUTEK TCP/IP software over a DEUNA on a
VAX 8650 under VMS V5.2.  The software has been running fine for a few months.
During the last week the IPACP has been aborting within a period of 5 seconds
to a half hour after it was brought up.  The OPCOM error messages follow:

    ?IPACP: Exception handler: signal name 0000000C
    IPACP: Network offline - ACP exiting

This sounds to me like an access violation which the internal signal handler
is capturing.  Has anyone seen this problem?  I don't know of anything we
changed that would make this problem start appearing.  The IPACP.EXE is the
one straight off the distribution tape -- it hasn't been modified.

Lance Gay                                    Internet: gay@venice.sedd.trw.com
TRW Systems Engineering & Development Div.   Phone: 213-764-9292
Redondo Beach, CA  90278
-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 90 21:34:36 GMT
From:      xavier!jeremy@psuvax1.cs.psu.edu  (Jeremy Brest)
To:        tcp-ip@nic.ddn.mil
Subject:   another traceroute question

Traceroute seems to have problems with the very end of many paths.
When it gets close to the destination (I don't know how close), it
starts with the stars, but since I've tried with well managed and
presumably well-behaved networks and hosts, I think that the problem
is with traceroute and not, as the man page says, bogus icmp handling.

There's another problem, which may be related.  Almost all routes that
extend beyond 12 hops give stars for all reports beyond hop 12.
Anyone else have this problem?  The only thing I did that was not
standard in building it was compiling the object files with O2
optimization.  

Thanks,

Jeremy Brest
jeremy@cs.swarthmore.edu
-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 90 22:12:35 GMT
From:      netcom!netcom.uucp!jbreeden@apple.com  (John Breeden)
To:        tcp-ip@nic.ddn.mil
Subject:   SLIP for AT&T V/386
Does anyone know of an IP package for AT&T's SysV/386 R3.2.2 that supports 
ia SLIP interface?

I know that both Wollongong's WIN and Interlan's IP run under AT&T's Unix
but don't know if a SLIP is available. Any suggestions would be appreciated.

Thanks in advance.
-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 90 23:10:28 GMT
From:      m2c!umvlsi!vishwana@husc6.harvard.edu  (Chidambaram Vishwanath)
To:        tcp-ip@nic.ddn.mil
Subject:   Network Management tools.
This is a request.  About a couple of months back some kind soul had
posted that a document(in ps) called "A Draft Network Management Tool Catalog:
Tools for Monitoring and Debugging TCP/IP Internets and Interconnected
Devices" was available by anonymous FTP.  I have only a part of the 
document with me, and unfortunately forgotten the address of the node
from which I got it.

    If anyone has information about it, please post/e-mail!  The help
will be much appreciated.

				- Vishwanath.
-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      23 Mar 90 23:49:50 GMT
From:      bally!pete@uunet.uu.net  (Pete Gregory)
To:        tcp-ip@nic.ddn.mil
Subject:   Is 'PC Network' compatible with 'Ethernet' ??????
Hi y'all netlanders....

I am about to acquire Ethernet cards for my two PS/2's (a mod 70 and 80).
So far all I've found (through another guy at work whose job it is to
buy equipment) is PC-Network adaptor cards.

My question:

	- will these work on an Ethernet?

Thanks in advance....

Pete Gregory   : uucp:   uunet!bally!pete            | 
Software Engr. : domain: pete@bally.bally.com     ---|---
Bally Systems  : phone:  702-323-6156 x882           |         John 3:16
255 Bell St.   : FAX:    702-323-5997                |     (think about it!)
Reno, NV 89503                                       |
-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 90 01:05:19 GMT
From:      bionet!turbo.bio.net!lear@apple.com  (Eliot)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Consider IMAP instead of POP
In IMAP, you've advertised as as a feature great server search
facilities, and the fact that the server protects the client from as
much state as possible. It would seem to me that such an approach
would produce a bottleneck of server resources far faster than POP
would.  In a large scale arena such as SUMEX, would it not be better
to design a protocol where you assume that the free cycles will be on
MANY client machines, rather than a few servers?  I suppose taken to
extremes I should stick to FTP, but I would see where both POP and
IMAP (and FTP) have their places...
-- 
Eliot Lear
[lear@turbo.bio.net]
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 90 03:27:17 GMT
From:      cambridge.apple.com!spt!gz@apple.com  (Gail Zacharias)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Consider IMAP instead of POP
There is one thing that IMAP understands that POP doesn't, and that is that I
want to KEEP MY MAIL ON THE SERVER.  I don't want to delete it from the server
just because I'm reading it on a mac!  I'm not willing to keep all my mail on
a mac, where I do software development and crash all the time (and I can't
even dial up to it if I want to check on some old messages from home).  Our
server is backed up daily, and that's where my mail is going to live.  So I
sure hope some good IMAP clients (on the level of TechMail, say) appear so I
can start using the mac to maintain my mail, SOME OF THE TIME.

--
gz@entity.com					...!mit-eddie!spt!gz
	  Unix: when you can't afford the very best.
-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 90 04:13:11 GMT
From:      dsl.pitt.edu!dsl.pitt.edu!sean@pt.cs.cmu.edu  (Sean McLinden)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: CMOT Implementations
This probably belongs in "comp.protocols.religion" but:

>
>> I sincerely hope not. SNMP is probably adequate for the task of network
>> management of networks and the full implementation of CMIP is, most likely,
>> overkill for what are basic network management tasks, but when you start
>> talking about the management of network objects that represent the
>> state of the real world (I mean, the computers are there to support
>> more than their network connections!) is when you see the real power
>> of a protocol like CMIP.
>
>But what is the basis of the "real power"?  Wallpaper diagrams?  When
>I think of the "real world" I start thinking about "real time", where issues
>like low latency become critical.  Real world means that my refrigerator
>that has a Z88 microprocessor in it might be controlled through an
>appliance network, will I put CMIP and its stack in the Z88, not really.
>Given the limitations of the protocol as it accesses its MIB I probably
>can't even ask if the light is on and if my beer is cold in the same
>operation, something that the "real power" of SNMP detergent can handle.

And I suppose that a "real world" question is the one that you posed
"Is the refrigerator light on and the beer cold?" I certainly find myself
asking just such profound things all of the time!

Let's back off a little. In reality, TCP/IP has evolved (and no one
has argued, least of all me, that it is not a real world workable
solution). SNMP folllowed a similar course of evolution. No one
"got it right the first time." It (TCP/IP) had the advantage, as pointed
out by a number of people but most poignantly by Marshall Rose in "The
Open Book", of being implemented, widely, *before* becoming a standard
(something which OSI *should* have done). It has proven to be remarkably
robust but it is and was, conceptually, designed for a different class
of problems that was OSI. And the reality appears to be, as people
start to implement OSI solutions, that some things are not, easily,
workable and some things will need to be changed. Personally, I like
TCP/IP just fine.

And you may or may not have a Z88 in your fridge and you may or may
not want to put it on "toaster net", but I have a real world problem,
called a hospital information system, and in that environment, I have
addressable "hosts" that range from an IBM 3090 down to pulmonary
arterial oxygen saturation catheter and I want a simple way of mapping
the information that is contained in each of those units into some
common view of the world. And I have prototyped it using the managed
object framework of SNMP, and I have prototyped it using CMIP and I
think that it is obvious from my message which one worked best, for
me.

So, I guess I have little sympathy for the argument that "it doesn't
do what I want it to do so it should be implemented." Besides, experience
has taught me that this year's Amana might have a Z88 but next year's
will have a 68020 if there is enough demand for an application (such
as yours). So many problems that we thought demanded sophisticated
solutions can now be solved using brute force simply because of
advances in processing power...

>> At the risk of sounding heretical, my personal opinion is that an
>> implementation of CMOT would make TCP/IP sufficiently robust as to
>> make it an attractive competitor to OSI (at least until we run
>> out of addresses). To put this another way, the real appeal of
>> OSI (and there are a lot of unappealing things about it), is not
>> the market hype but what is the OSI concept of information as it
>> exists in communities (an idea retrofitted to TCP/IP with such tools
>> as XDR, RPC, Threads...). With a generalized interface to what is
>> network information a la CM{IP,OT} you have a pretty powerful system
>> which has the advantage of being widely available across multiple
>> architectures. Until full implementations of the OSI stack
>> become widely available CMOT would extend the functionality of TCP/IP
>> as an OSI prototyping tool for, at least, the next few years, allowing
>> for the applications to be developed in parallel with the network.
>
>This is positively orwellian.  Not to confuse facts with fiction but
>OSI is right now unsuccessfully trying to compete with tcp/ip as
>a technical solution and market issue.  When the trading companies
>of NY and banking are using tcp/ip I don't know how much more button
>down it gets.

In 1906 more people got around using horses than cars, so what is
the point? I am not disagreeing with you that TCP/IP is workable
in the here and now and OSI, basically, is not. My argument is that
people who say "we don't need anything, conceptually, like CMIP
for TCP/IP because SNMP is enough" need to broaden their view of the
world, a bit. Network management of information is *NOT* the same
as the management of network information. And besides, Orwell was
probably more correct than we give him credit for.
-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 90 14:34:39 GMT
From:      zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!haven!aplcen!warper.jhuapl.edu!trn@tut.cis.ohio-state.edu  (Tony Nardo)
To:        tcp-ip@nic.ddn.mil
Subject:   Anyone know what happened to the NSFNET gateways?
Does anyone know what is wrong with the NSF gateway systems on the network
(e.g. College_Park.MD.NSS.NSF.NET [129.140.9.129])?  Since early Friday
morning, I have been unable to "ping" any of them from hosts on either MILNET
or SURANET.

The problem seems most acute for the cores.  They appear to be forwarding all
traffic from MILNET to other networks thru MCLEAN-MB, at which point the
packets die.

Are all the bridges down?
--
Tony Nardo,		   INET: trn@aplcen.apl.jhu.edu  (safest for now!)
 Johns Hopkins Univ./APL   UUCP: {backbone!}mimsy!aplcen!trn
		    Quote(s) relocated to my finger .plans
-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 90 16:03:39 GMT
From:      granite!piacenti@bbn.com  (Paul Piacentini)
To:        tcp-ip@nic.ddn.mil
Subject:   why won't this routing work?
The following diagram depicts part of a class B network, using a netmask
of 255.255.255.192 (10 bit subnet). This piece contains 3 logical subnets
on 1 wire, the trunk contains several logical subnets of the same class B 
address, with a gateway to the Internet.

                                                              > Internet
            main trunk  X.Y                                  /
  ==============================================================
                                            | X.Y.27.2 (net X.Y.27.0)
                                          [ a ]
                                            | X.Y.27.129 (net X.Y.27.128)
   =============================================================
      | X.Y.2.1       | X.Y.2.2        | X.Y.2.65        | X.Y.27.130
    [ b ]           [ c ]            [ d ]             [ e ]
   
The lower cable contains 3 logical subnets, X.Y.2.0, X.Y.2.64, X.Y.27.128.
The nodes in X.Y.27.128 work fine. We are trying to get the nodes in X.Y.2.0
and X.Y.2.64 to talk to the 3 logical subnets on the lower cable, with a 
default route to X.Y.27.129 for eveything else. In X.Y.2.0 and X.Y.2.64, the
nodes have the following statements:

ifconfig ie0 'hostname' netmask 255.255.255.192

route add net X.Y.2.0 'hostname' 0
route add net X.Y.2.64 'hostname' 0
route add net X.Y.27.128 'hostname' 0
route add net default X.Y.27.129 1

When the default route is entered, we get "Network is unreachable", but yet
we can telnet to X.Y.27.129 okay. 
The nodes in X.Y.2.0 and X.Y.2.64 are running Sun OS 4.0. Can anyone shed some
light on this? I suspect that if all node addresses were changed to be within
subnet X.Y.27.128, things would work fine, and that's just what we'll do if
the above arrangement won't work.

BTW, what should the broadcast address for nodes in X.Y.2.0 and X.Y.2.64 be?
We left if out of the ifconfig, and noticed it defaults to X.Y.2.0 on node
X.Y.2.1. I would have expected it to default to X.Y.2.63 (highest addr. within
that subnet)

Any info would be greatly appreciated
-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      24 Mar 90 19:33:16 GMT
From:      intercon!news@uunet.uu.net  (Amanda Walker)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Consider IMAP instead of POP
In article <325@spt.entity.com>, gz@spt.entity.com (Gail Zacharias) writes:
> There is one thing that IMAP understands that POP doesn't, and that is that I
> want to KEEP MY MAIL ON THE SERVER.  I don't want to delete it from the server
> just because I'm reading it on a mac!

This depends some on the POP client, though... at least one (ours :-)) lets
you select whether you want to acknowledge with ACKD (which deletes the
message from the server) and ACKS (which keeps ("saves") it in your mailbox
on the server).

IMAP2 does look like a good compromise between the bare simplicity of POP
and the almost OSI-grade complexitude of PCMAIL, though :-).

--
Amanda Walker
InterCon Systems Corporation

"Dans la vie y'a des hauts pis des bas,
des choses qui sont et d'autres qui ne sont pas."
	--Lucie Blue Tremblay
-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 90 03:57:19 GMT
From:      cucstud!tfd!kent@uunet.uu.net  (Kent Hauser)
To:        tcp-ip@nic.ddn.mil
Subject:   Help: NFS Mounts over `slip' not working

I'm having trouble implementing a bad idea -- I can't get
NFS mounts to work over a slip link.

Here's the setup -- SunOS 3.5, with the 4.3BSD TCP, IP & SLIP 
distributions installed.  Slip is running between the `ttya' ports
of two Sun 3/60's.  `ping', `rlogin', etc works fine, but a NFS
mount results in ``server not responding: RPC Timed Out''.

Any thoughts ?



-- 
Kent Hauser			UUCP: {uunet, sun!sundc}!tfd!kent
Twenty-First Designs		INET: kent@tfd.uu.net
-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 90 06:43:05 GMT
From:      zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!usc!elroy.jpl.nasa.gov!suned1!efb@tut.cis.ohio-state.edu  (Everett F. Batey II)
To:        tcp-ip@nic.ddn.mil
Subject:   NET TIME

Would appreciate pointers to a newsgroup, mail-list or persons in the
net time project.  Thank you /Ev/.

-- 
   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  
-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 90 06:48:57 GMT
From:      zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!usc!elroy.jpl.nasa.gov!suned1!efb@tut.cis.ohio-state.edu  (Everett F. Batey II)
To:        tcp-ip@nic.ddn.mil
Subject:   Suns and Ether number changing
Interested to hear any comments from anyone who has installed DECnet
compatible code on Suns which required altering the ethernet number to 
the DEC+area.node number.  Any risks or bad experiences.  We are a 192
hidden Class C net off MILNET and route all over.  Do we risk confusing
the outside world with ethers that may be the same as other Internet 
hosts DECprefix+area.node ether values ?  Risk going to lunch for fooling
with the numbers ?  Prefer not to mention the product we are contemplating 
trying.  Dont imagine it is possible to talk decnet or lat without messing
the ehter number ???


-- 
   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  
-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      Sun, 25 Mar 90 19:10:29 -0500
From:      enger@sccgate.scc.com ( Robert M. Enger)
To:        pollux!ccruss@ucdavis.ucdavis.edu, tcp-ip@nic.ddn.mil
Cc:        martyne@chumley.tn.cornell.edu
Subject:   Re:  High Schools on the Internet
Russ:

At the next IETF meeting you might wish to take a moment to speak
with Martyne Hallgren of Cornell.  She is in the process of putting
a number of high schools onto the Internet.

Bob
-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 90 13:21:24 GMT
From:      zaphod.mps.ohio-state.edu!sunybcs!ubvms!v093qqqh@tut.cis.ohio-state.edu
To:        tcp-ip@nic.ddn.mil
Subject:   How to Email to USMA?????
I recently recieved an e-mail message from a cadet at West Point.
I tried to reply and was unable to.Does anyone have any ideas on
how I can get E-mail to him? Even he admitted that it was hard 
for him to get E-mail out. Why all the difficulty?


							Thanks
						     
                                                     John Raftery  
-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 90 22:24:58 PST (Sun)
From:      dab@asylum.sf.ca.us (Dave Bridgham)
To:        naftoli@aecom.yu.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Broadcasting Adreess and Subnets
   Date: 23 Mar 90 15:49:23 GMT
   From: naftoli@aecom.UUCP  (Robert N. Berlinger)
   Organization: Albert Einstein College of Medicine, NY

   Which RFC would explain the proper way to configure broadcast
   addresses when using subnets?  For example, for a class B address, 8-bit
   subnet on subnet 1, would the broadcast address be XXX.XXX.255.255
   or XXX.XXX.1.255?

XXX.XXX.255.255	- Broadcast this packet on the network XXX.XXX.0.0.
		  If this requires forwarding the packet through gateways
		  and rebroadcasting to hit all of XXX.XXX.0.0 then the
		  gateways should do this (most don't and that's
		  probably for the best).

XXX.XXX.1.255	- Broadcast this packet on the subnet XXX.XXX.1.0.
		  How most machines I've seen are configured.

255.255.255.255	- Broadcast this packet on the wire this host is
		  attached to.  Probably the best broadcast address
		  but not as commonly used so you may find those who
		  don't understand.  Also has a problem that if an
		  application sends to this address, a multi-homed
		  host is left in the dark as to which interface it
		  should broadcast the packet out.


						David Bridgham
-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      25 Mar 90 17:54:55 GMT
From:      zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!news-server.csri.toronto.edu!clyde.concordia.ca!s3!lamarche@tut.cis.ohio-state.edu  (Louis Lamarche)
To:        tcp-ip@nic.ddn.mil
Subject:   Point-to-point protocol (PPP)

In UnixWorld of April 1990 (vol VII, No 4) page 85 Howard Baldwin writes:

 "Point-to-point protocol (PPP) has just been submitted to the CCITT from
  the Internet Engineering Task Force. It specifies a standard for encap-
  sulating Internet Protocol data  and other network layer (level three on
  ISO's OSI Model) protocole information over point-to-point links; it
  also provides ways to test and configure lines and the upper level proto-
  cols on th OSI Model. The only requirement is a provision of a duplex cir-
  cuit either dedicated or switched, that can operate in either an asyn-
  chronous or synchronous mode, transparent to the data-link layer frame.
 
  According to Michael Ballard, director of network systems fot Telebit,
  PPP is a direct improvement upon Serial Line Internet Protocol (SLIP),
  which had neither error correction nor a way to exchange network address."

----

1) Since we are very interrested in standards in this area, could someone
   tell me were I can find more information on PPP? 

2) Can this protocol be used in other fields than for the Internet
   (ex. telecontrol, telemetering) where we see a profusion of proprietary
   incompatible and hard to maintain point-to-point protocols?
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Louis Lamarche, IREQ |       lamarche@ireq.hydro.qc.ca
| CP 1000, Varennes    |                 or
| QC, Canada, J3X 1S1  |  514-652-8077 (office)  514-324-2919 (home)
-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Mar 90 07:55:31 EST
From:      "Phillip G. Gross" <pgross@NRI.Reston.VA.US>
To:        lamarche@ireq.hydro.qc.ca
Cc:        tcp-ip@nic.ddn.mil, rdhobby@ucdavis.edu, pgross@NRI.Reston.VA.US
Subject:   PPP Info
Louis,

PPP was designed to be useful for many protocols besides just IP.  Whether
it would be useful for your particularly application should probably be 
discussed with the current chair of the IETF PPP Working Group (Russ Hobby,
UC Davis).  I will include him as a cc on this message, with a copy of your 
message below.

The PPP specification is available as RFC1134, and a PPP options 
specification is available in the Internet-Drafts directories as file 
DRAFT-IETF-PPP-OPTIONS-01.TXT.  If you have trouble retrieving either 
document, please feel free to contact Monica Hart (mhart@nri.reston.va.us) 
or Greg Vaudreuil (gvaudre@nri.reston.va.us) for assistance.

Thanks for your interest in PPP.

Phill Gross, IETF Chair
Corporation for National Research Initiatives


	
Date: 25 Mar 90 17:54:55 GMT
To: tcp-ip@nic.ddn.mil
Subject: Point-to-point protocol (PPP)

In UnixWorld of April 1990 (vol VII, No 4) page 85 Howard Baldwin writes:

 "Point-to-point protocol (PPP) has just been submitted to the CCITT from
  the Internet Engineering Task Force. It specifies a standard for encap-
  sulating Internet Protocol data  and other network layer (level three on
  ISO's OSI Model) protocole information over point-to-point links; it
  also provides ways to test and configure lines and the upper level proto-
  cols on th OSI Model. The only requirement is a provision of a duplex cir-
  cuit either dedicated or switched, that can operate in either an asyn-
  chronous or synchronous mode, transparent to the data-link layer frame.
 
  According to Michael Ballard, director of network systems fot Telebit,
  PPP is a direct improvement upon Serial Line Internet Protocol (SLIP),
  which had neither error correction nor a way to exchange network address."

----
1) Since we are very interrested in standards in this area, could someone
   tell me were I can find more information on PPP? 

2) Can this protocol be used in other fields than for the Internet
   (ex. telecontrol, telemetering) where we see a profusion of proprietary
   incompatible and hard to maintain point-to-point protocols?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Louis Lamarche, IREQ |       lamarche@ireq.hydro.qc.ca
| CP 1000, Varennes    |                 or
| QC, Canada, J3X 1S1  |  514-652-8077 (office)  514-324-2919 (home)
-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Mar 90 08:09:37 EST
From:      Mark Bodenstein <MAB@CORNELLC.cit.cornell.edu>
To:        TCP-IP@NIC.DDN.MIL
Subject:   Single domain name/IP address for a group of hosts
We are considering the idea of having a group of front-end machines, each
with its own domain name and IP address, be known to the outside world by
a single domain name and/or IP address.  This would allow us to publish
the single name and/or address to our users, rather than telling them
to try one of a list, and depending on the implementation might allow for
reasonable load balancing.

If you have done this, or have ideas on this topic, please let me know;
I will summarize to the list.

Also, I remember vaguely having heard that there is a TELNET option that
would allow a TELNET server to tell a TELNET client to connect to another
TELNET server, i.e. pass the session on to another server.  Anyone know
of such a beast?

Thanks in advance for your help.

Mark Bodenstein   (mab@cornellc.cit.cornell.edu; 607-255-3747)
Cornell University
-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Mar 90 11:58:52 -0500
From:      crocker@TIS.COM
To:        IETF@isi.edu, us-wg@nnsc.nsf.net, tcp-ip@nic.ddn.mil, spwg@nri.reston.va.us, privacy-tf@venera.isi.edu
Cc:        iesg@nri.reston.va.us, iab@nri.reston.va.us, rdp@sei.cmu.edu, jkrey@isi.edu, ph@sei.cmu.edu, crocker@TIS.COM, Craig Partridge <craig@nnsc.nsf.net>
Subject:   Announcing Site Security Policy Handbook Working Group (SSPHWG)

A new working group has just been formed and will be meeting at the
next IETF Meeting in Pittsburgh:

Site Security Policy Handbook Working Group (SSPHWG)

Co-Chairs:

        Paul Holbrook/CERT ph@SEI.CMU.EDU
        Joyce K. Reynolds/USC-ISI jkrey@ISI.EDU

Mailing lists:

	General discussion: ssphwg@cert.sei.cmu.edu
        To subscribe: ssphwg-request@cert.sei.cmu.edu

Description of Working Group:
	
	The Site Security Policy Handbook Working Group is chartered
	to create a handbook that will help sites develop their own
	site-specific policies and procedures to deal with computer
 	security problems and their prevention.

Objectives:

Among the issues to be considered in this group are:

    1) Establishing official site policy on computer security.
    
    2) Establishing procedures to prevent security problems.
    
    3) Establishing procedures to use when unauthorized activity
       occurs.
    
    4) Establishing post-incident procedures.

A specific schedule of activities will be worked out in the near
future.  This group will meet at the next IETF meeting, in Pittsburgh.

The formation of this group provided an excellent opportunity for
cooperation between areas within the new IESG structure.  The User
Services director (Craig Partridge) and the Security Area director
(Steve Crocker) joined together to support the formation of this
working group.  After some discussion, it was agreed to place
administrative responsibility for this group within the security area, 
but the work will be reported to and reviewed by both areas in
parallel.

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Mar 90 09:35:03 EST
From:      stine@sparta.com (Robert Havens Stine)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Management Tools
 > This is a request.  About a couple of months back some kind soul had
 > posted that a document(in ps) called "A Draft Network Management Tool Catalog:
 > Tools for Monitoring and Debugging TCP/IP Internets and Interconnected
 > Devices" was available by anonymous FTP.  I have only a part of the 
 > document with me, and unfortunately forgotten the address of the node
 > from which I got it.

I've been called alot of things in my life, but this is a first for "kind
soul."  :-)

The latest draft of the catalog, dated March 90, is available via
anonymous FTP from hosts NIC.DDN.MIL, NNSC.NSF.NET, and
NARNIA.SAIC.COM, with filename

      draft-ietf-noctools-debugging-05,

and extensions .ps, .ms, and .txt for postscript, nroff -ms, and ascii
versions, respectively.

When FTP'ing from the NIC you change directory (cd) to

      internet-drafts:

(note the semicolon in "internet-drafts:")

When FTP'ing from NNSC you change directory (cd) to 

     internet-drafts

(No semicolon).

When FTP'ing from NARNIA, change directory to

     pub


If you have any problems, please contact me.  I'd be glad to email you
a copy (please specify your preference for postscript or straight-ascii
text).

- Bob Stine
  stine@sparta.com
-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Mar 90 16:10:47 -0500
From:      List Master <pem-dev-request@TIS.COM>
To:        tcp-ip@nic.ddn.mil
Subject:   Announcing PEM-DEV mailing list
A new mailing list, PEM-DEV, has been created for discussions related
to the development and deployment of Privacy Enhanced Mail systems
based on Internet RFCs 1113, 1114, and 1115.

RFC 1113 specifies protocol extensions and processing procedures for
cryptographic-based message encipherment and authentication for
Internet electronic mail.  RFC 1114 specifies a supporting key
management architecture and infrastructure, based on public key
certificates.  The key management architecure is compatible with the
authentication framework described in CCITT X.509.  RFC 1115 describes
algorithm and related information relevant to the other RFCs.

TIS, BBNCC, RSADSI and NIST are jointly developing RFC-compliant
software for deployment in the Internet in order to encourage the use
and development of RFC-based privacy enhanced mail systems.  Beta
testing of the software will occur this spring and release to the full
Internet is anticipated this summer.

The PEM-DEV mailing list is intended to cover a wide range of issues
including:

o       Issues related to the protocol extensions and message processing
	procedures and the key management architecture and infrastructure
	specified in the RFCs, including questions/answers, clarification
	of details, unpublished changes, etc.

o       Issues related to the development and deployment of privacy
	enhanced mail systems, including technical issues, development
	status, availability, etc.

Please send contributions to the list proper to "pem-dev@tis.com".
Administrivia, e.g., additions to or deletions from the list, should be
sent to "pem-dev-request@tis.com".

David Balenson <pem-dev-request@tis.com>

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 90 07:58:37 GMT
From:      mtxinu!rtech!wrs!hwajin@ucbvax.Berkeley.EDU  (Hwa Jin Bae)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Help: NFS Mounts over `slip' not working
In article <1807@tfd.UUCP> kent@tfd.UUCP (Kent Hauser) writes:
>Here's the setup -- SunOS 3.5, with the 4.3BSD TCP, IP & SLIP 
>distributions installed.  Slip is running between the `ttya' ports
>of two Sun 3/60's.  `ping', `rlogin', etc works fine, but a NFS
>mount results in ``server not responding: RPC Timed Out''.
>
>Any thoughts ?

SunOS 3.5 turns the UDP checksum off, which is legal and works okay
over interfaces such as ethernet which has link-level checksumming.
On the other hand, SLIP doesn't perform checksums thus running NFS
over SLIP requires you to turn the UDP checksum on.  Otherwise, you'll
experience erratic behavior such as the one described above.

Save the older kernel and try,

% adb -k -w /vmunix /dev/kmem
udpcksum?w 1

to patch up the kernel.
-- 
hwajin@wrs.com
-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Mar 90 13:39:26 EST
From:      Doug Nelson <08071TCP%MSU.BITNET@CORNELLC.cit.cornell.edu>
To:        "TCP/IP list (plus more)" <tcp-ip@nic.ddn.mil>
Subject:   Re: Internet break-in in the news
>Am I the only one left from the "old type" hacker school, when the
>term "hacker" only meant someone who liked to play with and inside
>computers, not "computer criminal!"
>
>I guess I'm just angry at the media taking the term }hacker" and using it
>in a derogatory manner.
>
>Pardon the flame, but...isn't there any of us left ?

There's a few of us left.  However, I suspect we've lost the battle with
the media on the use of the term "hacker".  I, too, would prefer to see
"computer criminals" labeled as such.

Doug Nelson
Network Software Manager
Michigan State University
-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 90 13:09:37 GMT
From:      MAB@CORNELLC.CIT.CORNELL.EDU (Mark Bodenstein)
To:        comp.protocols.tcp-ip
Subject:   Single domain name/IP address for a group of hosts

We are considering the idea of having a group of front-end machines, each
with its own domain name and IP address, be known to the outside world by
a single domain name and/or IP address.  This would allow us to publish
the single name and/or address to our users, rather than telling them
to try one of a list, and depending on the implementation might allow for
reasonable load balancing.

If you have done this, or have ideas on this topic, please let me know;
I will summarize to the list.

Also, I remember vaguely having heard that there is a TELNET option that
would allow a TELNET server to tell a TELNET client to connect to another
TELNET server, i.e. pass the session on to another server.  Anyone know
of such a beast?

Thanks in advance for your help.

Mark Bodenstein   (mab@cornellc.cit.cornell.edu; 607-255-3747)
Cornell University

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 90 21:50:05 PST (Mon)
From:      dab@asylum.sf.ca.us (Dave Bridgham)
To:        mcc@wlv.imsd.contel.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Broadcasting Adreess and Subnets
I agree that having 255.255.255.255 mean send this packet to all hosts
on all networks is a stupendously bad idea.  I don't recall ever
seeing that even jokingly proposed by anyone.  [Actually I think that
being able to send a broadcast to all subnets of a network is a bad
idea but fortunately I've not noticed anyone trying to push protocols
that depend on it.]

Since 255.255.255.255 wasn't going to mean all hosts everywhere, it
was defined to mean the one thing that broadcasts are maybe useful for
anyway; broadcast on the local wire, whatever it is.  My copy of the
RFC index doesn't list 919 and 922 as having been obseleted by
anything but if this part has been abolished since then, it might be
good to bring it back.  Consider one of the few places where a
broadcast may be acceptable: bootp.  Since the machine trying to boot
doesn't know its address, how can it know which IP broadcast address
it should use?  In fact it really doesn't care, it just wants all the
hosts on it's directly connected wire to hear this packet and know
that is was broadcast.

The use of 0's in the net field is new to me.  It seems much less
useful.

					David Bridgham
-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Mon, 26 Mar 90 13:54:29 GMT
From:      Mills@udel.edu
To:        "Everett F. Batey II" <zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!usc!elroy.jpl.nasa.gov!suned1!efb@tut.cis.ohio-state.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  NET TIME
Ev,

Network time buzzards have been known to perch on the ntp@trantor.umd.edu
wire.

Dave
-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 90 14:52:09 GMT
From:      snorkelwacker!ira.uka.de!smurf!gopnbg!altger!hnt@tut.cis.ohio-state.edu  (Michael Hentrich)
To:        tcp-ip@nic.ddn.mil
Subject:   Multiple Internet adresses???
Hi,

I hope you can help me a little out of an obvious misunderstanding.

I want my main host to understand 2 different Internet addresses
for the same host.  To configure the named-bind is not the problem,
my problem started, if it gets packages for the second address.

I'm unable to tell him (via route(C) ) that he should recognize
the second one. It always takes interface lo0. At boot-time he 
configures the en0 with the first address.

Do I need an 'en1' Interface, and if yes how to create?

Has anyone of you already slved this problem???

I'm using an Altos2000 with Altos System V.3.d (it's an 
System V.3.1 with TCP/IP (Streams) )

Thanks in advance

Michael
----------------------------------------------------------------------
Michael Hentrich       c/o  Altos Computer Systems GmbH,Wuermstr.55
                            D-8032 Graefelfing/Munich Western Germany
Voice:       +49 89 85484 40 
Internet: hnt%altger.Altos.COM Sub:  hnt@altger.alt.sub.org
Bang: ..!uunet!{altos|unido}!altger!hnt
-------------------------------------------------------------------------------
-- 
Michael Hentrich c/o Altos Computer Systems GmbH Wuermstr.55
	D-8032 Graefelfing/Munich Western Germany Voice:+49898548440 
E-Mail: hnt%altger.altos.com bang:..!uunet!unido!altger!hnt
-------------------------------------------------------------------------------
-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 90 15:06:48 GMT
From:      mcsun!cernvax!chx400!ethz!lubich@uunet.uu.net  (Hannes Lubich)
To:        tcp-ip@nic.ddn.mil
Subject:   Routing Algorithms Wanted
Hi,
for educational purposes I'm looking for example implementations of several
routing algorithms in C or Pascal. I've already got Dijkstra's label algorithm
(about 90 lines of code for the algorithm and surrounding main()) and I'm 
especially looking for implementations of Bellman-Ford and Floyd-Warshall 
(both shortest path ones as well) and for implementations of other routing 
strategies like bifurcated routing.
Anybody ever coded these in a short example program?
Thanks & CHeers
	--HaL
-- 
~ UUCP/Usenet 	       : {known world}!mcvax!cernvax!ethz!lubich
~ or                   : lubich@ethz.uucp
~ CSNET/ARPA/BITNET    : lubich@inf.ethz.ch / lubich%inf.ethz.ch@relay.cs.net
~ The usual disclaimer : No, it wasn't me, somebody must have used my account.
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 90 16:39:07 GMT
From:      fciva!dag@uunet.uu.net  (Daniel A. Graifer)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP for AT&T V/386
In article <9840@netcom.UUCP> jbreeden@netcom.uucp (John Breeden) writes:
>Does anyone know of an IP package for AT&T's SysV/386 R3.2.2 that supports 
>ia SLIP interface?
>

We have Prime EXLs (386 Multibus II machines) running Prime's release of 
ATT Sys V3.1.2.  On this, Prime supplied TCP/IP software originally from
Spyder.  The implementation includes SLIP, X-25, uucp over other transport
layers than uucico, etc.  It will act as a gateway, and support multiple
ethernet controllers.  I saw that Spyder had a booth at the expo in DC last
January, so they do sell their software direct.  Unfortunately, I do not 
have a number for them.

Good luck
Dan
---
Daniel A. Graifer			Franklin Mortgage Capital Corporation
uunet!fciva!dag				7900 Westpark Drive, Suite A130
(703)448-3300				McLean, VA  22102
-- 
Daniel A. Graifer			Franklin Mortgage Capital Corporation
uunet!dag@fmccva.franklin.com		7900 Westpark Drive, Suite A130
(703)448-3300				McLean, VA  22102
-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 90 18:35:31 GMT
From:      zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!mahendo!wlbr!hacgate!janus!todd@tut.cis.ohio-state.edu  (todd)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: broadcast storm
In article <9003121734.AA22356@ISIS.U-STRASBG.FR>, pansiot@isis.u-strasbg.FR (Jean-Jacques Pansiot Departement d'Informatique writes:
> Anything I can do? (Stations B and C

One quick fix to your problem is to use one broadcast address on your
physical net.  This means all logical subnets should use the same broadcast
address.  For example you could use 0.0.255.255 as a broadcast address
for all hosts.  

If you must have multiple broadcast groups on one physical net, then *try*
having your vendors fix their software to conform to RFC1122, page 39.
"An ICMP error message MUST NOT be sent as the result of receiving: ...
a datagram sent as a link-layer broadcast..."  I've been told that the
BSD 4.3 link layer does not pass this broadcast info up to IP so the
vendor may have to implemnt some new code.

--todd
-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 90 18:39:26 GMT
From:      08071TCP@MSU.BITNET (Doug Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Internet break-in in the news

>Am I the only one left from the "old type" hacker school, when the
>term "hacker" only meant someone who liked to play with and inside
>computers, not "computer criminal!"
>
>I guess I'm just angry at the media taking the term }hacker" and using it
>in a derogatory manner.
>
>Pardon the flame, but...isn't there any of us left ?

There's a few of us left.  However, I suspect we've lost the battle with
the media on the use of the term "hacker".  I, too, would prefer to see
"computer criminals" labeled as such.

Doug Nelson
Network Software Manager
Michigan State University

-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 90 19:53:40 GMT
From:      ftp!fks@bloom-beacon.mit.edu  (Frances Selkirk)
To:        tcp-ip@nic.ddn.mil
Subject:   Searching for a document
Help! I'm looking for a document entitled, "Stable Implementation
Agreements for Open Systems Interconnection Protocols". This doesn't
seem to be a standard (whatever that means!) OSI document. It was,
but is no longer, available from the US Printing Office. Guesses, 
anybody?

		-Francie
-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      26 Mar 90 22:29:40 GMT
From:      ogicse!blake!Tomobiki-Cho!mrc@decwrl.dec.com  (Mark Crispin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Consider IMAP instead of POP
In article <Mar.23.17.05.19.1990.3706@turbo.bio.net> lear@turbo.bio.net (Eliot) writes:
>In IMAP, you've advertised as as a feature great server search
>facilities, and the fact that the server protects the client from as
>much state as possible. It would seem to me that such an approach
>would produce a bottleneck of server resources far faster than POP
>would.  In a large scale arena such as SUMEX, would it not be better
>to design a protocol where you assume that the free cycles will be on
>MANY client machines, rather than a few servers?  I suppose taken to
>extremes I should stick to FTP, but I would see where both POP and
>IMAP (and FTP) have their places...

That's easy to answer.

Searches in both the existing IMAP server implementations are quite
fast, both in CPU and real time.  The cost to the server host is
generally small, particularly if the search is done at the behest of a
human user.  CPU time has never been an important factor to IMAP
servers; it's been I/O time.

Many of the search criteria require trivial work -- a lookup in state
tables.  It would be more work to transmit the complete state tables
to the client (if the client does not already have them) than to do
the lookup and report the results.  Of course, a smart client could
use save the server this work by looking up in local state tables, but
that would preclude the possibility of the state being changed
asynchronously by another agent without announcement to the client.

The searching that requires work -- envelope parsing, free text
searches, etc. -- also require tranmittal of the text to the client.
There's a lot of work involved in doing that.  Some clients don't have
the physical resources to handle mega-mailboxes.  We have users who
regularly allow their IMAP mailboxes to grow to thousands of messages
because the "transmit only on demand" aspect of IMAP greatly reduces
the real-time cost in using such large mailboxes.

Furthermore, many networks are not up to the task of tranmitting such
large amounts of data in a reasonable timeframe.  Ever do much Milnet
data transfer lately?  IMAP scales very well to adverse network
conditions.  I regularly read mailboxes on IMAP-accessible hosts that
are too painful to use via Telnet under normal conditions.

There's another reason why I feel this is undesirable; the more RFC822
or search parsing implementations there are, the more differences
there are between the behaviors of these implementations.

 _____     ____ ---+---   /-\   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!"
-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 90 00:48:42 GMT
From:      noose.ecn.purdue.edu!mentor.cc.purdue.edu!dls@iuvax.cs.indiana.edu  (David L Stevens)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP II: The Saga Continues...

	I'm working with Doug Comer to update his book "Internetworking With
TCP/IP."  The revision will include two volumes (expected release late '90
or early '91). Along with this revision, we will update the cover, which you may
recall is a map of the United States with points representing nodes on
the Internet.

	If you'd like your site to be represented on the cover of the second
edition, send us electronic mail that specifies the geographic location
of your site.  Please use a geographic name that we can find in an atlas,
instead of postal addresses that do not correspond to identifiable places.
For example, "State College, PA" (the town) is better than "University Park,
PA" (the university postal address).  Mail entries to:

			tcpbook@purdue.edu

	If you are on the connected Internet (e.g., NSFnet), the subject line
of your mail should be in the form:

		Subject: YourCity, YourState, CONNECTED

	If your site uses TCP/IP but does not have full connectivity (e.g.,
a corporate or campus internet with a mail bridge only), the subject should
be in the form:

		Subject: YourCity, YourState, NOTCONNECTED

	If you are unsure about full connectivity, check with your local guru,
or see if you can ping a machine on the Internet (e.g., try 128.10.2.1).
	Because of the volume we expect, mail with subject lines not following
this form will be discarded.  Also, the body of messages will be ignored.

EXAMPLE

   The entry for Purdue University would have a subject line:

		Subject: West Lafayette, IN, CONNECTED

-- 
				+-DLS (dls@purdue.edu)
				David L Stevens,
				Internetworking Research Group at Purdue
-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 90 02:34:59 GMT
From:      pluto!smiddy@nyu.edu  (Rich Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: CMOT Implementations

It is about time people stood up and said that OSI is MUCH too complex.
"Simple" implementations (i.e. applications I can run on my 386) will
probably be quite rare and expensive.  This does not help the cause of
the common person with a computer, or the inventor who wishes to
place simple devices on a network.  I have felt for some time that
improving TCP/IP is a better thing to do.  My current picture of a "good"
protocol stack is as follows:

			----------
			| New IP |
			----------
			     |
		    -------------------
		    |Security Layer   |
		    -------------------

	-----------	-------		------------
	| New TCP |	| UDP |		| Some RPC |
	-----------	-------		------------
					      |
		Presentation Layer	      |
					      |
			Application

This is still in the idea phase, but I simpler networking protocols are
definitely on my mind.

Smiddy
-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Mar 90 12:03:11 PST
From:      braden@venera.isi.edu
To:        barns@gateway.mitre.org
Cc:        braden@venera.isi.edu, nelson@clutx.clarkson.edu, tcp-ip@nic.ddn.mil
Subject:   Re: partial transfer recovery in RFC and OSI protocols

Bill,

I finally got around to reading your comments, and as usual you have
provided a technically correct and scholarly summary of the situation.
As a (former) representative of the Baroque file system school of
operating systems (OS/MVS), I agree with your summary of the pros and 
cons.

Historically, I don't think Alex McKenzie, who invented the RFC restart
mechanism, or anyone else in the Network Working Group, explored the RC
alternative.  Once we had one mechanism that solved the problem, we
stopped.  However, we did go through the arguments fairly thoroughly
about how to make the SC approach work.  The RFC restart protocol was 
implemented in the UCLA NCP, but probably never used in anger.

Bob Braden

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Mar 90 10:21:46 EST
From:      fab%saturn.ACC.COM@salt.acc.com (Fred Bohle acc_gnsc)
To:        lgpiers@sandia.gov, tcp-ip@nic.ddn.mil
Subject:   Re:  RFC 1072 Implementations Needed
>Message-Id: <9003200542.AA00921@saturn.acc.com>
>Date: 19 Mar 90 12:30:00 MST
>From: "2645 Pierson, Lyndon G." <lgpiers@sandia.gov>
>Subject: RFC 1072 Implementations Needed
>To: "tcp-ip" <tcp-ip@nic.ddn.mil>
>
>RFC 1072 represents a significant improvement in the performance 
>of TCP in communication environments with high delay-bandwidth product
>(geosynchronous satellite links at T1 and above) and moderate error rates.
>
>Does anyone know of a full implementation of TCP which incorporates
>the RFC 1072 window scaling, selective acknowledgements, and rtt
>estimator?  (or even a planned implementation?)
>
>L. G. Pierson (505)-845-8212,  LGPIERS@SANDIA.GOV
>
>

I am currently working on Window Scaling and Van Jacobson's rtt
estimator.  Do you also have a need for Selective Acknowlegements?
Please contact me directly for more information.

These enhancements will shortly be part of ACC'S ACCES/MVS R3.0,
no, no, I mean Interlink's SNS/TCPaccess R1.0.

Fred

------------------------------------------------------------------------
Fred Bohle			EMAIL: fab@saturn.acc.com
ACC (Interlink)			AT&T : 301-290-8100 
10220 Old Columbia Road
Columbia, MD 21046
------------------------------------------------------------------------

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 90 08:58:25 GMT
From:      snorkelwacker!ira.uka.de!fauern!tumuc!guug!pcsbst!@tut.cis.ohio-state.edu  (Rudi Wildgruber)
To:        tcp-ip@nic.ddn.mil
Subject:   Request for BOOTP server
I'm looking for the source code of a BOOTP server.
Are there any PD versions, that I can get via anonymous ftp or by uucp?

Please respond via E-mail to rw@pcsbst.pcs.com

Rudi Wildgruber, PCS Germany
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rudi Wildgruber                    PCS-Mail: rw
PCS Computer Systeme GmbH            DOMAIN: rw@pcsbst.pcs.com
D-8000 Muenchen 90                     UUCP: ...[unido,pyramid]!pcsbst!rw
-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Mar 90 15:29 CDT
From:      Larry Owen <OWEN@ducvax.auburn.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   RE: High Schools on the Internet
>During  the past six months UC Davis has been doing a joint project with
>Pacific  Bell and the Davis High School  to see how high school students
>can use the resources of the Internet. The connection to the high school
>consists  of a 56k link and router  to tie their local AppleTalk network
>to the Internet.
> 
>Some  of the uses have  been to tie into  various library card catalogs,
>obtaining  online  information  on  programs  and  requirements  at some
>colleges  and universities,  ftping software  from many  sites, and,  of
>course, reading USENET. In all it has been very rewarding.
> 
>Now  the question:  Are there  any other  high schools  connected to the
>Internet?  The Davis High students would like to share their experiences
>with  other  high  school  students  and  find  out  if  there are other
>resources  in which they  would be interested.  Perhaps we can  set up a
>mail  list or newsgroup for discussions. I think that it would be a real
>education  for  high  school  students  to  talk  to others in different
>environments  and share some of lifes problems and solutions experienced
>during  a particularly confusing  time in life.  (remember when you were
>that age? ;-)
 
The Alabama Supercomputer Network has some sort of grant to connect several
(5 or 6 in the first round) high schools to ASN.  ASN is a state-wide
T1-extended ethernet, supporting both TCP/IP and DECNET, and is connected
to both SURANET and SPAN.  I don't know what the nature of the link
between is between the ASN center and the high schools, so I can't say
for sure whether they are "on" the Internet, or just have access to
machine(s) on the Internet.  However, Bob Shaeffer is the network
manager at ASN, and could probably provide more info.  His address is
shaeffer@asncen.asn.net.

To date, I believe only one high school (Coffee County High) has actually
been connected.  All of the schools scheduled to be connected are in
North Alabama - reasonably close to Huntsville, where the ASN center is
located.  An article I read in Sunday's paper indicated they hope to
connect more schools with another grant, and these would be more
geographically dispersed.

Larry Owen
Mgr., Network Support
Auburn University

Bitnet:   owen@auducvax
Internet: owen@ducvax.auburn.edu
-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Mar 90 17:14:27 EST
From:      Scott W. Rogers <rogers@osi540sn.gsfc.nasa.gov>
To:        tcp-ip@nic.ddn.mil
Subject:   Wanted-Ethernet Packet Generator for SUN.
Help,	I need to create programs to do the following on a SUN-3
	running SunOS 4.0.3 and SunLINK OSI :
	(1)	Generate an ethernet packet (with a new type field)
		and transmit on a specified interface.
	(2)	Read and log ethernet packets with data on an interface
		(all packets, or all of a certain type) destined for
		that host (all hosts if in promiscous mode).

    I have looked at the NIT interface on the SUN, and found the manual
    pages and code snipets confusing.  I would rather do this using
    standard (raw?) socket calles as to make it more portable over BSD
    type platforms.  Any information, insight, code pieces, etc.  would
    be most appreciated.

    SUN's etherfind (or portion thereof) or etherd source would be most
    helpful, but is probally licenced restrictivly and therefore not
    available to me.			Thanks :)
------------------------------------------------------------------------
Scott Wayne Rogers	Internet: <rogers@osi540sn.GSFC.NASA.GOV>
Computer Sciences Corporation -- System Sciences Division.
4600 Powder Mill Road         -- Beltsville, MD 20705  (301) 572-8297
*NASA SEAS Contract/Code 540 - Goddard Space Flight Cntr - Greenbelt, MD*
------------------------------------------------------------------------
-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 90 14:01:44 GMT
From:      brunix!euclid!freedman@uunet.uu.net  (Avi Freedman)
To:        tcp-ip@nic.ddn.mil
Subject:   Diskless Sun Booter
Hi, I am faced with the following problem:  I can get a diskless Sun
3/50 for $2000, but I need disks for it.  A shoebox with a 150MB disk
costs $2500 (used!!!).  I've already got a 386 machine with Open
Desk Top (which has NFS and some socket libraries).  To the best of
my knowledge, the following things are needed to boot a diskless sun:

	o arpd/rarpd (so it can figure out its internet address)
	o tftpd (so it can get a boot program named its ethernet adx)
	o bootparamd (so it can figure out its root and swap filesystems)
	o nfs and co. 
	o rpc/xdr to make nfs work

So, I've got a few questions.  First, did I leave anything out from 
above (aside from having a legal copy of SunOS for it, which I can get
for $200).  Second, how easy would it be to get arp/rarp, tftp, and
bootparam ported to SCO Unix - can I get source for the daemons, will
the socket libraries on SCO work?)  Third, if I wanted to do a real
big favor to the world and come up with a "diskless sun booter box",
can I get source to nfs and rpc/xdr to roll my own?

(Oh, and the reason for all of this is that I want berkeley - otherwise, 
the 386 is fine)


			Thanks very much,
				Avi Freedman
				freedman@euclid.math.temple.edu
-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 90 14:58:49 GMT
From:      ateng!tct!chip@uunet.uu.net  (Chip Salzenberg)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Using SLIP with SCO Xenix/Unix
According to bill@polygen.UUCP (Bill Poitras):
>Does anyone know if there is a way to run a SLIP program on a IBM computer
>running SCO Xenix/Unix, with a multi-port serial board.

SCO TCP/IP for Xenix supports SLIP.  It works; I've used it.  However,
be warned: SCO SLIP works *only* with SCO serial drivers, so it will
*not* work with intelligent boards that come with their own drivers.
If you want lots of SLIP ports, you'll need lots of dumb ports,
perhaps with a multi-dumb-port board such as the one sold by Arnet.
-- 
Chip Salzenberg at ComDev/TCT   <chip%tct@ateng.com>, <uunet!ateng!tct!chip>
          "The Usenet, in a very real sense, does not exist."
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Mar 90 00:35 MST
From:      JOHNGALT@rvax.ccit.arizona.edu
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Using 3Com 503 Boards
From Geoffrey McKim:

> Have any of you out there had any experience using 3Com 503 boards on
> PS/2 Model 25's?  I've been trying to run NCSA Telnet on them for
> quite some time (with the Clarkson packet drivers v5 and 5A), and I've
> tried just about every IO Address and Shared Memory Address and Interrupt
> possible.  I seem to get a lockup every single time. (on different
> machines, on different branches of the Network, on both TP Ethernet and
> Thin Ethernet).

    We here at the University of Arizona have also had problems with the 3Com
3C503 cards in the model 25s.  Our problem has been with using remote reset
PROMs to connect the model 25s to Novell networks.  The 3C503 boards apparently
do not correctly initialize in the model 25s.  We can, however, disable the
shared memory and boot with a floppy and then manually log in to the network. 
I have spent a lot of time on the phone trying to iron this thing out. 
LANWORKS in Canada has been VERY helpful.  (They make the PROMs.)  3Com
apparently does not think that the model 25 is worth supporting.  Also, being a
Novell competitor, they do not make their own PROMs for Novell, so they point
at the PROMs as well.  Bottom line is that the boards are not acceptable in the
model 25s. (We have also had problems in other 8088 and 8086 machines as well.)

> Any ideas?

    Try disabling the memory.  In our case we couldn't do that, so we made our
vendor take the boards back and give us Western Digital 8003 boards.  (We had
specifically stated in our RFQ that whatever boards we received would have to
work in the model 25s.)  The WD board works fine and we will use them from now
on.

------------------------------------------------------------------------------
Internet: johngalt@rvax.ccit.arizona.edu
Bitnet:   johngalt@arizrvax

Wellington
Network Administrator
Instructional Computing
University of Arizona, Tucson
(602) 621-9482
------------------------------------------------------------------------------
    What...?  He's on the VAX...?  He's supposed to only do Novell!!!!!!! 
------------------------------------------------------------------------------
-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 90 18:17:56 GMT
From:      bu.edu!bu-it!kwe@bloom-beacon.mit.edu  (Kent England)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Broadcasting Addresses and Subnets
_______________

 RFC 1009 - Requirements for Internet Gateways                  June 1987

2.  Protocols Required in Gateways

   2.1.  Internet Protocol (IP)

  ...
        (c)   { -1, -1}

            Limited broadcast.  Can only be used as a destination
            address, and a datagram with this address must never be
            forwarded outside the (sub-)net of the source.

         (d)   {<Network-number>, -1}

            Directed broadcast to specified network.  Can only be used
            as a destination address.

         (e)   {<Network-number>, <Subnet-number>, -1}

            Directed broadcast to specified subnet.  Can only be used as
            a destination address.

         (f)   {<Network-number>, -1, -1}

           Directed broadcast to all subnets of specified subnetted
            network.  Can only be used as a destination address.
______________


Before you leap up and go off and implement something, you should
know that Phil Almquist is heading up a new Router Requirements
WG in the IETF to address needed updates.  I am pretty sure that
they intend to simplify the IP broadcast addressing for what should
be sent.  But for robustness you will need to accept all of the 
above forms.

	--Kent
-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      Tue, 27 Mar 90 23:44:07 EST
From:      (strick) <snstr@ttuvm2.ttu.edu>
To:        TCP-IP%SRI-NIC.ARPA@pucc.PRINCETON.EDU

>I have a question for you POP2 (RFC-937) experts. The RFC very clearly
>describes how a server delivers mail to a client and how a client gets
>mail from a server. However, there is no mention of how a client sends mail
>(SMTP, since this does not require a resident program?) or how a server
>receives mail to be delivered. Is there another RFC that describes this? What
>am I missing (bad copy of the RFC?)? If anyone has any information this
>inquiring mind wants to know. Thanks in advance.
>
the client is expected to send the mail directly to its destination.
the server only collects mail.

you can sometimes get the smtp server to deliver mail for you if you
code the address in the form: recipient%recipients-mailbox@smtphost
strick

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 90 18:57:20 GMT
From:      m2c!umvlsi!vishwana@husc6.harvard.edu  (Chidambaram Vishwanath)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Network Management Tools
In article <9003261435.AA01083@Fourier.sparta.com] stine@SPARTA.COM (Robert Havens Stine) writes:
]
] ] This is a request.  About a couple of months back some kind soul had
] ] posted that a document(in ps) called "A Draft Network Management Tool Catalog:
]
]The latest draft of the catalog, dated March 90, is available via
]anonymous FTP from hosts NIC.DDN.MIL, NNSC.NSF.NET, and

Thank you very much, Bob, and everybody else who took the trouble to
send me the information.  (Tried to e-mail greatful acks to all, but
our mailer had other ideas.)

				- Vishwanath.

]
]- Bob Stine
]  stine@sparta.com
-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 90 19:16:03 GMT
From:      van-bc!jtc@ucbvax.Berkeley.EDU  (J.T. Conklin)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Using SLIP with SCO Xenix/Unix
In article <260F7FA9.4661@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>SCO TCP/IP for Xenix supports SLIP.  It works; I've used it.  However,
>be warned: SCO SLIP works *only* with SCO serial drivers, so it will
>*not* work with intelligent boards that come with their own drivers.

Not true.  We use a Bell Tech HUB-6 card w/16550's and a driver developed
by Stuart Lynne for our SLIP link.  The driver was written before we had
SLIP, so I'm pretty sure nothing special had to be done to get it to work.

	--jtc
-- 
J.T. Conklin
	...!{uunet,ubc-cs}!van-bc!jtc, jtc@wimsey.bc.ca
-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 90 19:44:52 GMT
From:      netnews.upenn.edu!vax1.cc.lehigh.edu!vlsi3b15!lehi3b15!mludwig@rutgers.edu  (Mitchell Ludwig)
To:        tcp-ip@nic.ddn.mil
Subject:   Info on SLIP
Please don't mind the line noise...  Lousy conncection to my host.

I'm looking for information concerning SLIP for a VME-131 box running
system 5 ver 2.2.  We're looking to run SLIP to a local host over
a telebit trailblazer.  Anyone who can help would be considered a 
real nice and all around keen person and would earn my eternal gratitude.

So, anyone know of a place where I can get my hands on a 
copy of SLIP designed for my beastie here?

Please e-mail anyswers here and carbon copy them to my work address.

I thank you.

	Mitchel Ludwig
	mludwig@lehi3b15.csee.edu
	carbon copy to motown!xybion!ludwig

Danke.
-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 90 20:17:11 GMT
From:      stjohns@umd5.umd.edu  (Mike St. Johns)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: RFC 1072 Implementations Needed
In article <9003271521.AA09196@saturn.acc.com> fab@SATURN.ACC.COM (Fred Bohle acc_gnsc) writes:

   >
   >RFC 1072 represents a significant improvement in the performance 
   >of TCP in communication environments with high delay-bandwidth product
   >(geosynchronous satellite links at T1 and above) and moderate error rates.
   >
   >Does anyone know of a full implementation of TCP which incorporates
   >the RFC 1072 window scaling, selective acknowledgements, and rtt
   >estimator?  (or even a planned implementation?)
   >

   I am currently working on Window Scaling and Van Jacobson's rtt
   estimator.  Do you also have a need for Selective Acknowlegements?
   Please contact me directly for more information.

   Fred Bohle			EMAIL: fab@saturn.acc.com


The Internet Engineering Task Force is currently evaluating several
approaches to window scaling.  RFC1072 represents one of those
approaches.  If you are interested in this work, please send a note to
Craig Partridge (craig@nnsc.nsf.net).  

Mike
-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 90 20:29:00 GMT
From:      OWEN@DUCVAX.AUBURN.EDU (Larry Owen)
To:        comp.protocols.tcp-ip
Subject:   RE: High Schools on the Internet

>During  the past six months UC Davis has been doing a joint project with
>Pacific  Bell and the Davis High School  to see how high school students
>can use the resources of the Internet. The connection to the high school
>consists  of a 56k link and router  to tie their local AppleTalk network
>to the Internet.
> 
>Some  of the uses have  been to tie into  various library card catalogs,
>obtaining  online  information  on  programs  and  requirements  at some
>colleges  and universities,  ftping software  from many  sites, and,  of
>course, reading USENET. In all it has been very rewarding.
> 
>Now  the question:  Are there  any other  high schools  connected to the
>Internet?  The Davis High students would like to share their experiences
>with  other  high  school  students  and  find  out  if  there are other
>resources  in which they  would be interested.  Perhaps we can  set up a
>mail  list or newsgroup for discussions. I think that it would be a real
>education  for  high  school  students  to  talk  to others in different
>environments  and share some of lifes problems and solutions experienced
>during  a particularly confusing  time in life.  (remember when you were
>that age? ;-)
 
The Alabama Supercomputer Network has some sort of grant to connect several
(5 or 6 in the first round) high schools to ASN.  ASN is a state-wide
T1-extended ethernet, supporting both TCP/IP and DECNET, and is connected
to both SURANET and SPAN.  I don't know what the nature of the link
between is between the ASN center and the high schools, so I can't say
for sure whether they are "on" the Internet, or just have access to
machine(s) on the Internet.  However, Bob Shaeffer is the network
manager at ASN, and could probably provide more info.  His address is
shaeffer@asncen.asn.net.

To date, I believe only one high school (Coffee County High) has actually
been connected.  All of the schools scheduled to be connected are in
North Alabama - reasonably close to Huntsville, where the ASN center is
located.  An article I read in Sunday's paper indicated they hope to
connect more schools with another grant, and these would be more
geographically dispersed.

Larry Owen
Mgr., Network Support
Auburn University

Bitnet:   owen@auducvax
Internet: owen@ducvax.auburn.edu

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 90 22:36:02 GMT
From:      sgi!vic%wookie.wpd.sgi.com@ucbvax.Berkeley.EDU  (Victor Mitnick)
To:        tcp-ip@nic.ddn.mil
Subject:   Do you use telnet commands in tn3270?

I have a question for all of you out there running tn3270 on any platform.
Do you use the telnet commands in tn3270 other than open, close and quit?
Specifically, I'm talking about the following commands and/or features:
	- send (escape, synch, break, etc.)
	- toggle (localchars, autoflush, etc.)
	- set (echo, escape, interrupt, etc.)
	- mode (line by line vs. character at a time)
	- socket level tracing
	- transparent mode command (transcom)
	- trace network data.

Your response is greatly appreciated.

	Thanks.

--
Vic Mitnick                           Silicon Graphics, Inc.
vic@wookie.wpd.sgi.com                System Software Division
(415)335-1372
-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      27 Mar 90 23:37:27 GMT
From:      samsung!usc!jarthur!petunia!polyslo!rnicovic@think.com  (Ralph Nicovich)
To:        tcp-ip@nic.ddn.mil
Subject:   Problems with AIX "illegal protocols" ?

I have run into a problem with using IBM's AIX on our campus-wide
network. I am posting here to see if anyone may have insight as to
what this problem is. Thanks to the feature of "filters" that Ungermann
Bass Bridges have, my network is now operational, but it is a patch
and not a fix.

It appears that we have narrowed down the problem where the AIX machines
would crash the HP-9000's and perhaps other machines on campus.

To date this problem has only been confirmed when the AIX machines have
both token-ring and ethernet interfaces, and there are more that 1
AIX machine connected to both these networks. I personally believe that
it is not a token-ring problem persay but the fact the each machine is
connected to two separate subnets. I believe the same scenario would
occur with two ethernets.

I can Identify the exact "IP PROTOCOL TYPE" that causes the HP's to
crash. It is 0x5b (hex) this "type" is not defined in RFC-1010 which
I believe is the current official document defining "IP PROTOCOL TYPES".
The AIX machines also send several other "types" which are also
undefined, but they at this time do not seem to cause the same problem.

To allow the AIX machines to work, without crashing the HP's I installed
a filter on the Ungerman Bass Data Link Bridge that blocks all
"types" which are undefined according to the RFC (types 0x50 thru 0xfe).
This should protect the HP's from any other illegal types that we may
not have found yet.

We have only observed the "killer" packet it in this special case,
but they could easily occur for other reasons since we do not know what
they are used for.

Our setup uses PC "clusters (TCF)" and a 3090 mainframe all on the
token ring. All PC's (not 3090) are also on the ethernet. The 
ethernet and token ring do have diferent subnet "mask". The "killer"
packet occurs when any of the PC's are either enabled or disabled
(using ifconfig). The "killer" does not come from the machine being
cycled, but one (or all) of the others. Just by looking at the data
in the pcaket it looks to have a list of addresses in it, somewhat
like a route broadcast packet (EGP ?).

Does anyone know what this new "IP PROTOCOL" is and what it is used
for ?

Any help would be apreciated.
Ralph Nicovich
Network Engineering
Cal Poly State University
 
-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Mar 90 06:36:17 EST
From:      perry@MCL.Unisys.COM (Dennis Perry)
To:        pollux!ccruss@ucdavis.ucdavis.edu, tcp-ip@nic.ddn.mil
Cc:        perry@mcl.unisys.com
Subject:   Re:  High Schools on the Internet
Russ, I am not certain if the Thomas Jefferson High School for Science
and Technology in Arlington VA is connected to the Internet or not, but
they do have and ETA-10, which they won in a competition called Superquest,
a national competition by high school programming teams.  They have
substantial other computer resources as well.  I know that a lot of
the kids who graduated last year keep in touch on the Internet now that
they are in college.

I suspect that unless the connection is free, high schools do not have
the resources to connect to the Internet.  Perhaps the NSF could fund
a special project to provide those connections?

dennis
-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 90 07:15:00 EST
From:      "VAXA::DBURKE" <dburke%vaxa.decnet@nusc-npt.navy.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   PC emulator under VMS
Date sent:  28-MAR-1990 07:19:09 

Hi,
	A question came up within our organization about a PC emulator that 
runs on a VAX.  Anyone care to forward experiences with "THEM".  If response 
warrents, I'll summarize for the net.

Dave
================================================================================
Dave Burke                                ||               ___________
Aquidneck Data Corporation                ||              //  ||     ||  
170 Enterprise Center                     ||             //   ||      ||  
Middletown, R.I. 02840                    ||            //    ||       ||  
dburke%vaxb.decnet@nusc-npt.navy.mil      ||           //-----||       ||  
(401) 847-7260                            ||          //      ||      ||
(This line left intentionally blank)      ||         //       ||_____||
================================================================================


-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      Wed 28 Mar 90 11:00:16-PST
From:      Alan Larson <LARSON@CRVAX.SRI.COM>
To:        tcp-ip@NIC.DDN.MIL
Subject:   re: MX Records
Craig asks:

	    Which of the following two cases are you proposing we stamp out?
	
	    (1) Mailers that never look for MX RRs?  [I think these folks
	    have plenty of incentive to fix this -- their mailers can't
	    get certain places otherwise].
	
	    (2) Mailers that follow RFC 974 and look for an A RR if an
	    MX RR doesn't exist. [There are folks who say this is a convenient
	    shorthand, that spares them the need to enter all those MX
	    RRs when they aren't needed].
	
Philip responds:

	The answer
	is the later.  I don't want mail coming to a host unless their
	is an MX record for it that points explicitly (and preferrably)
	at it...
	

Recently it was noted by Kevin Oberman that "Very few systems in the
world have MX records."  Even if this is not true, there are still a
large number of hosts that do not have MX records.

Even if MX records were required, the Robustness Principle would still
require a mailer to follow the current practice of using the A record
in the absence of an MX record.


Philip writes:

	The only time it should be possible to deliver mail to a host
	without an MX record is when it is done by the MXer of highest
	preference for that destination.

Suprisingly, it is a technical error for the MXer of highest preference
to not be the host itself.  This would result in an empty MX list after
removing irrelevant RRs in the MXer of highest preference.  This is an
error condition, although it is noted that "974 points out that "extremely
persistent mail systems might want to try a delivery to REMOTE's address..."


The present system provides for reasonable defaults, and reduces the
amount of information stored and transmitted in the DNS in common cases.
The current use of an A record implying an MX record is reasonable, and
should be retained.

	Alan Larson
-------

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 90 04:44:07 GMT
From:      snstr@TTUVM2.TTU.EDU (strick)
To:        comp.protocols.tcp-ip
Subject:   (none)


>I have a question for you POP2 (RFC-937) experts. The RFC very clearly
>describes how a server delivers mail to a client and how a client gets
>mail from a server. However, there is no mention of how a client sends mail
>(SMTP, since this does not require a resident program?) or how a server
>receives mail to be delivered. Is there another RFC that describes this? What
>am I missing (bad copy of the RFC?)? If anyone has any information this
>inquiring mind wants to know. Thanks in advance.
>
the client is expected to send the mail directly to its destination.
the server only collects mail.

you can sometimes get the smtp server to deliver mail for you if you
code the address in the form: recipient%recipients-mailbox@smtphost
strick

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 90 09:26:44 GMT
From:      eru!luth!sunic!mcsun!hp4nl!phigate!prle!prles2!prleh3!hooft@BLOOM-BEACON.MIT.EDU  (Peter van Hooft)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Problems with AIX "illegal protocols" ?
In article <260ff937.4167@polyslo.CalPoly.EDU> rnicovic@polyslo.CalPoly.EDU (Ralph Nicovich) writes:
$
$I have run into a problem with using IBM's AIX on our campus-wide
$network. I am posting here to see if anyone may have insight as to
$what this problem is. Thanks to the feature of "filters" that Ungermann
$Bass Bridges have, my network is now operational, but it is a patch
$and not a fix.
$
$It appears that we have narrowed down the problem where the AIX machines
$would crash the HP-9000's and perhaps other machines on campus.
$
[ ... ]
$I can Identify the exact "IP PROTOCOL TYPE" that causes the HP's to
$crash. It is 0x5b (hex) this "type" is not defined in RFC-1010 which
$I believe is the current official document defining "IP PROTOCOL TYPES".
[ ... ]
$Ralph Nicovich
$Network Engineering
$Cal Poly State University
$ 

You had an encounter with larp (Locus ARP). 
There is a patch for this problem (at least for HP-UX 6.5). It replaces 
the module ip_input.o in your liblan.a library. There is also a patch
for suns.

Hope this helps,

peter.
-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 90 12:15:00 GMT
From:      dburke%vaxa.decnet@NUSC-NPT.NAVY.MIL ("VAXA::DBURKE")
To:        comp.protocols.tcp-ip
Subject:   PC emulator under VMS

Date sent:  28-MAR-1990 07:19:09 

Hi,
	A question came up within our organization about a PC emulator that 
runs on a VAX.  Anyone care to forward experiences with "THEM".  If response 
warrents, I'll summarize for the net.

Dave
================================================================================
Dave Burke                                ||               ___________
Aquidneck Data Corporation                ||              //  ||     ||  
170 Enterprise Center                     ||             //   ||      ||  
Middletown, R.I. 02840                    ||            //    ||       ||  
dburke%vaxb.decnet@nusc-npt.navy.mil      ||           //-----||       ||  
(401) 847-7260                            ||          //      ||      ||
(This line left intentionally blank)      ||         //       ||_____||
================================================================================

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Mar 90 17:46:16 EST
From:      rizzo@ss1.eng.wayne.edu (Frank Rizzo)
To:        tcp-ip@nic.ddn.mil
Cc:        rizzo@ss1.eng.wayne.edu
Subject:   Please add me to your mailing list.

My name is Frank Rizzo, and I am one of the network managers
at the Engineering Computer Center at Wayne State University, Det. Mi.
Would you please add my name to your mailing list.  I am especially 
interested in any unshielded twisted pair information your group has to
offer as I am setting up a new subnet based on UPT technology.

================================================================================ Frank Rizzo                             Wayne State University                  Networking                              tel: (313) 577-3824                     Engineering Computer Center        Internet: rizzo@ss1.eng.wayne.edu           ================================================================================        
-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Mar 90 18:07:17 EST
From:      Frank Kastenholz <kasten%europa.interlan.com@RELAY.CS.NET>
To:        PADLIPSKY@A.ISI.EDU, schoff%psi.com@RELAY.CS.NET, tcp-ip@NIC.DDN.MIL
Subject:   Re: CMOT Implementations
PADLIPSKY@A.ISI.EDU Writes...

> So from the perspective of a maybe not all that hypothetical Z88-in-a-frig
> programmer, the style of protocol based on "from each according to his ability"
> would certainly seem to be more attractive than that of a protocol based on
> "from each according to OUR needs", even if, to bring in another analogy, you

and

> Afterthought:  Gee, if "Politics is the art of the possible" maybe the ISO
> isn't all that political after all.  (Or have I said that before?)

I'm afraid that I don't agree - ISO would be the most political - after all,
SNMP would be the Marxist Ideal - "From each according to his ability, to each
according to his needs" while CMIP/OT would represent the political reality 
as shown by the last 40+ years of history - "From each according to OUR needs,
to each according to OUR whims"

Happy Forthcoming April Fools Day
Frank Kastenholz

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 90 13:11:03 GMT
From:      pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!deakin.OZ.AU!ccw@tut.cis.ohio-state.edu  (Craig Warren)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Using SLIP with SCO Xenix/Unix
As an aside, has anyone got a PD dialup slip for SCO Xenix?
-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Mar 90 16:19:49 -0100
From:      Philippe Prindeville <philipp@Gipsi.Gipsi.Fr>
To:        craig@NNSC.NSF.NET
Cc:        TCP-IP <tcp-ip@nic.ddn.mil>
Subject:   re: MX Records
	    Which of the following two cases are you proposing we stamp out?
	
	    (1) Mailers that never look for MX RRs?  [I think these folks
	    have plenty of incentive to fix this -- their mailers can't
	    get certain places otherwise].
	
	    (2) Mailers that follow RFC 974 and look for an A RR if an
	    MX RR doesn't exist. [There are folks who say this is a convenient
	    shorthand, that spares them the need to enter all those MX
	    RRs when they aren't needed].

Sorry to take so long to respond (was out of town).  The answer
is the later.  I don't want mail coming to a host unless their
is an MX record for it that points explicitly (and preferrably)
at it...

The only time it should be possible to deliver mail to a host
without an MX record is when it is done by the MXer of highest
preference for that destination.

As for a short-hand, I would recommend revising the wildcard
to mean any existing leaf that does not have an MX record (not
the complete absence of RRs that is the current rule).

Of course, two such sudden (well, maybe not sudden) and drastic
changes would certainly cause all sorts of headaches...

-Philip
-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 90 15:16:31 GMT
From:      daffy!rt5.cs.wisc.edu!horn@speedy.wisc.edu  (Mark Horn)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP running on HPUX machines
In article <513@iconix.assco.oz.au> glf@iconix.assco.oz.au (Giuseppe Fiusco) writes:
>I am trying to locate a version of slip that will run on HP9000
>boxes running HPUX.
>
>I was wondering if anyone out there knows of the existance of such a beast.

ME TOO!! ME TOO!!

>Giuseppe Fiusco

Thanks,
- sparkie
--
 ___  ___  ___  ___  _  _  _  ___
/ __\| . \/ . \| . \| |/ /|_|| _ |  "Mothers Against Skunks Driving...
\___\| __/|   || _ /|   < | || _[    ...because stinking and driving don't mix"
\___/|_|  |_|_||_|\\|_|\_\|_||___|          - heard on a madison radio station
ARPA:	harier!sparkie@cs.wisc.edu, sparkie@uhura.cs.wisc.edu
UUCP:	...{harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!harier!sparkie
-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      Wed, 28 Mar 90 21:54:10 CST
From:      Frank W. Peters <peters@CC.MsState.Edu>
To:        snorkelwacker!usc!wuarchive!rex!srikanth@tut.cis.ohio-state.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  tftp,anonymous ftp
> From: snorkelwacker!usc!wuarchive!rex!srikanth@tut.cis.ohio-state.edu  (R Srikanth)
 
> I am interested in the security aspects of tftp. I am trying to find out
> why tftp exists, what it does exactly, and what are the security
> restrictions on it. Also I would like to know what is the difference
> between tftp and ftp (anonymous) in terms of the access to files on
> systems for which one does not have any authorization.

What it is
==========
In essence tftp is a one shot FTP with no userid authentication.  A user
(or more often, an automated process) sits on one system and requests a
file from another system using the TFTP protocol.  The server system then
decides whether to grant access to the file (and it has no userid or 
password information to decide this).  A similar proceedure is followed for
attempts to write a file.

Security
========
There is effectively no security defined in the protocol itself.  On a
Sun system (almost certainly on any system using 4.3 bsd networking) the
tftpd daemon is usually invoked with 'tftpd -s dirname'.  Dirname is the
name of a directory which the daemon attempts to cd to before processing
requests.

The -s option requests a secure mode in the daemon.  In this mode the 
cd to the directory given on the command line (or the default /tftpboot)
must succeed.  The daemon then does a chroot to that directory so that
no files not under that directory are accessible.

There are some additional security features turned on by -s:

- A file may only be read (gotten) by a remote machine if it has world
  read permissions (that is, if EVERYONE on the system can read it).

- A file may be written only if it already exists and is world writeable.
  So, a file cannot be created...only modified.  And it can only be
  modified if the permissions are such that ANY user can modifiy it.

What it is used for
===================
On a Sun system tftp is used by diskless workstations to download a
boot image from a server.  In addition may other types of dedicated
systems (such as terminal servers, network printers, routers and the
like) use it to download configuration information at startup time.

I don't know of any common use for the ability to write files with 
tftp.  There is absolutely no way to give write permission even a
semblance of security so I wouldn't recommend using it.

Comparison to anonymous FTP
===========================
FTP is typically implemented as an interactive protocol (although we
do have one system here that implements it as a one shot deal similar
to tftp).  You typically have the ability to 'log on' to the server,
move around through the directories and list the files available, get
collections of files and the like.  These abilities are basically 
lacking in tftp.  FTP is thus a much better protocol for users to use
(especially if you have several files to make available).  In fact,
I've never heard of anyone using tftp to give users (as opposed to 
processes) access to files.

TFTP is better suited to use by automated boot or initialization 
processes which don't need to write to any files and which don't
want to have any sensitive information in their initialization
files.


I hope this information is of some use.

--Frank

Frank W. Peters        Systems Programmer     Computing Center & Services
peters@CC.MsState.Edu  Peters@MsState.Bitnet  (601)325-2942
"I can't give you brains, but I can give you a diploma." -- The Wizard of OZ
-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 90 16:32:01 GMT
From:      hpfcso!hpldola!hpctdlb!hpctdlf!jeff@hplabs.hp.com  (Jeff Hughes)
To:        tcp-ip@nic.ddn.mil
Subject:   Broadcasted ARP's


   Are there any Sun gurus who can explain the operation of the PC-NFS
version of Telnet to me? It seems that when I login to my favorite
server from my PC, a series of ARP's are first generated. The first
ARP is trying to retrieve the hardware address of my server. This one
gets a response from the server and this makes sense to me.

   What happens next is somewhat of a mystery. The PC again sends out
an ARP packet with an IP subnet broadcast as the target IP address.
(e.g. xx.xx.xx.0). Noone on the network responds to this ARP so it
is retransmitted by my PC 3 more times. The question is: "Is my PC
attempting to build an address table for itself by forcing all 
hosts on the network to respond to a broadcast ARP?" Also, do hosts
really respond to ARP's with broadcast IP addresses? According to 
the ARP spec, they should only respond if the target address in the
ARP packet matches their own address. Finally, are the hosts on my
network failing to respond because they do not recognize the Berkely
convention of 0 as a broadcast IP address? Or is it because they just
aren't supposed to respond to broadcast ARPs?

   Any responses will be appreciated. Mail them to me directly if
you prefer....

jeff@hpctdlb.hp.com
-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 90 16:35:12 GMT
From:      oliveb!tymix!sagehen!drawson@apple.com  (Dick Rawson)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Searching for a document

You want to order
  Stable Implementation Agreements for Open Systems Interconnection 
  Protocols.  Version 2, Edition 1.
  NTIS Order number PB89-193312LCP, 511 pp., $53.00

I ordered it recently, and received it this week.
Phone credit card orders via 703-487-4650.

Dick
-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 90 17:28:24 GMT
From:      hpfcso!hpldola!hpctdlb!hpctdlf!jeff@hplabs.hp.com  (Jeff Hughes)
To:        tcp-ip@nic.ddn.mil
Subject:   More ARP questions...

Ok,
   I found a couple more unusual uses of ARP by other vendors. First,
NCSA telnet version 2.2. When I attempt to connect to a host, it first
ARP's twice with its own IP address as the target IP address. Anyone
have any idea why??

   Also, FTP software version 2.03. I tried to FTP to a host on our
network and FTP gives me the error that the host is unreachable. Again,
examining the packets on the LAN, I see 13 ARP requests to the host
in question, each request receives the appropriate reply. Why does
FTP continue to ARP after it has obtained the hardware address it
needs?

jeff@hpctdlb.hp.com
-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 90 17:36:45 GMT
From:      snorkelwacker!usc!wuarchive!rex!srikanth@tut.cis.ohio-state.edu  (R Srikanth)
To:        tcp-ip@nic.ddn.mil
Subject:   tftp,anonymous ftp

I am interested in the security aspects of tftp. I am trying to find out
why tftp exists, what it does exactly, and what are the security
restrictions on it. Also I would like to know what is the difference
between tftp and ftp (anonymous) in terms of the access to files on
systems for which one does not have any authorization.

Thank you
-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 90 18:26:05 GMT
From:      pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!sunybcs!dsinc!netnews.upenn.edu!vax1.cc.lehigh.edu!vlsi3b15!lehi3b15!mludwig@tut.cis.ohio-state.edu  (Mitchell Ludwig)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: SLIP
Out of curisoty, and for no other reason than my company has no desire
to lose a phone line forever, has anyone heard anything serious
concerning the supposed dialup SLIP package?  Does it work?

Mitch
-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      28 Mar 90 23:56:27 GMT
From:      uswat!!matthews@boulder.colorado.edu  (John Matthews)
To:        tcp-ip@nic.ddn.mil
Subject:   Any Laptop Network Monitor Recommendations?
Can anyone give me any good recommendations for a laptop network monitor?
We want to get a very fast laptop 386 that won't miss any packets.
The other question is what's the BEST ethernet card around?  So far,
I am considering the Toshiba 5200 laptop.  Has anyone had any problems
with it?  If anyone knows of nice software that will monitor such protocols
as: IP,DECNET,APPLETALK,CHAOS,OSI,NOVELL that would be greatly appreciated
as well.  Power and portability are our main concerns at this point.
				Thanks in advance,
					John Matthews
-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 00:27:01 GMT
From:      network.ucsd.edu!celit!dave@ucsd.edu  (Dave Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Help: NFS Mounts over `slip' not working
In article <883@wrs.wrs.com> hwajin@wrs.wrs.com () writes:
>In article <1807@tfd.UUCP> kent@tfd.UUCP (Kent Hauser) writes:
>>Here's the setup -- SunOS 3.5, with the 4.3BSD TCP, IP & SLIP 
>>distributions installed.  Slip is running between the `ttya' ports
>>of two Sun 3/60's.  `ping', `rlogin', etc works fine, but a NFS
>>mount results in ``server not responding: RPC Timed Out''.
>>
>>Any thoughts ?
>
>SunOS 3.5 turns the UDP checksum off, which is legal and works okay
>over interfaces such as ethernet which has link-level checksumming.
>On the other hand, SLIP doesn't perform checksums thus running NFS
>over SLIP requires you to turn the UDP checksum on.  Otherwise, you'll
>experience erratic behavior such as the one described above.

Possible, but unlikely.  Direct connect serial links have pretty low error
rates.  In any case, this would give you corrupt data more often than
corrupt packet headers (simple statistics, the data area is much larger than
the header area).

What is more likely to be happening is that the packets are just taking too 
long to come across.  NFS works in a block mode; each read/write involves 
sending the entire block from the disk across the link.  At 9600 baud with an 
8K filesystem, this takes 8 seconds, minimum!  In our documentation we 
recommend an NFS timeout value of 7, which is 7 tenths of a second.  Every 
access would fail on the first three retransmissions due to timeouts (the 
timeout value is doubled on each retransmission).   If the retrans value is 
too low, it would never work.

I would set timeo (in /etc/fstab or on the mount option line) to be at least
the minimum number of seconds needed to transmit the blocksize of your
filesystem across the line and leave retrans alone.

--
David L. Smith
FPS Computing, San Diego
ucsd!celerity!dave or dave@fps.com
"We are a bigger musical genius than any Bob Dylan" - Milli Vanilli
-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Thu Mar 29 08:35:58 1990
From:      karl@asylum.sf.ca.us (Karl Auerbach)
To:        ietf@venera.isi.edu.tcp-ip@nic.ddn.mil
Subject:   Source Routing Changes and RFC 1042

I am posting this on behalf of someone else.  Since I don't understand
the deeper meaning of what follows, please send followups to the
address shown at the end of the attached text.  (It's a long,
irrelevant story why I'm doing posting.)

				--karl--

=====================================================================
Monday, March 26, 1990
To:	IETF Liaison
From:	Rich Seifert
Company:	Networks and Communications
Subject:	Source Routing Changes and RFC 1042

I am trying to act as a liaison between IEEE 802 and the IETF.  I am a
(loud and active) member of both IEEE 802.1 (Transparent Bridging),
802.5 (Source Routing) and the joint .1/.5 task force working on
Source Routing/Transparent Bridge Interoperability.  I'm not sure who
this should go to, but I was asked to try to get this information to
the cognoscente of RFC 1042 and the IETF as work we are doing in IEEE
802 may have significant impact.

During the last IEEE plenary in Irvine, CA during the week of 12-16
March 1990, significant progress was made towards achieving harmony
between Transparent Bridging (TB) and Source Routing (SR).  Boiled down
to simplicity itself, IBM proposed that SR bridges should provide full
TB capability.  That is, SR bridges should be a proper superset of the
802.1 TB specification.  To avoid confusion with the earlier draft
specification of SR bridges, this new bridge is called an SRT bridge.

SRT bridges:

   * Share a single spanning tree with all TBs.  There is now no longer
     separate spanning trees for the two bridge domains.  In fact, there
     aren't two bridge domains anymore.

   * Forward multicast (group) address along the spanning tree instead
     of source routed paths.  This eliminates duplicate multicasts at the
     end stations.

   * Act as a transparent bridge for all frames which do not carry
     Routing Information (RII = 0).

   * Act as a source routing bridge for all frames which do carry
     Routing Information.

End stations do the following:

   * Send all multicast frames without Routing Information.  Source
     routing is now restricted to unicast traffic.

   * Send Route Explorer frames without Routing Information.  They will
     be delivered along the spanning tree.

   * Send Route Explorer responses RAll Routes BroadcastS AND Spanning
     Tree (no Routing Information).  This ensures that the response will be
     heard by the originator regardless of the types of bridges present in
     the path between them.

   * Use Routing Information (Source Routing) if available and
     desirable; otherwise they may always use Spanning Tree (transparent
     bridging).

There is no change required to the Transparent Bridge specification or
to transparent (non-source routing) end stations.

Significant changes are being made to the 802.5 Source Routing
specification.  (Note that Transparent Bridging has been passed by 802
and is in the ISO Draft cycle.  Source Routing has not yet been
released, even as a draft standard.  This proposal radically changes
the nature and content of the Source Routing draft.)

These changes include:

   * Elimination of the SR-TB bridge.  With all SRTs providing
     transparent bridge support, there is no need for any translation or
     interoperability device.

   * Elimination of the "double transmission" of multicast addressed
     frames by end stations.

   * Elimination of Routing Type RT = 111 (Spanning Tree Routed)
     frame.  Frames to be sent on the spanning tree are sent without any
     Routing Information.

   *  Elimination of Routing Type RT = 110 (Spanning Tree Explorer) frame.

   *  Elimination of multicast address table, flags, filtering, etc.

   *  Elimination of the SR-specific Bridge PDU.

   * Addition of route explorer response (All Routes Broadcast AND
     Spanning Tree)

   *  Addition of mandatory TB capability for SR bridges.

The result of all of this is:

   * Source Routing features available to any station which wishes to
     use them.

   *  Simplified multicast handling

   * Arbitrary mixing of SR and TB stations and bridges on a bridged
     LAN, with NO configuration or design rules.

   *  Seamless interoperability.

   *  A solution for FDDI as well as 802.

   *  A single domain, with a single spanning tree.

   *  No need for an SR-TB bridge or translator

Not bad for a standards group, eh!

There will be an interim meeting of the joint 802.1/802.5 bridging
Task Force May 1-2 at the Embassy Suites hotel in beautiful, downtown
Milpitas, CA.  Feel free to contact me if you are interested in this
meeting, or in more detail on the changing Source Routing standard.

I am available and willing to help resolve any issues this raises with
respect to RFC 1042 or other areas of Internet concern.


Rich Seifert

President
Networks and Communications
10596 John Way
Cupertino, CA 95014
(408) 996-0922
(408) 996-2860 FAX
seifert@asylum.SF.CA.US

-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Mar 90 09:45:18 -0500 (EST)
From:      Craig_Everhart@transarc.com
To:        tcp-ip@nic.ddn.mil, Mark Bodenstein <MAB@cornellc.cit.cornell.edu>
Cc:        Aaron Wohl <aw0g+@andrew.cmu.edu>
Subject:   Re: Single domain name/IP address for a group of hosts
Buried in the Andrew contribution to the X.V11R4 release is a
load-balancing program that Aaron Wohl (at CMU) wrote.  (You'd find it
under andrew/overhead/snap2 somewhere; Aaron will be able to clarify.) 
The server that answers IP-address requests for the artificial name
keeps contact with a collections of machines in a service pool, and will
point incoming requests at the IP address (or CNAME, maybe) of the
least-loaded server machine in a pool.

Sounds like what you want.  It's publicly available.  I don't know if
all the pieces are in the Andrew contribution or whether there's some
stuff elsewhere as well; again, Aaron will know.

Only problem is that this server returns packets with very short (0)
lifetimes, because loads change instantaneously, and
currently-distributed resolver routines generally don't handle those
very well.  (I don't know whether it would be reasonable to return
packets with lifetimes of a few seconds instead.)

		Craig


-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Mar 90 07:09:36 EST
From:      Marci Kennedy <marci@aretha.franklin.uga.edu>
To:        TCP-IP%SRI-NIC.ARPA@uga.cc.uga.edu
Subject:   Re: Problems with AIX "illegal protocols" ?
I don't know, but it is worrisome.  Perhaps you should pass this information
on to Kurt Jansen, who's boss is planning to invest heavily in the new
RISC (risk?) product from IBM.  Perhaps Schaffer can bring some pressure
to bare on the SE IBM group that will have positive repercussions.

                               -- Marci
-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 04:18:35 GMT
From:      silver!gilbertd@iuvax.cs.indiana.edu  (Don Gilbert)
To:        tcp-ip@nic.ddn.mil
Subject:   Bitnet ftp ?

Can someone direct me to info about bitnet-ftp or bitftp?
I know it exists somewhere:  a gateway that converts
bitnet messages to ftp calls, and returns the ftp results thru
bitnet.  I have an ftp archive that bitnet-only users want
access to.  I'd like to know how bitftp works, where this 
public gateway is, and/or is the software available.  
            Thanks,  Don

Don Gilbert  biocomputing office   /  archive for
gilbertd@iubio.bio.indiana.edu    /  molecular & general biology
biology dept., indiana univ.,    /  ftp iubio.bio.indiana.edu  
bloomington, in 47405, usa      /  (129.79.1.101) user anonymous 
-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Mar 90 13:33:06 -0500
From:      "Martin Lee Schoffstall" <schoff@psi.com>
To:        enger@sccgate.scc.com ( Robert M. Enger)
Cc:        pollux!ccruss@ucdavis.ucdavis.edu, tcp-ip@nic.ddn.mil, martyne@chumley.tn.cornell.edu, rma@cc.rochester.edu, wls@psi.com
Subject:   Re: High Schools on the Internet

Also, Richard Mandelbaum of NYSERNet Inc. is working on this
issue.

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

 Russ:

 At the next IETF meeting you might wish to take a moment to speak
 with Martyne Hallgren of Cornell.  She is in the process of putting
 a number of high schools onto the Internet.

 Bob
-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Mar 90 10:23:47 EST
From:      stine@sparta.com (Robert Havens Stine)
To:        netcom!netcom.uucp!schang@apple.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  getting on internet
> I am looking for ways for a small company to get on internet without paying
> a lots of money...

You might consider AlterNet or the Cypress Network.

For info on AlterNet, contact Rick Adams <rick@uunet.uu.net>.

For info on the Cypress Network, contact Scott Ballew <smb@cs.purdue.edu>.

Bob Stine
stine@sparta.com
-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 05:29:07 GMT
From:      netcom!netcom.uucp!schang@apple.com  (Sehyo Chang)
To:        tcp-ip@nic.ddn.mil
Subject:   getting on internet

I am looking for ways for a small company to get on internet without paying
a lots of money.  Should I try direclty connect to backbone sites?, or one
of the regional network?.  All information/reply would be appreciated. thanks
-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 05:33:40 GMT
From:      eagle!mlacus!paulb@ucbvax.Berkeley.EDU  (Paul Bandler)
To:        tcp-ip@nic.ddn.mil
Subject:   OSI Over TCP Interoperability Issues - Q's
I've observed discussion on the net in the area of running
OSI upper layers over TCP lower layers and visa versa.  I'm also aware of
the ISODE work.

However, from what I've read I'm still unclear as to the actual interoperability
that can be achieved without actually having the same implementation at both
ends.

If I take one implementation of OSI layers 5-7 stack running over TCP
will it inter-operate with such a stack of a different implementation?

What are the issues here?  I've seen discussion on:

	Transport Disconnect protocol differences
	Address Format Differences
	"Directories issues"

but I was unable to discern an agreed position of these issues.  Can anyone
offer what the state of the art is?  I've also heard mention of a standard
which defines how OSI should use TCP.  Can anyone point me towards this?

Replies by mail are prefered - I seem to miss postings in times of heavy
traffic.

Thanks in anticipation.

Paul Bandler
ACUS - Australian Centre For Unisys Software
-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 05:48:09 GMT
From:      samsung!munnari.oz.au!bruce!mlacus!paulb@uunet.uu.net  (Paul Bandler)
To:        tcp-ip@nic.ddn.mil
Subject:   TCP/IP Over WAN Connections - SLIP/PPP/X.25?

I've observed discussions on running TCP over serial lines using something
called SLIP, and more recently discussion on something called PPP - Point to
Point Protocol.

The products my employer sells for WAN TCP/IP connections use X.25, either
over a real X.25 PDN or even a point-to-point connection.

Can anyone point me towards / provide me with the full picture of TCP/WAN
connections?  I'm looking for answers to questions such as:

Are all these WAN methods "standard" (RFC...) TCP/IP subnets?
When are each the 'best method'?
Which came first? 
Which is the most commonly used?
 
Is there good book/reference for such information.

My overall objective is to understand the issues involved in connecting a
PC to a TCP/IP host over WAN connections.

Please reply by mail as postings often get lost.  

Thanks in anticipation

Paul Bandler
ACUS - Australian Centre for Unisys Software
-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      Thu, 29 Mar 90 13:14:38 -0100
From:      Philippe Prindeville <philipp@Gipsi.Gipsi.Fr>
To:        LARSON@CRVAX.SRI.COM, tcp-ip@NIC.DDN.MIL
Subject:   re: MX Records
		The only time it should be possible to deliver mail to a host
		without an MX record is when it is done by the MXer of highest
		preference for that destination.
	
	Suprisingly, it is a technical error for the MXer of highest preference
	to not be the host itself.  This would result in an empty MX list after
	removing irrelevant RRs in the MXer of highest preference.  This is an
	error condition, although it is noted that "974 points out that
	"extremely persistent mail systems might want to try a delivery to
	REMOTE's address..."

I don't believe this statement is correct.  It should be (and is)
possible to have the following:

	some-pc.domain.org	IN	MX	10 mail-relay.domain.org

where mail-relay is prepared to receive mail for some-pc and
"deliver" to some-pc, possibly by uucp, tftp, POP, IMAP, or even
by sharing (via NFS) mailboxes.  Clearly, in this case some-pc
is not the MXer of highest preference (or even one of the MXers).
Yes, there would be an empty list at this point.  So, mail-relay
would have to deliver the mail by an agreement which is considered
(and rightly) a "local affair".

	The present system provides for reasonable defaults, and reduces the
	amount of information stored and transmitted in the DNS in common cases.
	The current use of an A record implying an MX record is reasonable, and
	should be retained.

The present system provides a set of semantics that support the
current politics of the Internet.  It does not represent the
technically "optimal" solution...

-Philip
-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 16:26:21 GMT
From:      manta!psm@nosc.mil  (Scot Mcintosh)
To:        tcp-ip@nic.ddn.mil
Subject:   RDP Implementations: Summary
A while back I posted a query about RDP implementations. To
summarize the responses in a word: zilch. There were a total
of two.  One asked me to let him know what I found out, and
the other said that he had made the same query in the past,
had heard nothing, and implemented it himself.  Unfortunately,
it was for a customer, so he couldn't make the code available.
So, I guess we'll be rolling our own as well. When we're done
(don't hold your breath), I'll make the result available.
-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 16:55:55 GMT
From:      spot!marti@boulder.colorado.edu  (Al Marti)
To:        tcp-ip@nic.ddn.mil
Subject:   Problems installing KIP code
We are having problems install the Kinetics Internet Protocol(KIP) code
on our network.  The installlation document is two years old and 
many parts seem to be irrelevant to the latest FastPath Manager
version we have, 5.xx.  Can someone who has recently installed this code
give me some pointers on how they differed from the install docs?  A
sample atalkatab and atalk.local file would be of great help also.
If possible please reply directly to me at: marti@spot.colorado.edu.

-Al Marti
Computing and Network Services
University of Colorado, Boulder
marti@spot.colorado.edu
(303)492-4617

*----------------------------------*
* Al Marti                         *
* marti@spot.colorado.edu          *
*----------------------------------*
-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 16:58:24 GMT
From:      pilchuck!amc-gw!thebes!ncrsea!dmdc@uunet.uu.net  (Dennis M. Dooley)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Help w/internet address & subnets
In article <332@sfc.Wichita.NCR.COM> chas@sfc.Wichita.NCR.COM (Charles Binford) writes:
>
>We are trying to figure out how to setup our internet address with
>the proper subnets.  If you are will to give some hints and advice 
>please send email and I'll send the specifics of our situation.
>
     I don't have much in the way of advice for you...  but if you need
     a good source for information on network addressing, subnet masks,
     etc., I would highly recommend ordering the publication "Using your
     NCR TOWERVIEW X-Station" - ST-21114-06.  Chapter 4 has one of the
     best coverages of TCP/IP networking, routing and gateways that I
     have seen from NCR.

________________________________________________________________________

Dennis M. Dooley      Systems Engineering     NCR Corporation
ncrsea!dmdc           (206) 643-4150          15400 S.E. 30th Pl.
dennis.dooley@ncrsea.Seattle.NCR.COM          Bellevue, WA. 98007
-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 17:04:34 GMT
From:      csusac!csuchico.edu!csuchico.edu!robin@ucdavis.ucdavis.edu  (Robin Goldstone)
To:        tcp-ip@nic.ddn.mil
Subject:   Help needed with CMU-TEK MAILSMB installation
I am installing CMU-TEK tcpip software version 6.4 on a VAX 11/750 running
VMS 5.2.  The main modules IPDRIVER, NAMSRV, IPACP, Telnet and FTP have
actually been operational for a few months and work just fine.  Yesterday
I went to install the mail-related stuff.  I installed INET_MAILSHR then
MAILSMB (version 2.8).  When I executed MAILSMB_STARTUP.COM, which sets
up the mail queues, it ended with:

%JBC-E-SYMDEL, unexpected symbiont process termination

I have limited VMS expertise and have no idea what this error is implying.
Does anyone have any ideas?

Please reply directly via e-mail if possible to robin@csuchico.edu

Thanks.   
Robin Goldstone,  Systems Software Specialist
California State University, Chico Computer Center
robin@csuchico.edu
-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 17:16:28 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:   Re: Single domain name/IP address for a group of hosts

In article <oa4Vxyf0BwwOQ15IY3@transarc.com> Craig_Everhart@TRANSARC.COM writes:

   Only problem is that this server returns packets with very short (0)
   lifetimes, because loads change instantaneously, and
   currently-distributed resolver routines generally don't handle those
   very well.  (I don't know whether it would be reasonable to return
   packets with lifetimes of a few seconds instead.)

Craig, can you track down which piece of the resolver code has
the wrong way of dealing with 0 TTLs?  A cursory grep of my
bind sources didn't show anything too obvious.

I've thought about instances, like a dial-up IP that assigns a user a
different IP address each time, where it would be the right thing to
have a lifetime of 0 seconds mean "never cache this result".  This
appears to be the same semantics that you want.  Since caching is
absolutely necessary to having the net avoid being swamped by DNS
traffic, this is possibly a dangerous approach and should be looked at
with some caution!

RFC 1035 section 3.3.13, in its discussion of the MINIMUM part of the
SOA record, calls this field "a lower bound on the TTL field for all
RRs in a zone".  Administratively, this may mean that you need to set
MINIMUM really low for all hosts and explicitly put in longer times
for more permanent entities (if you domain has a mix of transient
names and long-lived names).

--Ed

Edward Vielmetti, U of Michigan math dept.
emv@math.lsa.umich.edu
-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 17:38:01 GMT
From:      logicon.com!tots!tep@nosc.mil  (Tom Perrine)
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  tftp,anonymous ftp
As long as someone has brought up security aspects of tftp, I feel
that is also important to remark that unrestricted tftp is a security
hole. Of course, it will only let you download files that are
world-readable. Note that in the absence of an "-s" option and a
chroot() that this will include the passwd file. I do not believe that
all vendors support "secure tftp" yet.

Handy for offline password cracking....

Tom Perrine (tep)
Logicon (Tactical and Training Systems Division) San Diego CA (619) 455-1330
Internet: tep@tots.Logicon.COM		GENIE: T.PERRINE
UUCP: nosc!hamachi!tots!tep -or- sun!suntan!tots!tep
-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 18:09:02 GMT
From:      gay@venice.SEDD.TRW.COM (Lance Gay)
To:        comp.os.vms,comp.protocols.tcp-ip
Subject:   Bug in V6.4 CMUTEK software


     I have found a bug in the CMUTEK V6.4 TCP/IP software running under
VMS 5.2.  If you PING (i.e send an ICMP ECHO request) a VMS system running 
CMUTEK software with a packet size of greater than about 500 bytes, the 
IPACP process will abort and the following will be printed on the operator's
console:

    ?IPACP: Exception handler: signal name 0000000C
    IPACP: Network offline - ACP exiting.

A fix for this shouldn't be too hard, but I hate to wade through BLISS code.
Has anyone else run across this problem?

Lance Gay                                    Internet: gay@venice.sedd.trw.com
TRW Systems Engineering & Development Div.   Phone: 213-764-9292
Redondo Beach, CA  90278

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 19:04:08 GMT
From:      nsc!pyramid!infmx!briand@decwrl.dec.com  (brian donat)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Broadcasting Addresses and Subnets
In article <54705@bu.edu.bu.edu>, kwe@bu-it.bu.edu (Kent England) writes:
> _______________
> 
>  RFC 1009 - Requirements for Internet Gateways                  June 1987
> 

Ok, so I'm a neophyte.  I don't even know where to get RFCs. 

Some I know are recommended reading for us up-getty-dy neophytes.

	eg. RFC 1009, 1122, 1123, and 1118. 

I can't help but know, - I read.    But I'll be damned if I know
where I obtain copies of these puppies.  I'd like to read 'em. 

Does NIC at SRI International dispense these things like internet 
addresses? 

Can anyone help open this door? 

briand@infmx
-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 19:19:33 GMT
From:      nsc!pyramid!infmx!briand@decwrl.dec.com  (brian donat)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Broadcasting Addresses and Subnets
Disregard my last message.   Too late to kill it.
Obviously, other folks had the same question.
-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 19:50:24 GMT
From:      image.soe.clarkson.edu!nelson@uunet.uu.net  (Russ Nelson)
To:        tcp-ip@nic.ddn.mil
Subject:   4.2BSD lpr spec exists.
Five years ago, Shawn Routhier write a document that describes the lpr
protcol.  I found that document in husc6.harvard.edu:/pub/pcip/doc.tar.Z:/doc/lprspec.txt.
I'll put it sun.soe.clarkson.edu:/pub/ka9q/lprspec.txt.
-russ
-- 
--russ (nelson@clutx [.bitnet | .clarkson.edu])  Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problems
Clarkson will be featured on PBS's Computer Chronicles next week.  I'm the dude
with the camcorder taking digital portraits.
-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 22:26:22 GMT
From:      zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!vax1.cc.lehigh.edu!vlsi3b15!lehi3b15!mludwig@tut.cis.ohio-state.edu  (Mitchell Ludwig)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: getting on internet
In article <10156@netcom.UUCP> schang@netcom.uucp (Sehyo Chang) writes:
>
>I am looking for ways for a small company to get on internet without paying
>a lots of money.  Should I try direclty connect to backbone sites?, or one
>of the regional network?.  All information/reply would be appreciated. thanks

And for the third time in a week I say .. .. ..  I would like to know
any of this info too.  Up to now, I've been persuing slip only implementations,
but if any of you net.gurus have better ideas, throw them our way!

Mitch
-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      29 Mar 90 22:43:59 GMT
From:      sdcc6!cerf.net@ucsd.edu  (Pushpendra Mohta)
To:        tcp-ip@nic.ddn.mil
Subject:   PERFORMANCE EVALUATION ON WANs



This relates to performance evaluation on wide area
TCP/IP networks.This is slightly long and my questions are prefaced
by some of my notes , so indulge me.


How do people measure performance?
What kind of parameters are of interest to the community
and to the network managers? Some obvious ones which
come to mind are capacity utilization , delays and things like
"availability" of the network.

CAPACITY UTILIZATION

I suppose this would be used by most people to decide
when to upgrade speed on serial links.Measuring utilization
is not so much of a problem but what should be the
granularity of these measurements in time ? Data traffic
is usually bursty. While frequent measurements  provide
realistic utilization figures, they contribute to the traffic themselves
Too sparse measurements hide the real picture. 

What is a decent interval to poll for utilization ?  
How does one extrapolate this data to the actual utilization/congestion
on the link ? Is there published work on interpretation of
empirical measurements? An example of what I am looking for are
rules of thumb like - poll every <x> minutes and if the
average utilization is greater then <y> percent , it is time
to upgrade the speed of the link. 

DELAY MEASUREMENTS

Delays will be introduced on the network due
to queueing (link speeds ,processing in routers/gateways)
physical transmission times (link speeds,network access)
particular routes chosen by the packets and lost/damaged packets etc.

One would like to  measure delays on the network to examine
routing and to decide whether faster gateways/routers and links are
called for.

Again, how does one measure delay?
[ ICMP Echo, SNMP queries on MIB Interface Queuelenghts ? ]
More importantly on a WAN, how does one partition different
components of delay, specially since delays are more transient
than utilization figures.


AVAILABILITY OF THE NETWORK

This is perhaps the variable which is most subjective
both in measurement and interpretation. I am trying to 
come up with a "number", say on a percent scale which will
indicate " how available the network is". This should
include things like router/gateway failures , link failures
compensated for by the fact that there are redundant links in the
WAN and whether the failed device is a leaf-site as opposed to a
backbone site.In short it should measure the logical connectivity
of the network- a measure of the how many sites on the network
could reach how many other sites.I am not sure whether it will
end up being a number or a matrix - but the idea is develop
an all encompassing ( as if it is possible !) measure to
compare/judge a networks daily/weekly perfromance

Has someone developed a model like this ?
I am aware of theoretical models but there assumptions
preclude their use in "Real-Life" networks. 

How do other regional nets /WANs measure and INTERPRET
performance ? What do they measure ? What goes on their
daily/weekly/monthly reports ? What do users want to see
on these reports ?
I am also looking for pointers to published
work.

Email me and I will summarize

Pushpendra Mohta
CERFNet/SDSC/UCSD
pushp@cerf.net
pmohta@ucsd.edu 
-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 90 00:42:18 GMT
From:      mtxinu!rtech!wrs!hwajin@ucbvax.Berkeley.EDU  (Hwa Jin Bae)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Help: NFS Mounts over `slip' not working
In article <7624@celit.fps.com> dave@fps.com (Dave Smith) writes:
>   Possible, but unlikely.  Direct connect serial links have pretty low error
>   rates.  In any case, this would give you corrupt data more often than
>   corrupt packet headers (simple statistics, the data area is much larger than
>   the header area).

1. Direct connect serial links in general exhibit variable error rates and
   sometimes quite high error rates.  This depends entirely on the quality
   and length of the line in question.  The issue is that errors do happen!
2. The fact that it's more likely to have the data corrupted (because it's
   larger most of the time) than headers is irrelevant to the UDP checksumming
   which is computed over the entire packet, not just headers.  Am I missing
   something you're trying to say here?
3. I have been using my implementation of SLIP for our proprietary realtime
   OS to communicate with SunOS 4.0.3 reliably over NFS (we also have a NFS
   client implementation for our OS) with UDP checksum turned on.  I know
   of at least one customer of ours who's doing the same without problems
   for the past several months.  The timeo value tweaking sounds interesting
   but so far everything's been running okay without any special adjustments.
4. Guy Harris reminded me of kernel hacks in SunOS 3.5 NFS implementation that
   uses kudp_fastsend() which bypasses the code in udp_usrreq.c entirely.  I
   do remember seeing such code a while back but I don't have SunOS 3.5 source
   code with me so I can't verify this.  Oh well...

--
hwajin@wrs.com
-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Mar 90 08:12:05 CST
From:      MAINT@ASNTSU.asn.net
To:        TCP-IP@SRI-NIC.ARPA
I have a question for you POP2 (RFC-937) experts. The RFC very clearly
describes how a server delivers mail to a client and how a client gets
mail from a server. However, there is no mention of how a client sends mail
(SMTP, since this does not require a resident program?) or how a server
receives mail to be delivered. Is there another RFC that describes this? What
am I missing (bad copy of the RFC?)? If anyone has any information this
inquiring mind wants to know. Thanks in advance.

--------------------------------------------------------------------------------
Dennis Putnam, Service Manager
Boeing Computer Services
Alabama Supercomputer Network
-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Mar 90 11:15:42 -0500
From:      Stephen Wolff <steve@cise.nsf.gov>
To:        tcp-ip@NIC.DDN.MIL, zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!vax1.cc.lehigh.edu!vlsi3b15!lehi3b15!mludwig@TUT.CIS.OHIO-STATE.EDU
Subject:   Re: getting on internet
Try your local regional network of the Internet; many have special deals for
small businesses, start-ups, and the like.  Or contact any of

		Anterior Communication Services
		P.O. Box 1206
		Menlo Park, CA  94026-1206
		Attn: Mr. Geoffrey S. Goodfellow

                Performance Systems International
                11800 Sunrise Valley Drive, Suite 1100
                Reston, VA  22091

                Uunet Communications Services, Inc.
                3110 Fairview Park Drive, Suite 570
                Falls Church, VA  22042

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Mar 90 10:59:04 PST
From:      postel@venera.isi.edu
To:        MAINT@asntsu.asn.net
Cc:        TCP-IP@nic.ddn.mil
Subject:   Re: question for you POP2 (RFC-937) experts

Dennis Putnam:

Hi.  The sending is done via SMTP (RFC-821).  A "send only" SMTP implementation
is pretty straight forward.

--jon.
-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Mar 90 11:51:37 PST
From:      postel@venera.isi.edu
To:        kddlab!trl!rdmei!pronews!baltan!okada@uunet.uu.net
Cc:        JKRey@venera.isi.edu, Postel@venera.isi.edu, tcp-ip@nic.ddn.mil
Subject:   re: private protocol port

Noritake Okada:

To have an assigned port number you make a requests to the Internet Assigned 
Numbers Authority (IANA) care of Joyce Reynolds (JKREY@ISI.EDU).  Typically
you will be required to describe your planned use of the port -- especially,
the protocol to be used on the network, its packet formats is interaction
sequences, commands and replies, ond so on.  It would be most desirable that
you prepare a memo to be published as an RFC about your experimental protocol,
but this is not a requirement.

--jon.
-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 90 04:18:19 GMT
From:      kddlab!trl!rdmei!pronews!baltan!okada@uunet.uu.net  (Noritake Okada)
To:        tcp-ip@nic.ddn.mil
Subject:   private protocol port

 I am developing a networking software using socket interface.
 And I need a private protocol port for its daemon to identify
 the service.
 It is private,but I'd like to avoid the collision of the ports
 with other major services.  Is the only way to do this to take
 the formal procedure to get a port?  If so,what shall I do as
 the formal procedure?


 Noritake Okada		okada@sws.cpd.mei.co.jp
			Matsushita Electric Industrial Co., Ltd. Japan
-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 90 04:20:12 GMT
From:      stealth.acf.nyu.edu!brnstnd@nyu.edu
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Finding U Wash
In article <5322@amelia.nas.nasa.gov> samlb@pioneer.arc.nasa.gov (Sam Bassett RCD) writes:
> 	I want to send some mail to a guy named "draggi" at a machine
> named "milton" at the University of Washington in Seattle.  I've tried
> various things (including interrogating the NIC at SRI), and I can't get
> a line on any machine at the U of Wash, much less one called milton --

Gee, another triumph for the 125,000 hosts table:

128.125.1.81	milton.usc.edu
128.227.40.22	milton.iec.ufl.edu
128.95.136.1	milton.u.washington.edu u.u.washington.edu u.washington.edu
129.149.34.111	milton_client1.tops.sun.com
129.149.34.24	milton.tops.sun.com

Total search time: just under three seconds.

I snicker at the hosts attempting this search with DNS.

Followups to tcp-ip.

---Dan
-----------[000377][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Mar 90 10:12:37 EST
From:      bill gunshannon <702WFG%SCRVMSYS.BITNET@CORNELLC.cit.cornell.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: More ARP questions
>   I found a couple more unusual uses of ARP by other vendors. First,
>NCSA telnet version 2.2. When I attempt to connect to a host, it first
>ARP's twice with its own IP address as the target IP address. Anyone
>have any idea why??
>

NCSA Telnet checks first to see if you are using the same IP Address
as some other host on the network.  If this is the case, it refuses
to establish the connection.  On a mchine where the user has the ability
change IP Addresses pretty much at will, this is IMHO a very good idea.

bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000378][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Mar 90 10:15:15 EST
From:      jbvb@vax.ftp.com (James Van Bokkelen)
To:        karl@asylum.sf.ca.us
Cc:        ietf@venera.isi.edu, tcp-ip@nic.ddn.mil
Subject:   Re: Source Routing Changes and RFC 1042
I can't get to the "joint bridging task force" meeting on May 2, but
I really hope the Internet community will be represented, both research
and commercial sides.  Some history follows:

1. IP over 802.5 is well established, and unlike many other 802.5
sub-protocols it uses LLC1 and is thus required to be cognizant of
source routing in all (or at least most of) its glory.

2. The bit-ordering of 802.5 addresses across the protocol-stack to
MAC programming interface is well established, and tunnel-vision when
things were being designed has made it very difficult to build a
general 802.5 - Ether bridge.

3. The FDDI people have learned from history, and are attempting to
legislate bit-ordering through the programming interface and source
routing such that general Ether - FDDI bridges will be feasible, at
the expense of 802.5 - FDDI bridging.

Without knowing the details of 802.1's history, I am concerned that
what is in the works here is a "standards flag day" for 802.5, with
changes on a similar scale to the DIX Ethernet -> 802.3 Ethernet
standards changes.  While I am not at all enthusiastic about the
mechanisms 802.5 uses for source routing today, there are a *lot* of
nodes out there, and a standard MAC programming interface under DOS:
IBM's ASI spec, which has the 'difficult' bit-order embedded in it, is
supported by essentially all PC 802.5 interface vendors.

If the proposed changes won't affect an 802.5 end-node implementing
source-routing sufficient for current IBM 802.5 - 802.5 bridges, I'll
let the bridge proponents fight it out among themselves.  However, if
the changes will, I will opine: The time for major structural changes
to 802.5 and its approach to bridging, affecting end-nodes, has
passed.  Furthermore, I don't think that bridges are sufficiently
better than multi-protocol routers that "better mixed-media bridging"
justifies that large a change to the existing, de-facto 802.5.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901

-----------[000379][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Mar 90 10:27:25 EST
From:      jbvb@vax.ftp.com (James Van Bokkelen)
To:        tcp-ip@nic.ddn.mil
Cc:        jeff@hpctdlb.hp.com
Subject:   Re: More ARP questions...
The NCSA node is probably attempting to find out if anyone else has the
same IP address as it has been told to use.  This is a defensible thing
to do, although it certainly hasn't been universally adopted.

The PC/TCP node's behaviour indicates one of the following problems:

1. The other host may not be sending the reply to the right place, or
the format may be wrong.  We check hardware type.

2. The PC has a network interface that is either broken, or marginal, and
it isn't seeing the replies.

3. The network cable is marginal, and pairs of nodes exist that can't
see each other's packets, or they always arrive damaged.  This is pretty
easy to do with a thin Ethernet that is slightly too big...

In any of the above cases, the PC/TCP kernel does not "...continue to
ARP after...".  Instead, it is re-trying because it hasn't gotten the
answer it needs.  The command "inet debug" will print out statistics
from the low-level driver and ARP module, which should help to
determine what's wrong.  If your support is current, give us a call...

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000380][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Mar 90 14:45:10 -0500 (EST)
From:      Drew Daniel Perkins <ddp+@andrew.cmu.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Single domain name/IP address for a group of hosts
zaphod.mps.ohio-state.edu!math.lsa.umich.edu!emv@tut.cis.ohio-state.edu \ writes:
> In article <oa4Vxyf0BwwOQ15IY3@transarc.com> Craig_Everhart@TRANSARC.COM write\
> s:
> 
>    Only problem is that this server returns packets with very short (0)
>    lifetimes, because loads change instantaneously, and
>    currently-distributed resolver routines generally don't handle those
>    very well.  (I don't know whether it would be reasonable to return
>    packets with lifetimes of a few seconds instead.)
> 
> Craig, can you track down which piece of the resolver code has
> the wrong way of dealing with 0 TTLs?  A cursory grep of my
> bind sources didn't show anything too obvious.

Craig mis-spoke.  The bugs with 0 TTLs are not in the BIND resolver code
(or more technically the resolver stub code), they are in the named
code.  Also, the bugs were fairly subtle and not obvious upon a
cursory glance at the code.  I don't remember exactly what I had to
fix (it was a year ago), but the basic problems had to do with the
database code.  The bug caused named to loop until it had completely
filled the packet buffer. Then it would return an error.  The bug
fixes were not trivial.  I forwarded the fixes to Mike Karels at
Berkeley, but I don't think he was going to use them because he had
plans for other fairly substantial changes.

> RFC 1035 section 3.3.13, in its discussion of the MINIMUM part of the
> SOA record, calls this field "a lower bound on the TTL field for all
> RRs in a zone".  Administratively, this may mean that you need to set
> MINIMUM really low for all hosts and explicitly put in longer times
> for more permanent entities (if you domain has a mix of transient
> names and long-lived names).

We got around these problems using long-lived CNAMEs in our normal large zone
pointing at zero TTL RRs in a special load-balancing zone.

Drew
-----------[000381][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 90 07:33:12 GMT
From:      mcsun!inria!bull!echbull!ablews!baux@uunet.uu.net
To:        tcp-ip@nic.ddn.mil
Subject:   Looking for a KNVS in Streams
Any information about a NVS implementation in Kernel (Rick Ace - like)
an within  Streams, is welcome
andre

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=++=+=+=+	Andre Baux
Email   : baux@ec.bull.fr		Bull S.A.
Fax     : 011-33-76397600		1, Rue de Provence / B.P. 208
Phone   : +33 76 39 76 02		38432 Echirolles CEDEX / FRANCE
-----------[000382][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Mar 90 13:41:46 CST
From:      MAINT@ASNTSU.asn.net
To:        TCP-IP@SRI-NIC.ARPA
Subject:   POP2 Server
Thanks for the responses to my question about POP2 servers but I apparently
need to clarify what I'm asking for. I think I pretty much understand the
client interface, its the server that I don't fully comprehend. My main
question is where does the server get the mail from that is to be delivered
when a client connects? How does the server know which client the mail is
for and what folder, between the time it receives the mail until the client
connects to retreive the mail? Is there a hook in the SMTP server that
knows when mail has to be forwarded to the POP2 server rather than a
resident user? Since the client must have an account on the host running
the server does SMTP store the mail for that user per normal and then the
POP2 server access it there? Is there a standard that shows where and how
the POP2 server determines what mail is waiting? Thanks again and I apologize
for my ignorance on this subject.

--------------------------------------------------------------------------------
Dennis Putnam, Service Manager
Boeing Computer Services
Alabama Supercomputer Network
-----------[000383][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Mar 90 14:48:46 EST
From:      jas@proteon.com (John A. Shriver)
To:        jbvb@vax.ftp.com
Cc:        karl@asylum.sf.ca.us, ietf@venera.isi.edu, tcp-ip@nic.ddn.mil
Subject:   Source Routing Changes and RFC 1042
Actually, this was a change of direction on IBM's part, but they (?)
had proposed it a long time ago and it came back to life.

The papers from the session leave the MAC bit order problems as
"unsolved", for later resolution.  (Still a can of worms.)

The SR-TB device had exactly the same problems with MAC bit order,
plus some serious problems with multicast doubling and topology
restrictions.  The SR-TB was one of those things nobody was sure could
ever be perfected, and it posed too many limitations.

The SRT should alleivate the SR-TB problems.  (It's a harder device to
build than a SR bridge, however.)

Remember that IBM does not have any bit order problems.  All of their
protocols (SNA & NETBIOS over 802.2) always put MAC addresses in 802.5
order, even on 802.3!  Only (!) IP, IPX, and XNS are bothered by MAC
address bit order.

IBM could add a flag to the driver implementing the ASI, to have it
flop the bits in the MAC addresses on the way in and out.

The part of IEEE 802.1 handling bridges is independent from the part
dictating the MAC bit order.  The MAC bit order for numeric MAC
addresses is defined in 802.1a, the bridging is the province of
802.1d.

(The FDDI people are not legislating anything, they are just choosing
to conform to the current draft of 802.1a.)

As for IP knowning about source routing, all that is really needed is
a configuration flag of whether to try and thread the bridges, iff you
don't send a non-SR ARP packet first.  This is because a TB only 802.5
bridge will ignore packets with source routing.

[I didn't re-read the 802.5 papers to write this, hopefully my memory
is OK.]
-----------[000384][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Mar 90 18:35:20 PST
From:      Dave Crocker <dcrocker@nsl.dec.com>
To:        "Martin Lee Schoffstall" <schoff@psi.com>
Cc:        tkostan@trwind.trw.com (Tyson Kostan), usc!cs.utexas.edu!mailrus!umich!umeecs!itivax!vax@elroy.jpl.nasa.gov, mm@3.iti.org, tcp-ip@nic.ddn.mil
Subject:   Re: CMUT Implementations
	"...management within the OSI stack.  Despite the denials of Mr. Crocker
	who represents both DEC and the ISEG/IETF collegium, thank goodness
	we at least have the safety net of meer rationality,
	market forces, user demand, and other standards
	groups to work within to give us the possability of useful mechanisms
	to manage OSI networks in parallel with tcp/ip networks for the 20-30
	years."

Well, Marty.  A week has passed and I have yet to be able to figure
out what you are referring to.  What have I denied?

I'm inclined automatically to deny whatever denial I am supposed to have made.  
On the other hand, it probably would help if you explained the reference, first?

By way of keeping this note from being entirely frivolous, let me mention
to your readers that I had the pleasure of informing the last IETF that 
SNMP/SMI/MIB-I were recommended for elevation to the status of Full Standard.  
This action was greeted with very loud applause by those assembled.  (MIB II
was entered into the formal standards process and is expected to reach
Full Standard post haste.)

Dave
-----------[000385][next][prev][last][first]----------------------------------------------------
Date:      Fri, 30 Mar 90 16:47:24 EST
From:      Bob Stewart <stewart@xyplex.com>
To:        tcp-ip@nic.ddn.mil
Subject:   BOOTP and 32-bit CRC
I have two unrelated requests for information.  Does anyone know of:

    1.  Public domain sources for a BOOTP server to run on System V.

    2.  A public domain source (preferably C) for doing a 32-bit (Ethernet)
        CRC in software.

Thanks.

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


-----------[000386][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 90 13:08:45 GMT
From:      eagle!linus!community-chest!mitchell@ucbvax.Berkeley.EDU  (George Mitchell)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: OSI Over TCP Interoperability Issues - Q's
In article <404@mlacus.oz> paulb@mlacus.oz (Paul Bandler) wrote:
`Replies by mail are prefered - I seem to miss postings in times of heavy
`traffic.

PLEASE summarize to the net!
--
/s/ George   vmail:  703/883-6029
email:  gmitchel@mitre.org    [alt: mitchell@community-chest.mitre.org]
snail:  GB Mitchell, MITRE, MS Z676, 7525 Colshire Dr, McLean, VA  22102
-----------[000387][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 90 14:12:05 GMT
From:      MAINT@ASNTSU.ASN.NET
To:        comp.protocols.tcp-ip
Subject:   (none)

I have a question for you POP2 (RFC-937) experts. The RFC very clearly
describes how a server delivers mail to a client and how a client gets
mail from a server. However, there is no mention of how a client sends mail
(SMTP, since this does not require a resident program?) or how a server
receives mail to be delivered. Is there another RFC that describes this? What
am I missing (bad copy of the RFC?)? If anyone has any information this
inquiring mind wants to know. Thanks in advance.

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

-----------[000388][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 90 15:02:50 GMT
From:      zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!newton.ncsa.uiuc.edu!jgodsil@tut.cis.ohio-state.edu  (Joseph Godsil)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Using SLIP with SCO Xenix/Unix

  I would be interested in this - if there is one.


   Joseph M. Godsil  (jgodsil@ncsa.uiuc.edu)
   National Center for Supercomputing Applications
-----------[000389][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 90 15:12:37 GMT
From:      702WFG@SCRVMSYS.BITNET (bill gunshannon)
To:        comp.protocols.tcp-ip
Subject:   Re: More ARP questions

>   I found a couple more unusual uses of ARP by other vendors. First,
>NCSA telnet version 2.2. When I attempt to connect to a host, it first
>ARP's twice with its own IP address as the target IP address. Anyone
>have any idea why??
>

NCSA Telnet checks first to see if you are using the same IP Address
as some other host on the network.  If this is the case, it refuses
to establish the connection.  On a mchine where the user has the ability
change IP Addresses pretty much at will, this is IMHO a very good idea.

bill

                                          bill gunshannon
                                       702WFG@SCRVMSYS.BITNET

-----------[000390][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 90 16:43:47 GMT
From:      pluto!dave@nyu.edu  (Dave Monachello)
To:        tcp-ip@nic.ddn.mil
Subject:   TLI over sockets?

  Does anyone know of a PD (with source) version of TLI using sockets?
Thanks for any info.

	 Dave Monachello
	 dave@pluto.dss.com
-----------[000391][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 90 17:56:00 GMT
From:      snorkelwacker!spdcc!eli@tut.cis.ohio-state.edu  (Steve Elias)
To:        tcp-ip@nic.ddn.mil
Subject:   threatening email / Cracker-Hackers / sad face for internet :(
many thanks to those who have sent supportive messages regarding the 
scary mail i received.  *one* of the scary-mail-senders has
apologized and it is apparent that s/he misunderstood my posting.  
perhaps the other sender will apologize as well.  

in any case, i'm really disillusioned about the internet lately.
the problem goes much further than a few emails containing implicit
threats.  more than one person out there has received actual death 
threats due to their activity on the internet.  the security problems
of the internet are being exploited by Cracker-Hackers who are quite
amoral by many folks' standards.  

you know, if i didn't know better, i'd start ranting about the 
"imminent downfall of the internet", or whatever that catch-phrase is.

it's been nice usenetting with you folks.  i'm going to try to avoid 
public postings for the most part (hold back the tears!), and i'll instead
try a bit of lurking, mailing lists, and fax.  it's obviously no loss
to the network that i do this, but i wonder how many of the truly 
valuable contributors out there will ever face the same choice?
i believe some of these folk have already made such a choice...

happy trails, everyone, and have a good spring and summa.






-- 
/* eli@spdcc.com ; 617-932-5598 ; fax 508-671-7447 ; fax 508-671-7419  */
/* annoying biased comment:  US Sprint is a better LD carrier than ATT */
-----------[000392][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 90 19:02:41 GMT
From:      portal!cup.portal.com!Will@apple.com  (Will E Estes)
To:        tcp-ip@nic.ddn.mil
Subject:   Where Has UDP Been Implemented?
On what systems is the UDP datagram currently supported, and who
are the vendors who sell the protocol as part of some package?
Also, given technical characteristics of each system, could UDP be
successfully implemented on:

- Novell Netware nets running Ethernet and Arcnet
- NetBIOS nets running token ring and Ethernet
- LAN Manager nets running Ethernet
- Appletalk nets running Ethernet and Appletalk
- DEC nets running DECnet
- IBM SNA nets running LU 6.2

I'll assume that UDP is on just about every UNIX network, so I
don't even bother to ask about that world.

Thanks,
Will              (sun!portal!cup.portal.com!Will)
 
-----------[000393][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 90 19:41:46 GMT
From:      MAINT@ASNTSU.ASN.NET
To:        comp.protocols.tcp-ip
Subject:   POP2 Server

Thanks for the responses to my question about POP2 servers but I apparently
need to clarify what I'm asking for. I think I pretty much understand the
client interface, its the server that I don't fully comprehend. My main
question is where does the server get the mail from that is to be delivered
when a client connects? How does the server know which client the mail is
for and what folder, between the time it receives the mail until the client
connects to retreive the mail? Is there a hook in the SMTP server that
knows when mail has to be forwarded to the POP2 server rather than a
resident user? Since the client must have an account on the host running
the server does SMTP store the mail for that user per normal and then the
POP2 server access it there? Is there a standard that shows where and how
the POP2 server determines what mail is waiting? Thanks again and I apologize
for my ignorance on this subject.

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

-----------[000394][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 90 20:22:00 GMT
From:      swrinde!zaphod.mps.ohio-state.edu!mips!prls!pyramid!cromemco!tomsu@ucsd.edu  (Tom Cumming)
To:        tcp-ip@nic.ddn.mil
Subject:   netbios and unix???
Is it possible to create some kind of server running on a unix machine
so that a machine running netbios can have access to the unix file system?
Has it been done already, by who and how? If not, why not?

Please email me, thanx. 

				Tom C.

				uunet!pyramid!cromemco!tom
-----------[000395][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 90 20:48:09 GMT
From:      ftp!jbvb@BLOOM-BEACON.MIT.EDU  (James Van Bokkelen)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Where Has UDP Been Implemented?
In article <28460@cup.portal.com>, Will@cup.portal.com (Will E Estes) writes:
> On what systems is the UDP datagram currently supported, and who
> are the vendors who sell the protocol as part of some package?

Get a copy of the "DDN Implementations and Vendors Guide" from the
people at SRI (ftp from NIC.DDN.MIL or on paper).  Essentially the
only IP host systems that don't have a user-accessible UDP are
dedicated terminal concentrators, and all of those that use
nameservers necessarily contain an internal-use UDP.

> Also, given technical characteristics of each system, could UDP be
> successfully implemented on:
> 
> - Novell Netware nets running Ethernet and Arcnet
> - NetBIOS nets running token ring and Ethernet
> - LAN Manager nets running Ethernet
> - Appletalk nets running Ethernet and Appletalk
> - DEC nets running DECnet
> - IBM SNA nets running LU 6.2

There are encapsulations for IP on all of these nets except for
perhaps IBM LU 6.2 on some of its media.  Thus, you can run UDP over
IP on the same hardware.  However, what you are describing are
protocol stacks, and Netware, NetBIOS and Appletalk, at least, have
datagram protocols of their own.  You could put IP/UDP inside the
proprietary protocol`s own datagram protocol (there are potentially
reasons for doing this, and encapsualtions have been defined for
NetBIOS and Banyan VINES) if you wanted to...



-- 
James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901
-----------[000396][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 90 21:42:12 GMT
From:      network.ucsd.edu!celit!dave@ucsd.edu  (Dave Smith)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Help: NFS Mounts over `slip' not working
In article <HWAJIN.90Mar29164218@daahoud.wrs.com> hwajin@daahoud.wrs.com (Hwa Jin Bae) writes:
 >In article <7624@celit.fps.com> dave@fps.com (Dave Smith) writes:
 >>   Possible, but unlikely.  Direct connect serial links have pretty low error
 >>   rates.  In any case, this would give you corrupt data more often than
 >>   corrupt packet headers (simple statistics, the data area is much larger than
 >>   the header area).
 >
 >2. The fact that it's more likely to have the data corrupted (because it's
 >   larger most of the time) than headers is irrelevant to the UDP checksumming
 >   which is computed over the entire packet, not just headers.  Am I missing
 >   something you're trying to say here?

If the error is in the data block transmitted (for example, the super block)
rather than the RPC header, you will see a file system error.

What he was describing was timeouts on the mount.  This could be explained,
I believe, by one of two things:  1) Corrupt RPC headers that are being
detected and discarded, or 2) timeouts on the transmission itself.  I believe
that 1 is unlikely to happen every time, but 2 is a very distinct possibility.


--
David L. Smith
FPS Computing, San Diego
ucsd!celerity!dave or dave@fps.com
"We are a bigger musical genius than any Bob Dylan" - Milli Vanilli
-----------[000397][next][prev][last][first]----------------------------------------------------
Date:      30 Mar 90 23:33:20 GMT
From:      petunia!polyslo!rnicovic@decwrl.dec.com  (Ralph Nicovich)
To:        tcp-ip@nic.ddn.mil
Subject:   Need TELNET "front end"

Dear TCP experts,

I have a computer that assumes it has a terminal directly connected
to it, but instead it is connected to a Terminal server that speaks
Telnet. The network handles the connection OK, but it is ugly to the
user, since when they connect they must blindly type some control
characters to re-paint the screen. There is no easy way for them to
logout, and the application uses some control codes of which the user
does not know. The system is our campus library catalog, which was
designed for dedicated terminals, but I wish to make it available
for network users.

My Idea is to dedicate a Unix Machine that will "front end" this
application. Basically what I have in mind is that the User TELNETS
to the Unix machine, which will automatically then TELNET to the
terminal server, issue the commands to start the Library system,
and give the user a little welcome screen with the key-maps. Also
the Unix machine would trap a special character which would cause
the connection to break down.

Does anyone have some pointers to some code that will do this,
or close to it that I can modify ?  I do not want to start
from scratch with sockets etc.. I already thought of modifying
the TELNET source, but would like to start with something a
little closer to what I need.

Ralph Nicovich
Network Engineering
Cal Poly State University
-----------[000398][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31 Mar 90 10:31 PST
From:      Michael Stein                        <CSYSMAS@OAC.UCLA.EDU>
To:        tcp-ip@NIC.DDN.MIL
Cc:        Alan Larson <LARSON@CRVAX.SRI.COM>
Subject:   re: MX Records
> Suprisingly, it is a technical error for the MXer of highest preference
> to not be the host itself.  This would result in an empty MX list after
> removing irrelevant RRs in the MXer of highest preference.  This is an
> error condition, although it is noted that "974 points out that "extremely
> persistent mail systems might want to try a delivery to REMOTE's address..."

What about the case where there are "non-internet" paths to
the host from the MXer of highest preference?
-----------[000399][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 90 06:05:48 GMT
From:      samsung!usc!skat.usc.edu!pkim@uunet.uu.net  (Philip Kim)
To:        tcp-ip@nic.ddn.mil
Subject:   Subcommand Interface for VM FTP
Some one told me there is a program(mod?) modifies the VM FTP module
so that I can call FTP from REXX.  Currently, I stack FTP commans,
then hope for the best.  Calling FTP from REXX lets me build more 
sophisticated applications and handle error correctly(I hope).

Where can I get the copy of this mod?

Please help.   Thanx

-Phlip-
-----------[000400][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31 Mar 90 11:55:32 EST
From:      "Lee C. Varian" <LVARIAN@pucc.PRINCETON.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Bitnet ftp ?
On Thu, 29 Mar 90 04:18:35 GMT Don Gilbert said:
>Can someone direct me to info about bitnet-ftp or bitftp?
>I know it exists somewhere:  a gateway that converts
>bitnet messages to ftp calls, and returns the ftp results thru
>bitnet.

Don,  BITFTP is a server provided on the Princeton University VM system
to allow BITNET/NetNorth/EARN users to ftp files from sites on the
Internet.  BITFTP currently accepts requests only via RFC822-format
mail, IBM NOTE-format mail, PROFS-format messages, or files with no
headers at all.  BITFTP currently returns the requested files as
NETDATA-format files or as mail files containing UUENCODED data.
(Since BITFTP accepts RFC822-format mail, other users such as UUCP
mail-only sites are also able to use BITFTP to retrieve ftp files.)

For more details on the use of BITFTP, send a mail message to BITFTP
containing a single line in the message of HELP.  The address for
BITFTP is BITFTP@PUCC (BITNET) or bitftp@pucc.princeton.edu (Internet).
  Lee Varian
  Princeton University
-----------[000401][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31 Mar 90 15:50:33 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   re: MX Records

> Suprisingly, it is a technical error for the MXer of highest preference
> to not be the host itself.  This would result in an empty MX list after
> removing irrelevant RRs in the MXer of highest preference.  This is an
> error condition, although it is noted that "974 points out that "extremely
> persistent mail systems might want to try a delivery to REMOTE's address..."

This summary isn't correct.

The correct statement is that it is an error for the most preferred MX
to try to use the MX system to figure out where to deliver the message.
The reasons for this rule are pretty clear -- if the most preferred MX
is asking the MX system for information, then either the most preferred
MX has broken configuration information, or the MX data in the DNS is
busted.  In either case, the most preferred MX ought to get upset so
a human gets the problem fixed.

Note this places no restrictions on the most preferred MX using local
information, or information from networks other than the Internet, to
deliver the message.

Craig
-----------[000402][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31 Mar 90 15:53:13 -0500
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   re: MX Records

> Suprisingly, it is a technical error for the MXer of highest preference
> to not be the host itself.  This would result in an empty MX list after
> removing irrelevant RRs in the MXer of highest preference.  This is an
> error condition, although it is noted that "974 points out that "extremely
> persistent mail systems might want to try a delivery to REMOTE's address..."

This summary isn't correct.

The correct statement is that it is an error for the most preferred MX
to try to use the MX system to figure out where to deliver the message.
The reasons for this rule are pretty clear -- if the most preferred MX
is asking the MX system for information, then either the most preferred
MX has broken configuration information, or the MX data in the DNS is
busted.  In either case, the most preferred MX ought to get upset so
a human gets the problem fixed.

Note this places no restrictions on the most preferred MX using local
information, or information from networks other than the Internet, to
deliver the message.

Craig

PS: At the risk of blowing my own horn, I'd like to encourage folks who are
working with MX records to read RFC 974.  My reviewers and I tried hard
to make it short, simple and clear about the rules and all their subtleties
-----------[000403][next][prev][last][first]----------------------------------------------------
Date:      Saturday, 31 March 1990 15:45:53 EST
From:      Gene.Hastings@boole.ece.cmu.edu
To:        netcom!netcom.uucp!schang@apple.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: getting on internet
Call the NNSC (NSF Network Service Center) at 617-497-3400 /
nnsc@nnsc.nsf.net and ask them what regional networks serve your area.

Gene

-----------[000404][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31 Mar 90 20:30 PST
From:      Denis DeLaRoca (213) 825-4580        <CSP1DWD@OAC.UCLA.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   DNS mess with NIC losing 10.0.0.1 address
Most of the hosts in our local domain didn't take kindly to the NIC
losing its 10.0.0.51 address, they continue to cache that information.
I even found some hosts running Name Servers that think that the NIC
has only what it used to be its Arpanet address?

I am curious as to how much better is the rest of the world doing? I
just checked the DNS over at usc.edu, and it is currently caching the
obsolete NIC entry. The Name Servers over at isi.edu, however, do
reflect the new NIC configuration!

-- Denis



-----------[000405][next][prev][last][first]----------------------------------------------------
Date:      Sat, 31 Mar 90 20:42:30 PST
From:      cire|eric <cire@cisco.com>
To:        Marci Kennedy <marci@aretha.franklin.uga.edu>
Cc:        TCP-IP@NIC.DDN.MIL
Subject:   Re: Problems with AIX "illegal protocols" ?

>> >From TCP-IP-RELAY@NIC.DDN.MIL  Sat Mar 31 09:52:07 1990
>> Date: Thu, 29 Mar 90 07:09:36 EST
>> From: Marci Kennedy <marci@aretha.franklin.uga.edu>
>> To: TCP-IP%SRI-NIC.ARPA@uga.cc.uga.edu
>> Subject: Re: Problems with AIX "illegal protocols" ?
>> 
>> I don't know, but it is worrisome.  Perhaps you should pass this information
>> on to Kurt Jansen, who's boss is planning to invest heavily in the new
>> RISC (risk?) product from IBM.  Perhaps Schaffer can bring some pressure
>> to bare on the SE IBM group that will have positive repercussions.
>> 
>>                                -- Marci


I fail to see why this is an IBM problem.  Its the HP machine that is
dieing.  Because it doesn't for whatever reason handle an unknown
protocol type properly.  IBM is perfectly free to use an unused code
for whatever.  Sure at some point they should get it registered but
that doesn't make it their problem.  It is HP's and they should
be contacted.

-c
cisco

(former HP employee)
-----------[000406][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 90 16:55:32 GMT
From:      LVARIAN@PUCC.PRINCETON.EDU ("Lee C. Varian")
To:        comp.protocols.tcp-ip
Subject:   Re: Bitnet ftp ?

On Thu, 29 Mar 90 04:18:35 GMT Don Gilbert said:
>Can someone direct me to info about bitnet-ftp or bitftp?
>I know it exists somewhere:  a gateway that converts
>bitnet messages to ftp calls, and returns the ftp results thru
>bitnet.

Don,  BITFTP is a server provided on the Princeton University VM system
to allow BITNET/NetNorth/EARN users to ftp files from sites on the
Internet.  BITFTP currently accepts requests only via RFC822-format
mail, IBM NOTE-format mail, PROFS-format messages, or files with no
headers at all.  BITFTP currently returns the requested files as
NETDATA-format files or as mail files containing UUENCODED data.
(Since BITFTP accepts RFC822-format mail, other users such as UUCP
mail-only sites are also able to use BITFTP to retrieve ftp files.)

For more details on the use of BITFTP, send a mail message to BITFTP
containing a single line in the message of HELP.  The address for
BITFTP is BITFTP@PUCC (BITNET) or bitftp@pucc.princeton.edu (Internet).
  Lee Varian
  Princeton University

-----------[000407][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 90 18:31:00 GMT
From:      CSYSMAS@OAC.UCLA.EDU (Michael Stein)
To:        comp.protocols.tcp-ip
Subject:   re: MX Records

> Suprisingly, it is a technical error for the MXer of highest preference
> to not be the host itself.  This would result in an empty MX list after
> removing irrelevant RRs in the MXer of highest preference.  This is an
> error condition, although it is noted that "974 points out that "extremely
> persistent mail systems might want to try a delivery to REMOTE's address..."

What about the case where there are "non-internet" paths to
the host from the MXer of highest preference?

-----------[000408][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 90 19:34:01 GMT
From:      sgi!vjs%rhyolite.wpd.sgi.com@ucbvax.Berkeley.EDU  (Vernon Schryver)
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Help: NFS Mounts over `slip' not working

Shrinking the clients block sizes (rsize, wsize) to 1 or 2 times the
typical SLIP MTU of 512 or 256 has made NFS/SLIP work around here.
Forgetting this adjustment makes mounts fail around here.

Some block sizes will not work with some NFS servers.  It may be best to
use reasonable powers of 2.

As others have said, one wants a small MTU to minimize the latency suffered
by interactive traffic and caused by bulk traffic.

Using small block sizes has the added benefit of reducing IP fragmentation.
Consider what happens if the send-queue in your SLIP driver tends to
overflow as you add the last of the 33 IP fragments of an 8+KB NFS UDP
packet.  Given the bad results seen with 8K block sizes and 6 IP/ether
fragments with certain PC ethernet boards, consider the results likely if
these boards are subjected to 33 back-to-back fragments.  You might be
disappointed no matter how you set timeouts or retransmissions.

The NFS protocol is not perfect, but it is not so parochial to transmit any
varient of superblocks.  You get directories, data, sym-links, and attributes.

Despite being a purveyor of SLIP and NFS, using the two together is too
wild and crazy for me.


Vernon Schryver
Silicon Graphics
vjs@sgi.com
-----------[000409][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 90 20:50:33 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: MX Records


> Suprisingly, it is a technical error for the MXer of highest preference
> to not be the host itself.  This would result in an empty MX list after
> removing irrelevant RRs in the MXer of highest preference.  This is an
> error condition, although it is noted that "974 points out that "extremely
> persistent mail systems might want to try a delivery to REMOTE's address..."

This summary isn't correct.

The correct statement is that it is an error for the most preferred MX
to try to use the MX system to figure out where to deliver the message.
The reasons for this rule are pretty clear -- if the most preferred MX
is asking the MX system for information, then either the most preferred
MX has broken configuration information, or the MX data in the DNS is
busted.  In either case, the most preferred MX ought to get upset so
a human gets the problem fixed.

Note this places no restrictions on the most preferred MX using local
information, or information from networks other than the Internet, to
deliver the message.

Craig

-----------[000410][next][prev][last][first]----------------------------------------------------
Date:      31 Mar 90 20:53:13 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: MX Records


> Suprisingly, it is a technical error for the MXer of highest preference
> to not be the host itself.  This would result in an empty MX list after
> removing irrelevant RRs in the MXer of highest preference.  This is an
> error condition, although it is noted that "974 points out that "extremely
> persistent mail systems might want to try a delivery to REMOTE's address..."

This summary isn't correct.

The correct statement is that it is an error for the most preferred MX
to try to use the MX system to figure out where to deliver the message.
The reasons for this rule are pretty clear -- if the most preferred MX
is asking the MX system for information, then either the most preferred
MX has broken configuration information, or the MX data in the DNS is
busted.  In either case, the most preferred MX ought to get upset so
a human gets the problem fixed.

Note this places no restrictions on the most preferred MX using local
information, or information from networks other than the Internet, to
deliver the message.

Craig

PS: At the risk of blowing my own horn, I'd like to encourage folks who are
working with MX records to read RFC 974.  My reviewers and I tried hard
to make it short, simple and clear about the rules and all their subtleties

END OF DOCUMENT