The 'Security Digest' Archives (TM)

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

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

START OF DOCUMENT

-----------[000000][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 00:28:08 GMT
From:      jgong@hpccc.HP.COM (John Gong)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Traffic File?


Hello,


I had read in this notesgroup sometime back about a file from Berkeley
that had a "realistic" mix of TCP/IP traffic.  We're in the midst of 
setting up some performance tests for our routers, and this data would
be of value to us.

Can anyone provide a pointer to this information, or about other TCP/IP
test suites?


     Thanks,

John Gong  HP Corporate Telecommunications

-----------[000001][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 00:45:39 GMT
From:      jd9014@cca.ucsf.edu (Joe DeBattista)
To:        comp.protocols.ibm,comp.protocols.tcp-ip,comp.os.vms
Subject:   tn3270 for VMS systems

Greetings,
   We currently have a MicroVax II (running MicroVMS 4.5, with an
Excelan card, running the EXOS TCP/IP software) and an IBM
mainframe (an IBM 4381, running VM/HPO 5.0, CMS, MVS/SP and the IBM
TCP/IP FAL code).  Our Unix machines communicate with the IBM on
our LAN ethernet via the tn3270 program, which permits a full-screen, 
full duplex connection, emulating an IBM 3270 terminal.  Is there 
such an animal for VMS systems?  I'm interested in both public domain
programs, and commercial products.  Thanks very much.
-- 
                            Joe DeBattista
                            UCSF Computer Center
                   BITNET:  jd9014@ucsfcca
                   DOMAIN:  jd9014@cca.ucsf.edu

-----------[000002][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 1989 05:34-EDT
From:      CERF@A.ISI.EDU
To:        jupiter!karn@FLASH.BELLCORE.COM
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems
Phil,

isn't it a consequence of your suggestion that no IP packet
could be broadcast outside of a given network since packets
lose their link levels as they move through a gateway?

Vint
-----------[000003][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 02:06:07 GMT
From:      lhl@CS.WISC.EDU (L.H. Landweber)
To:        comp.protocols.tcp-ip
Subject:   SIGCOMM '89


		 ADVANCE PROGRAM FOR ACM SIGCOMM '89
	      COMMUNICATIONS ARCHITECTURES AND PROTOCOLS
		AUSTIN, TEXAS, SEPTEMBER 19 - 22, 1989

---------------------------------------------------------------------------
		      ADVANCE REGISTRATION FORM

Please send this form and a check or money order (in U.S. dollars, no
purchase orders) payable to SIGCOMM '89, to:

SIGCOMM '89
Department of Computer Sciences
Taylor Hall 2.124
University of Texas at Austin
Austin, Texas 78712-1188
(512) 471-7316

[] SYMPOSIUM (9/20 - 9/22)
		Before 9/5/89		After 9/5/89
Member		[] $200			[] $250
Non-Member	[] $250			[] $300
Student		[] $100			[] $100

[] TUTORIAL 1 (9/19) (High-Speed WANs)
[] TUTORIAL 2 (9/19) (FDDI)
		Before 9/5/89		After 9/5/89
Member		[] $150			[] $200
Non-Member	[] $200			[] $250
Student		[] $100			[] $100

DIETARY RESTRICTIONS
[] Kosher	[] Vegetarian

Special meals can be guaranteed only for those who register in advance.


Name:
Affiliation:
Address:
Phone#:
EMAIL Address:
ACM or SIGCOMM Member #:

The symposium and tutorials will be conducted at the Austin Marriott
at the Capitol.  Registration fee includes Proceedings; reception on
Tuesday; lunch on Wednesday and Thursday; and Thursday evening
banquet.  Student registration includes all but the Thursday evening
banquet. The tutorial registration fee includes lunch on Tuesday.

Requests for refunds will be honored until September 5, 1989.

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

		       HOTEL REGISTRATION FORM

Please send this form to:

Austin Marriott at The Capitol
701 East 11th Street
Austin, Texas 78701
(512) 478-111

Reservations must be received by September 5, 1989 to guarantee the
following rates:

[] Single $55 + tax	[] Double $62 + tax

Name:
Address:
Phone#:
Arrival date & time:
Departure date:
Sharing room with:

All rooms will be held until 6 pm the day of arrival without
deposit/guarantee.  For arrivals later than 6 pm, please guarantee to
a major credit card.

Card Name & Number:
Expiration date:
Name on card:
Signature:

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

The symposium provides an international forum for the presentation and
discussion of communication network applications and technologies, as
well as recent advances and proposals on communication architectures,
protocols, algorithms, and performance models.

			      TUTORIALS
			Tuesday, September 19

9:00 am - 5:00 pm TUTORIAL 1
"High-Speed, Wide Area Networks," M. El Zarki, University of
Pennsylvania,  and N. F. Maxemchuk, AT&T Bell Laboratories.

This course will be divided into two parts, routing and flow control
on high speed networks, and  congestion and error control in ATM
networks. In the first part of the course, routing and flow control
mechanisms that have been used in local, metropolitan, and wide-area
networks will be surveyed, and a classification scheme will be
described. The objective is to determine which of these techniques may
be applicable to high-speed, wide area networks.  The second part of
the course focuses on ATM, the proposed technique for Broadband ISDN.
The concepts of ATM transmission are first introduced and will include
an overview of fast packet switching architectures.  This is then
followed by a discussion on the performance of error schemes and
congestion control mechanisms.

OUTLINE

Introduction to high speed networks:  characteristics and performance issues
Overview of past and current routing schemes
Overview of past and current flow control mechanisms
Definition of a new classification scheme for routing and flow control
  algorithms
Predictions for high speed networks
Concepts of ATM transmission
Overview of fast packet switching
Performance of error control schemes in high speed networks
Issues in congestion control for high speed networks
Discussion of some recent proposals for error and congestion control

BIOGRAPHIES

Nick F. Maxemchuk is currently the head of the distributed systems
research department at AT&T Bell Laboratories.  He received a B.S.E.E.
from CCNY, and a masters and Ph.D. from the University of
Pennsylvania.  He has worked in the area of data networking since
1968.  During that time he has been at RCA Labs, on the adjunct
faculty of the University of Pennsylvania and Columbia University, editor
of data communications for IEEE Transactions on Communications, on the
editorial board of JSAC, and an advisor on data networking for the UN,
RADC, ITRC, and other organizations.

Magda El Zarki is an assistant professor at the University of
Pennsylvania in the Department of Electrical Engineering, where she is
doing research in telecommunications.  She received a B.E.E. from
Cairo University, and M.S. and Ph.D. degrees in Electrical Engineering
from Columbia University.  Her doctoral research focused on resource
allocation mechanisms for high speed integrated local area networks.
She has also worked as a communications network planner at Citibank in
New York and in the Columbia University Computer Communications
Research Laboratory designing and developing an integrated LAN testbed
called MAGNET.


9:00 am - 5:00 pm TUTORIAL 2
"Fiber Distributed Data Interface (FDDI)," Raj Jain, Digital Equipment
Corporation

Fiber Distributed Data Interface (FDDI) is a 100 megabits per second
fiber optic local area network (LAN) standard being developed by the
American National Standard Institute (ANSI).  The standard allows up
to 500 stations to communicate via fiber optic cables using a timed
token access protocol. Normal data traffic as well as time constrained
traffic such as voice, video, and real time applications are
supported.  All major computer vendors, communications vendors, and
telephone companies are planning to offer products supporting this
standard.

In this tutorial we will cover key aspects of FDDI such as the media
access protocol, encoding schemes, fiber cables, optical components,
and network management.  The emphasis will be on explaining the
concepts and the reasons behind various design decisions.  We will
compare various alternatives and discuss why a particular alternative
was chosen.  Known Performance and error characteristics will be
presented.  A comparison will be made with IEEE 802.5 token ring approach.

We will also discuss FDDI-II which allows circuit switched
(Isochronous) traffic on FDDI and will be used by telecommunication
industry for interconnection to ISDN networks.

OUTLINE

Introduction: Protocol layers, Types of stations
Media-Access Control (MAC):  Timed token access method
Physical Layer (PHY):  Coding, Clock synchronization
Physical Media Dependent (PMD):  Optical components
Station Management (SMT):  Topology control
Performance Analysis
FDDI-II
Comparison with IEEE 802.5

BIOGRAPHY

Raj Jain received the Ph.D. degree from Harvard University in 1978.
For the last ten years, he has been with Digital Equipment Corporation
where he has been involved in performance modeling and analysis of a
number of computer systems and networks including VAX clusters,
DECnet, and Ethernet.  Currently, he is responsible for analyzing
various design alternatives for the FDDI architecture.  He was a
visiting scholar at MIT in 1983-84, and since then has taught a
graduate course at MIT on performance analysis techniques.  He is a
Senior Member of the IEEE.

7:00 pm - 9:00 pm EVENING RECEPTION

			      SYMPOSIUM

		       WEDNESDAY, SEPTEMBER 20

8:30 am - 9:30 am SESSION 1:  Keynote Session
General Chair:  L. Landweber, University of Wisconsin
Program Chair:  M. Gouda, University of Texas

10:00 am - 12:00 pm SESSION 2:  Network Control
Chair:  D. Comer, Purdue University

"Analysis and Simulation of a Fair Queueing Algorithm," Alan Demers,
Xerox Palo Alto Research Center, Srinivasan Keshav, University of
California at Berkeley, and Scott Shenker, Xerox Palo Alto Research Center.

"Connection Caching of Traffic Adaptive Dynamic Virtual Circuits," Per
Jomer, Ericsson Programatic Sweden.

"A Hierarchical Solution for Application Level Store-and-Forward
Deadlock Prevention," Barry J. Brachman and Samuel T. Chanson,
University of British Columbia.

"Specification and Verification of Network Managers for Large
Internets," David L. Cohrs and Barton P. Miller, University of
Wisconsin at Madison.

1:30 pm - 3:00 pm SESSION 3:  Routing and Naming in Large Networks
Chair:  C. Edmondson-Yurkanan, University of Texas

"The Revised ARPANET Routing Metric," Atul Khanna and John Zinky, BBN
Communication Corporation.

"A Routing Architecture for Very Large Networks Undergoing Rapid
Reconfiguration," Joel M. Snyder, The University of Arizona.

"Descriptive Names in X.500," Gerald W. Neufeld, The University of
British Columbia.

3:30 pm - 5:00 pm SESSION 4: Local Area Networks
Chair:  S. S. Lam, University of Texas 

"X-NET: A Dual Bus Fiber-Optic LAN using Active Switches," A. E. Kamal
and B. W. Abeysundara, University of Alberta.

"AMp: A Highly Parallel Atomic Multicast Protocol," Paulo Verissimo,
Luis Rodrigues, and Mario Baptista, Instituto de Engenharia de
Sistemas e Computadores.

"Traffic Placement Policies for a Multi-Band Network," K. J. Maly, E.
C. Foudriat, D. Game, R. Mukkamala, C. M. Overstreet, Old Dominion
University.

"REXDC -- A Remote Execution Mechanism," Chi-ching Chang, Unisys Corporation.

 
5:15 pm - 6:00 pm SIGCOMM Business Meeting
Chair:  Vinton Cerf, Corp. for National Research Initiative.


			THURSDAY, SEPTEMBER 21

8:30 am - 10:00 am SESSION 5: Algorithm & Protocol Design
Chair:  A. U. Shankar, University of Maryland

"The Original Unity of Minimum Cost Spanning Tree Algorithms," Susan
M. Merrit, Pace University.

"Block Acknowledgement:  Redesigning the Window Protocol," G. M.
Brown, Cornell University, M. G. Gouda, The University of Texas at
Austin, and R. E. Miller, Georgia Institute of Technology.

"New Results on Deriving Protocol Specifications from Service
Specifications," Ferhat Khendek, Gregor von Bochmann, Universite de
Montreal, and Christian Kant, Univ. de Moncton.

10:30 am - 12:00 pm SESSION 6:  High Speed Networks
Chair:  V. Cerf, Corp. for National Research Initiative

"A High Speed Transport Protocol for Datagram/Virtual Circuit
Networks," Krishan K. Sabnani and Arun N. Netravali, AT&T Bell
Laboratories.

"Sirpent: A High-Performance Internetworking Approach," David R.
Cheriton, Stanford University.

"Group Communication in Multichannel Networks with Staircase
Interconnection Topologies," Philip K. McKinley and Jane W. S. Liu,
University of Illinois.

1:30 pm - 3:00 pm SESSION 7:  ISDN
Chair:  C. Partridge, BBN

"A Testbed for Wide Area ATM Research," David L. Tennenhouse,
Massachusetts Institute of Technology, and Ian M. Leslie, University
of Cambridge.

"Flexible Aggregation of Channel Bandwidth in Primary Rate ISDN," John
W. Burren, Rutherford Appleton Laboratory.

"Dynamic Bandwidth Management of Primary Rate ISDN to Support ATM
Access," Bhaskar R. Harita and Ian M. Leslie, University of Cambridge.

3:30 pm - 5:00 pm SESSION 8:  Panel
Chair:  L. Peterson, University of Arizona 

"Building a Global Directory Service:  Alternate Designs"
The panel will discuss the merits of several naming systems that might
be used to provide a global directory service.  The services include
X.500, the Domain Naming System, DEC's Naming Architecture, and the
Profile/UNP Naming Service.

6:00 pm EVENING BANQUET
(Cocktails, Dinner, Speaker, Awards)
Dinner Address:  "Very High-Speed Networks," Robert Kahn, Corp. for
National Research Initiative.


			 FRIDAY, SEPTEMBER 22

8:30 am - 10:00 am SESSION 9:  Routing Algorithms
Chair:  G. Brown, Cornell University

"A Unified Approach to Loop-Free Routing using Distance Vectors or
Link States," J. J. Garcia-Luna-Aceves, SRI International.

"A Loop-Free Extended Bellman-Ford Routing Protocol Without Bouncing
Effect," Chunsiang Cheng, Ralph Riley, and Srikanta P. R. Kumar,
Northwestern University.

"A New Responsive Distributed Shortest-Path Routing Algorithm,"
Balasubramanian Rajagopalan and Michael Faiman, University of Illinois
at Urbana-Champaign.

10:30 am - 12:00 pm SESSION 10:  Internetworking and Protocol Conversion
Chair:  P. Green, IBM
 
"Deriving a Protocol Converter:  a Top-Down Method," Kenneth L.
Calvert and Simon S. Lam, The University of Texas at Austin.

"A Protocol Conversion Toolkit," Joshua Auerbach, IBM T. J. Watson
Research Center.

"Internet Routing," Thomas Narten, Purdue University.

1:30 pm - 3:00 pm SESSION 11: Protocol Testing and Validation
Chair:  K. Sabnani, AT&T Bell Laboratories 	

"An Improved Protocol Test Generation Procedure Based on UIOS," Wendy
Y. L. Chan, Son T. Vuong, and M. Robert Ito, The University of British
Columbia.

"Probabilistic Testing of Protocols," Deepinder P. Sidhu, University
of Maryland, and Chun-Shi Chang, Iowa State University.

"Protocol Validation in Complex Systems," Colin H. West, IBM Zurich
Research Laboratory.


			 CONFERENCE LOCATION

The symposium and tutorials will be conducted at the conference hotel,
the Austin Marriott at the Capitol, 701 East 11th Street, Austin,
Texas, 78701, (512) 478-1111.  All scheduled activities will be held
in the Capitol Ballroom, located on the main entrance level, 3rd floor.

The Austin Marriott at the Caiptol is located in the heart of downtown
Austin, 4 blocks from the Capitol, and just a stroll or trolly ride
from the entertainment district.  The hotel will also provide
complimentary use of recreational and health club facilities.

			    TRANSPORTATION

The Austin Marriott is located 10 minutes from the airport.  The hotel
shuttle arrives at the airport every 30 minutes during the day or can
be called with the courtesy phone in the airport lobby. Additionally,
taxi fare to the hotel is $5-8.

For conference participants driving to the Austin Marriott, take IH35
south, then exit at the Capitol exit for 11-12th Streets.  The hotel
is at the corner of East 11th and IH35 and has a complimentary parking
garage.

			       CLIMATE

Normal daily temperatures in Austin in September range from 68o to 89oF.
Measurable rain, usually in the form of thundershowers, can be
expected on one day in four.  Although Fall will officially arrive
during the conference period, expect Austin to still feel like summer
and the predominant color will be green.

			     INFORMATION

For further information about the symposium, contact:  Dr. L. H.
Landweber, General Chair, Computer Sciences Department, University of
Wisconsin, 1210 W. Dayton Street, Madison, WI  53706.  Telephone:
(608) 262-1204, EMAIL: landweber@cs.wisc.edu

CONFERENCE CHAIRS

General:  Lawrence Landweber, University of Wisconsin
Program:  Mohamed Gouda, University of Texas at Austin
Treasurer:  Ken Calvert, University of Texas at Austin
Publications:  K. F. Carbone, University of Texas at Austin
Local Arrangements:  Chris Edmondson-Yurkanan, University of Texas at Austin
Registration:  James H. Anderson, University of Texas at Austin


PROGRAM COMMITTEE

Mohamed Gouda, University of Texas, Chairman
Geoffrey Brown, Cornell University
Vinton Cerf, Corp. for National Research Initiative
Douglas Comer, Purdue University
David Farber, University of Pennsylvania
Paul Green, IBM
Raj Jain, Digital Equipment Corporation
Leonard Kleinrock, University of California
Simon Lam, University of Texas
Lawrence Landweber, University of Wisconsin
Nick Maxemchuk, AT&T Bell Laboratories
Craig Partridge, BBN Systems & Technologies Corp.
Larry Peterson, University of Arizona
Krishan Sabnani, AT&T Bell Laboratories
A. Udaya Shankar, University of Maryland
Fouad Tobagi, Stanford University

-----------[000004][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 02:52:16 GMT
From:      vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
To:        comp.protocols.tcp-ip
Subject:   Re: source code of ttcp.c

It has been observed that page misalignment substantially affects the TCP &
UDP performance of some systems.  Given common bcopy/copy{in,out}/usercopy
implementations, one would expect dramatic effects from byte-misaligment.
So there is now a version of ttcp which allows the base of the buffers to
be known and controlled in sgi/src/ttcp.shar via public ftp to sgi.com.
The shar file also contains a man-page (hacked at SGI, so all errors are
ours).  It has been submitted to comp.sources.unix.

Anyone care to say publically how many vendors are near or past 1MByte/sec?


Vernon Schryver
Silicon Graphics
vjs@sgi.com

-----------[000005][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 03:12:06 GMT
From:      geoff@FERNWOOD.MPK.CA.US (the terminal of Geoff Goodfellow)
To:        comp.protocols.tcp-ip
Subject:   THE INTERNET CRUCIBLE - Volume 1, Issue 1

THE CRUCIBLE                                                  INTERNET EDITION
an eleemosynary publication of the                                August, 1989
Anterior Technology IN MODERATION NETWORK(tm)               Volume 1 : Issue 1

			     Geoff Goodfellow
				 Moderator

   In this issue:
	A Critical Analysis of the Internet Management Situation

   THE CRUCIBLE is an irregularly published, refereed periodical on the
   Internet.  The charter of the Anterior Technology IN MODERATION NETWORK 
   is to provide the Internet and Usenet community with useful, instructive
   and entertaining information which satisfies commonly accepted standards
   of good taste and principled discourse.  All contributions and editorial
   comments to THE CRUCIBLE are reviewed and published without attribution.
   Cogent, cohesive, objective, frank, polemic submissions are welcomed.

Mail contributions/editorial comments to:	crucible@fernwood.mpk.ca.us

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

	 A Critical Analysis of the Internet Management Situation:
		       The Internet Lacks Governance


				  ABSTRACT

At its July 1989 meeting, the Internet Activities Board made some
modifications in the management structure for the Internet.  An outline of
the new IAB structure was distributed to the Internet engineering community
by Dr. Robert Braden, Executive Director.  In part, the open letter stated:

   "These changes resulted from an appreciation of our successes, especially
    as reflected in the growth and vigor of the IETF, and in rueful
    acknowledgment of our failures (which I will not enumerate).  Many on
    these lists are concerned with making the Internet architecture work in
    the real world."

In this first issue of THE INTERNET CRUCIBLE we will focus on the failures
and shortcomings in the Internet.  Failures contain the lessons one often
needs to achieve success.  Success rarely leads to a search for new
solutions.  Recommendations are made for short and long term improvements 
to the Internet.


			A Brief History of Networking

The Internet grew out of the early pioneering work on the ARPANET.  This
influence was more than technological, the Internet has also been
significantly influenced by the economic basis of the ARPANET.

The network resources of the ARPANET (and now Internet) are "free".  There
are no charges based on usage (unless your Internet connection is via an
X.25 Public Data Network (PDN) in which case you're well endowed, or better
be).  Whether a site's Internet connection transfers 1 packet/day or a 1M
packets/day, the "cost" is the same.  Obviously, someone pays for the
leased lines, router hardware, and the like, but this "someone" is, by and
large, not the same "someone" who is sending the packets.

In the context of the Research ARPANET, the "free use" paradigm was an
appropriate strategy, and it has paid handsome dividends in the form of
developing leading edge packet switching technologies.  Unfortunately,
there is a significant side-effect with both the management and technical
ramifications of the current Internet paradigm: there is no 
accountability, in the formal sense of the word.

In terms of management, it is difficult to determine who exactly is
responsible for a particular component of the Internet.  From a technical
side, responsible engineering and efficiency has been replaced by the
purchase of T1 links.

Without an economic basis, further development of short-term Internet
technology has been skewed.  The most interesting innovations in
Internet engineering over the last five years have occurred in resource
poor, not resource rich, environments.

Some of the best known examples of innovative Internet efficiency
engineering are John Nagle's tiny-gram avoidance and ICMP source-quench
mechanisms documented in RFC896, Van Jacobsen's slow-start algorithms and
Phil Karn's retransmission timer method.

In the Nagle, Jacobsen and Karn environments, it was not possible or cost
effective to solve the performance and resource problems by simply adding
more bandwidth -- some innovative engineering had to be done.
Interestingly enough, their engineering had a dramatic impact on our
understanding of core Internet technology.

It should be noted that highly efficient networks are important when
dealing with technologies such as radio where there is a finite amount of
bandwidth/spectrum to be had.  As in the Nagle, Jacobsen and Karn cases,
there are many environments where adding another T1 link can not be used
to solve the problem.  Unless innovation continues in Internet
technology, our less than optimal protocols will perform poorly in
bandwidth or resource constrained environments.

Developing at roughly the same time as Internet technology have been the
"cost-sensitive" technologies and services, such as the various X.25-based
PDNs, the UUCP and CSNET dial-up networks.  These technologies are all
based on the notion that bandwidth costs money and the subscriber pays for
the resources used.  This has the notable effect of focusing innovation to
control costs and maximize efficiency of available resources and bandwidth.
Higher efficiency is achieved by concentrating on sending the most amount
of information through the pipe in the most efficient manner thereby making
the best use of available bandwidth/cost ratio.

For example, bandwidth conservation in the UUCP dial-up network has
multiplied by leaps and bounds in the modem market with the innovation of
Paul Baran's (the grandfather of packet switching technology) company,
Telebit, which manufactures a 19.2KB dial-up modem especially optimized for
UUCP and other well known transfer protocols.  For another example,
although strictly line-at-a-time terminal sessions are less "user friendly"
than character-oriented sessions, they make for highly efficient use of
X.25 PDN network resources with echoing and editing performed locally on
the PAD.

While few would argue the superiority of X.25 and dial-up CSNET and UUCP,
these technologies have proved themselves both to spur innovation and to be
accountable.  The subscribers to such services appreciate the cost of the
services they use, and often such costs form a well-known "line item" in
the subscriber's annual budget.

Nevertheless, the Internet suite of protocols are eminently successful,
based solely on the sheer size and rate of growth of both the Internet and
the numerous private internets, both domestically and internationally.  You
can purchase internet technology with a major credit card from a mail order
catalog.  Internet technology has achieved the promise of Open Systems,
probably a decade before OSI will be able to do so.


			   Failures of the Internet

The evolution and growth of Internet technology have provided the basis for
several failures.  We think it is important to examine failures in detail,
so as to learn from them.  History often tends to repeat itself.


Failure 1:- Network Nonmanagement

The question of responsibility in todays proliferated Internet is completely
open.  For the last three years, the Internet has been suffering from
non-management.  While few would argue that a centralized czar is necessary
(or possible) for the Internet, the fact remains there is little to be done
today besides finger-pointing when a problem arises.
 
In the NSFNET, MERIT is incharge of the backbone and each regional network
provider is responsible for its respective area.  However, trying to debug
a networking problem across lines of responsibility, such as intermittent
connectivity, is problematic at best.  Consider three all too true refrains
actually heard from NOC personal at the helm:

	"You can't ftp from x to y?  Try again tomorrow, it will
	 probably work then."

	"If you are not satisfied with the level of [network] 
         service you are receiving you may have it disconnected."

	"The routers for network x are out of table space for routes,
	 which is why hosts on that network can't reach your new
	 (three-month old) network.  We don't know when the routers will
	 be upgraded, but it probably won't be for another year." 

One might argue that the recent restructuring of the IAB may work towards
bringing the Internet under control and Dr. Vinton G. Cerf's recent
involvement is a step in the right direction.  Unfortunately, from a
historical perspective, the new IAB structure is not likely to be
successful in achieving a solution.  Now the IAB has two task forces, the
Internet Research Task Force (IRTF) and the Internet Engineering Task Force
(IETF).  The IRTF, responsible for long-term Internet research, is largely
composed of the various task forces which used to sit at the IAB level.
The IETF, responsible for the solution of short-term Internet problems, has
retained its composition.

The IETF is a voluntary organization and its members participate out of
self interest only.  The IETF has had past difficulties in solving some of
the Internet's problems (i.e., it has taken the IETF well over a year to
not yet produce RFCs for either a Point-To-Point Serial Line IP or Network
Management enhancements).  It is unlikely that the IETF has the resources
to mount a concerted attack against the problems of today's ever expanding
Internet.  As one IETF old-timer put it: "No one's paid to go do these
things, I don't see why they (the IETF management) think they can tell us
what to do" and "No one is paying me, why should I be thinking about the
these things?"
 
Even if the IETF had the technical resources, many of the Internet's
problems are also due to lack of "hands on" management.  The IETF

	o  Bites off more than it can chew;
	o  Sometimes fails to understand a problem before making a solution;
	o  Attempts to solve political/marketing problems with technical
	     solutions;
	o  Has very little actual power.

The IETF has repeatedly demonstrated the lack of focus necessary to
complete engineering tasks in a timely fashion.  Further, the IRTF is
chartered to look at problems on the five-year horizon, so they are out of
the line of responsibility.  Finally, the IAB, per se, is not situated to
resolve these problems as they are inherent to the current structure of
nonaccountability.

During this crisis of non-management, the Internet has evolved into a
patch quilt of interconnected networks that depend on lots of
seat-of-the-pants flying to keep interoperating.  It is not an unusual
occurrence for an entire partition of the Internet to remain disconnected
for a week because the person responsible for a key connection went on
vacation and no one else knew how to fix it.  This situation is but one
example of an endemic problem of the global Internet.


Failure 2:- Network Management

The current fury over network management protocols for TCP/IP is but a
microcosm of the greater Internet vs. OSI debate going on in the
marketplace.  While everyone in the market says they want OSI, anyone
planning on getting any work done today buys Internet technology.  So it
is with network management, the old IAB made the CMOT an Internet
standard despite the lack of a single implementation, while the only
non-proprietary network management protocol in use in the Internet is the
SNMP.  The dual network management standardization blessings will no
doubt have the effect of confusing end-users of Internet
technology--making it appear there are two choices for network
management, although only one choice, the SNMP has been implemented.  The
CMOT choice isn't implemented, doesn't work, or isn't interoperable.

To compound matters, after spending a year trying to achieve consensus on
the successor to the current Internet standard SMI/MIB, the MIB working
group was disbanded without ever producing anything: the political climate
prevented them from resolving the matter.  (Many congratulatory notes were
sent to the chair of the group thanking him for his time.  This is an
interesting new trend for the Internet--congratulating ourselves on our
failures.)

Since a common SMI/MIB could not be advanced, an attempt was made to
de-couple the SNMP and the CMOT (RFC1109).  The likely result of RFC1109
will be that the SNMP camp will continue to refine their experience
towards workable network management systems, whilst the CMOT camp will
continue the never-ending journey of tracking OSI while producing demo
systems for trade shows exhibitions.  Unfortunately the end-user will
remain ever confused because of the IAB's controversial (and technically
questionable) decision to elevate the CMOT prior to implementation.

While the network management problem is probably too large for the SNMP
camp to solve by themselves they seem to be the only people who are
making any forward progress.


Failure 3:- Bandwidth Waste

Both the national and regional backbone providers are fascinated with T1
(and now T3) as the solution towards resource problems.  T1/T3 seems to
have become the Internet panacea of the late 80's.  You never hear anything
from the backbone providers about work being done to get hosts to implement
the latest performance/congestion refinements to IP, TCP, or above.
Instead, you hear about additional T1 links and plans for T3 links.  While
T1 links certainly have more "sex and sizzle" than efficient technology
developments like slow-start, tiny gram avoidance and line mode telnet, the
majority of users on the Internet will probably get much more benefit from
properly behaving hosts running over a stable backbone than the current
situation of misbehaving and semi-behaved hosts over an intermittent catenet.


Failure 4:- Routing

The biggest problem with routing today is that we are still using phase I
(ARPANET) technology, namely EGP.  The EGP is playing the role of routing
glue in providing the coupling between the regional IGP and the backbone
routing information.  It was designed to only accommodate a single point of
attachment to the catenet (which was all DCA could afford with the PSNs).
However with lower line costs, one can build a reasonably inexpensive
network using redundant links.  However the EGP does not provide enough
information nor does the model it is based upon support multiple
connections between autonomous systems.  Work is progressing in the
Interconnectivity WG of the IETF to replace EGP.  They are in the process
of redefining the model to solve some of the current needs.  BGP or the
Border Gateway Protocol (RFC1105) is an attempt to codify some of the ideas
the group is working on.

Other problems with routing are caused by regionals wanting a backdoor
connection to another regional directly.  These connections require some
sort of interface between the two routing systems.  These interfaces are
built by hand to avoid routing loops.  Loops can be caused when information
sent into one regional network is sent back towards the source.  If the
source doesn't recognize the information as its own, packets can flow until
their time to live field expires.

Routing problems are caused by the interior routing protocol or IGP.  This
is the routing protocol which is used by the regionals to pass information
to and from its users.  The users themselves can use a different IGP than
the regional.  Depending on the number of connections a user has to the
regional network, routing loops can be an issue.  Some regionals pass
around information about all known networks in the entire catenet to their
users.  This information deluge is a problem with some IGPs.  Newer IGPs
such as the new OSPF from the IETF and IGRP from cisco attempt to provide
some information hiding by adding hierarchy.  OSPF is the internets first
attempt at using a Dykstra type algorithm as an IGP.  BBN uses it to route
between their packet switch nodes below the 1822 or X.25 layer.

Unstable routing is caused by hardware or hosts software.  Older BSD
software sets the TTL field in the IP header to a small number.  The
Internet today is growing and its diameter has exceed the software's
ability to reach the other side.  This problem is easily fixed by
knowledgeable systems people, but one must be aware of the problem before
they can fix it.

Routing problems are also perceived when in fact a serial line problem or
hardware problem is the real cause.  If a serial line is intermittent or
quickly cycles from the up state into the down state and back again,
routing information will not be supplied in a uniform or smooth manner.
Most current IGPs are Bellman-Ford based and employ some stabilizing
techniques to stem the flow of routing oscillations due to "flapping"
lines.  Often when a route to a network disappears, it may take several
seconds for it to reappear.  This can occur at the source router who waits
for the route to "decay" from the system.  This pause should be short
enough so that active connections persist but long enough that all routers
in the routing system "forget" about routes to that network.  Older host
software with over-active TCP retransmission timers will time out
connections instead of persevering in the face of this problem.  Also
routers, according to RFC1009, must be able to send ICMP unreachables when
a packet is sent to a route which is not present in its routing database.
Some host products on the market close down connections when a single ICMP
reachable is received.  This bug flies in the face of the Internet parable
"be generous in what you accept and rigorous in what you send".

Many of the perceived routing problems are really complex multiple
interactions of differing products.


			    Causes of the Failures

The Internet failures and shortcomings can be traced to several sources:
			
First and foremost, there is little or no incentive for efficiency and/or
economy in the current Internet.  As a direct result, the resources of the
Internet and its components are limited by factors other than economics.
When resources wear thin, congestion and poor performance result.  There is
little to no incentive to make things better, if 1 packet out of 10 gets
through things "sort of work".  It would appear that Internet technology
has found a loophole in the "Tragedy of The Commons" allegory--things get
progressively worse and worse, but eventually something does get through.

The research community is interested in technology and not economics,
efficiency or free-markets.  While this tack has produced the Internet
suite of protocols, the de facto International Standard for Open Systems,
it has also created an atmosphere of intense in-breeding which is overly
sensitive to criticism and quite hardened against outside influence.
Meanwhile, the outside world goes on about developing economically viable
and efficient networking technology without the benefit of direct
participation on the part of the Internet.

The research community also appears to be spending a lot of its time
trying to hang onto the diminishing number of research dollars available
to it (one problem of being a successful researcher is eventually your
sponsors want you to be successful in other things).  Despite this, the
research community actively shuns foreign technology (e.g., OSI), but,
inexplicably has not recently produced much innovation in new Internet
technology.  There is also a dearth of new and nifty innovative
applications on the Internet.  Business as usual on the Internet is mostly
FTP, SMTP and Telnet or Rlogin as it has been for many years.  The most
interesting example of a distributed application on the Internet today is
the Domain Name System, which is essentially an administrative facility,
not an end-user service.

The engineering community must receive equal blame in these matters.
While there have been some successes on the part of the engineering
community, such as those by Nagel, Jacobsen and Karn mentioned above, the
output of the IETF, namely RFCs and corresponding implementations, has
been surprisingly low over its lifetime.

Finally, the Internet has become increasingly dependent on vendors for
providing implementations of Internet technology.  While this is no doubt
beneficial in the long-term, the vendor community, rather than investing
"real" resources when building these products, do little more than
shrink-wrap code written primarily by research assistants at universities.
This has lead to cataclysmic consequences (e.g., the Internet worm
incident, where Sendmail with "debug" command and all was packaged and
delivered to customers without proper consideration).  Of course, when
problems are found and fixed (either by the vendor's customers or software
sources), the time to market with these fixes is commonly a year or longer.
Thus, while vendors are vital to the long-term success of Internet
technology, they certainly don't receive high marks in the short-term.


			       Recommendations

Short-term solutions (should happen by year's end):

In terms of hardware, the vendor community has advanced to the point where
the existing special-purpose technologies (Butterfly, NSSs) can be replaced
by off-the-shelf routers at far less cost and with superior throughput and
reliability.  Obvious candidates for upgrade are both the NSFNET and
ARPANET backbones.  Given the extended unreliability of the mailbridges,
the ARPA core is an immediate candidate (even though the days of net 10 are
numbered).

In terms of software, ALL devices in the Internet must be network
manageable.  This is becoming ever more critical when problems must be
resolved.  Since SNMP is the only open network management protocol
functioning in the Internet, all devices must support SNMP and the Internet
standard SMI and MIB.

Host implementations must be made to support the not-so-recent TCP
enhancements (e.g., those by Nagle, Jacobsen and Karn) and the more
recent linemode TELNET.

The national and regional providers must coordinate to share network
management information and tools so that user problems can be dealt with in
a predictable and timely fashion.  Network management tools are a big help,
but without the proper personnel support above this, the benefits can not
be fully leveraged.

The Internet needs leadership and hands-on guidance.  No one is seemingly
in charge today, and the people who actually care about the net are pressed
into continually fighting the small, immediate problems.  

Long-term solutions:

To promote network efficiency and a free-market system for the delivery of
Internet services, it is proposed to switch the method by which the network
itself is supported.  Rather than a top-down approach where the money goes
from funding agencies to the national backbone or regional providers, it is
suggested the money go directly to end-users (campuses) who can then select
from among the network service providers which among them best satisfies
their needs and costs.

This is a strict economic model: by playing with the full set of the laws of
economics, a lot of the second-order problems of the Internet, both present
and on the horizon, can be brought to heel.  The Internet is no longer a
research vehicle, it is a vibrant production facility.  It is time to
acknowledge this by using a realistic economic model in the delivery of
Internet services to the community (member base).

When Internet sites can vote with their pocketbooks, some new regionals
will be formed; some, those which are non-performant or uncompetitive, will
go away; and, the existing successful ones will grow.  The existing
regionals will then be able to use their economic power, as any consumer
would, to ensure that the service providers (e.g., the national backbone
providers) offer responsive service at reasonable prices.  "The Market" is
a powerful forcing function: it will be in the best interests of the
national and regional providers to innovate, so as to be more competitive.
Further, such a scheme would also allow the traditional telecommunications
providers a means for becoming more involved in the Internet, thus allowing
cross-leverage of technologies and experience.

The transition from top-down to economic model must be handled carefully,
but this is exactly the kind of statesmanship that the Internet should
expect from its leadership.
-------

-----------[000006][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 08:52:00 EDT
From:      "VAXB::DBURKE" <dburke%vaxb.decnet@nusc-npt.navy.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   NFS assistance needed, PLEASE!
Date sent:  1-SEP-1989 08:51:31 

Hello,
	I'm have been playing with NFS on our VAX (VMS,WOLLONGONG), and I am 
curious about something.  I can "publish" a VAX disk to be shared bye SUNs and 
PCs, but how do I share SUNs and PCs disks with the VAX? (or is it possible).

The ultimate goal is to share a PC based CD ROM DRIVE with the VAX.


ANY HELP IS APPRECIATED, and results will be summarized on 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)      ||         //       ||_____||
================================================================================

-----------[000007][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 07:06:23 GMT
From:      OLE@CSLI.STANFORD.EDU (Ole J. Jacobsen)
To:        comp.protocols.tcp-ip
Subject:   It was twenty years ago today

On this day in 1969: IMP 1 was air-shipped from BBN to UCLA where it soon
started passing bits to its fellow IMPs at UCSB, SRI and UTAH, forming
the original ARPANET.

Ole
-------

-----------[000008][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 07:23:02 GMT
From:      af%sei.ucl.ac.be@CUNYVM.CUNY.EDU ("Alain FONTAINE ", Postmaster - NAD)
To:        comp.protocols.tcp-ip
Subject:   Three letters country codes

On Wed, 30 Aug 89 23:16:28 GMT Daniel Ehrlich said:
>
>Are there not also three letter ISO codes for countries?  I was under
>the impression that either the two letter or the three letter code
>would work.  Maybe Austria should use the three letter code instead of
>`at'.  Just a thought passing through a fogged mind.
>
ISO is currently discouraging the use of the three letter codes, and is
considering dropping them entirely in the future.         /AF

-----------[000009][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 07:54:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP close connection TIME_WAIT ?

Phil and Sandy have done a good job of explaining the mechanism
and rationale for TIME_WAIT. During the design phase of TCP,
tremendous effort was put into exploring, through case
analysis, various sequences of events in various orders. 

The "two armies" problem is also called the Byzantine
Generals problem in the literature on synchronization.
There are some wonderfully complicated variations in
which there are more than two generals and some of them lie.

In any case, no amount of waiting and acking will guarantee
anything - but the states are there to reduce the possibility
that a successful session is considered a failure for lack
of an ACK. Generally, though, such designs fail safe in that
a truly unsuccessful session is not accidently considered
successful though a successful one may be mislabelled a
failure.

Vint

-----------[000010][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 09:34:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems

Phil,

isn't it a consequence of your suggestion that no IP packet
could be broadcast outside of a given network since packets
lose their link levels as they move through a gateway?

Vint

-----------[000011][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 11:28:54 GMT
From:      wasc@cgch.UUCP (Armin Schweizer)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   DoD --> CMOT and SNMP



From one of our network devices suppliers I got the information,
that the DoD will request from all suppliers, that their
respective products support CMOT. 
I did not hear the same for SNMP. Is this valid for SNMP too?

What are the advantages of CMOT compared with SNMP, which
make the DoD chose CMOT as their favorite network management
vehicle? (Both, CMOT and SNMP use the same management information
base!?)

Who knows of or runs a CMOT implementation? I would like
to have a direct contact.

kind regards
armin


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

-----------[000012][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 12:20:00 GMT
From:      LANDON@ENR.Prime.COM
To:        comp.protocols.tcp-ip
Subject:   Re: pc tcp/ip in microsoft windows 386


This is a short thread from comp.windows.ms which should help answer
your question.

/* Written  2:52 pm  Jul 15, 1989 by usenet@cps3xx.UUCP in ENR:comp.windows.ms */
/* ---------- "MS-Windows and networking software" ---------- */
Over the past several months, I have seen a few postings describing
how it is impossible to run networking applications under MS Windows.
Several people  found various networks incompatible with Windows,
evidently due to Windows' habit of stealing the timer interrupt.

Well, I have found that Windows and the networking kernel from
FTP Software, Inc. get along fine.  I have been able to run several
copies of TNGLASS (dumb but well-behaved TELNET implementation that
comes with the TCP/IP suite from FTP Software) simultaneously, each in
its own window, with no problem.
This is under Windows/286 v. 2.10, and FTP Software's
PC/TCP version 2.  (I've heard that versions 1.x of FTP Software's
stuff don't get along with Windows.)

FTP Software's Development Kit for DOS includes a socket library;
I assume this means one could write socket applications under Windows.

I hope to test this assumption soon; meanwhile, I'd like to hear
from anyone who knows more about this.

Mark Riordan   Mich State Univ   riordanmr@clvax1.cl.msu.edu
/* End of text from ENR:comp.windows.ms */


/* Written 11:08 am  Aug 12, 1989 by LANDON@ENR.Prime.COM in ENR:comp.windows.ms */
>Well, I have found that Windows and the networking kernel from
>FTP Software, Inc. get along fine.

I can verify this with Windows/386.  Seemed MicroSoft nor FTP could
predict whether Windows/386 would work at all within a Windows
application.  FTP said that it wasn't possible to run their
Internet applications from a DOS Window in Win/386.  This is due to
applications running in a new virtual machine (DOS Window) not being
to use the FTP resident kernel correctly (though TSRs are supposed
to be replicated in new virutal machines.)  The question was whether
a Windows application coming up in the first virtual machine would
operate correctly.  The answer is yes - I've created a client which
can talk TCP or UDP from a Windows/386 application.

>FTP Software's Development Kit for DOS includes a socket library;
>I assume this means one could write socket applications under Windows.

It is true, I've tested it.

I haven't done extensive application programming to really work it over,
but have done enough to verify that it works.

Landon Cox
landon@enr.prime.com
/* End of text from ENR:comp.windows.ms */

-----------[000013][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 12:52:00 GMT
From:      dburke%vaxb.decnet@NUSC-NPT.NAVY.MIL ("VAXB::DBURKE")
To:        comp.protocols.tcp-ip
Subject:   NFS assistance needed, PLEASE!

Date sent:  1-SEP-1989 08:51:31 

Hello,
	I'm have been playing with NFS on our VAX (VMS,WOLLONGONG), and I am 
curious about something.  I can "publish" a VAX disk to be shared bye SUNs and 
PCs, but how do I share SUNs and PCs disks with the VAX? (or is it possible).

The ultimate goal is to share a PC based CD ROM DRIVE with the VAX.


ANY HELP IS APPRECIATED, and results will be summarized on 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)      ||         //       ||_____||
================================================================================

-----------[000014][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Sep 89 17:45:29 EDT
From:      Bruce Crabill <BRUCE@UMDD.UMD.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: Broadcast flag
I think the use of a flag that is set based on network level addressing
has validity.  This is not to say that you should not use the IP broadcast
format for outgoing traffic, but using network level broadcast information
can be very useful in preventing broadcast storms.  Several years ago, I
added this very mechanism to the TCP/IP software that we use on our IBM
mainframes.  Basically, each of the network drivers will set a flag in
the packet buffer for incoming packets if the driver detects that it
received the packet as the result of a broadcast.  Later on, IP checks
this flag if it is about to forward a packet.  If it is on, it drops the
packet.  I can see the network destination address on all the currently
supported Ethernet/Pronet drivers, so everything works.  If I had a
network interface where I couldn't get to the network destination
address for incoming packets, I would probably also add an additional
check at the IP level using the IP broadcast format (I probably ought
to do that anyway).  I don't currently support broadcasts over point-to-
point links (I have mixed feelings about this).

                                       Bruce
-----------[000015][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 14:12:44 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Encore Annex Terminal server dies as NSFNET grows.

For all you lucky folks with the above box on your network.

The Internet has reached a point where if you share the routing
information with one of these boxes it will run out of memory and
quit.  The Annex, not the network.  This Annex processes RIP messages
with the BSD 'routed' application.  Apparently, one cannot substitute a
default static route to a smart gateway for 'routed'.  Routed cannot be
turned off.

We have always indicated to our host administrators that running routed
in our environment was not a good idea.  Instead, in our network a
simple static route to a smart gateway is sufficient.

Encore has been informed.

Phil Wood,  cpw@lanl.gov

-----------[000016][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 14:22:50 GMT
From:      kasten@interlan.interlan.COM (Frank Kastenholz)
To:        comp.protocols.tcp-ip
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems

The use of an indication passed up from the datalink layer that indicates
whether the packet was sent to the datalink broadcast or not, while useful,
does not cover the entire problem. There are network configurations where, in 
effect, you do not have data link level packet addressing - for example, if
a network was built out of point to point links (slip, etc, etc). At a previous
company I worked at, we offered a product that allowed one to build TCP/IP
networks between mainframe hosts using serial point to point links. All 
addressing was carried in the IP header. ALL decisions as to the destination
of the packet were made SOLELY on the basis of the IP header.

I think that the preferred solution is to FIX the problem.

Cheers
Frank Kastenholz
Racal InterLan

-----------[000017][next][prev][last][first]----------------------------------------------------
Date:      Fri, 1 Sep 89 21:40:26 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        tcp-ip@nic.ddn.mil
Subject:   Re:  DoD --> CMOT and SNMP
(Sorry.  I intended to send this to the entire list. DHC)

	From dcrocker Fri Sep  1 21:28:53 1989
	From: Dave Crocker <dcrocker>
	Subject: Re:  DoD --> CMOT and SNMP
	To: mcsun!cernvax!cgch!wasc@uunet.uu.net
	
	The Internet Activities Board has declared SNMP and CMOT to be co-equal
	standards.  If effect, this means that they both have a stamp of approval
	from a significant "standards" body.  (For the TCP/IP technology, the
	IAB fills the kind of role that ISO and CCITT and ECMA do in various
	parts of international communities.
	
	So much for the stamp of approval.
	
	Your question is more to the point and asks about actual support by
	vendors.  (A nicely practical point to have concern for.)
	
	A number of companies are currently shipping products that use SNMP.
	Further, the NSFNet is managed using it.  It is my impression that virtually
	all TCP/IP vendors have announced intent to support SNMP, if they are not
	already doing so.
	
	SNMP is unique to the TCP/IP community, although it uses the OSI ASN.1
	encoding standard, for specifying the format of objects.  CMOT is derived
	from the OSI CMOT standards effort, although I am told there are some
	differences.  It is not clear to me that these differences are in the
	management protocol, itself, it does run over a modified stack of
	support protocols.  Most significantly, is uses TCP or, perhaps, UDP,
	instead of an OSI transport.  Hence, CMOT gets you closer to the future
	of OSI network management protocol details.
	
	However, there does not appear to be any vendor that currently ships
	CMOT and, therefore, there is no field (production network) experience
	using it.  While a number of vendors have announced plans to support
	CMOT, I am not aware of any official, announced, delivery dates from
	these vendors.
	
	A further point about the recent decision to make SNMP and CMOT co-equal
	standards is that their use of the Management Information Base (MIB) was
	entirely de-coupled.  While one should expect them to continue to use the
	original 100 variable, there having additional variable in common is
	problematic.  At the least, such sharing should be expected to organic or
	accidental, rather than formally enforced.  (That should be "expected to
	be organic..."  I am on a thin wire with a poor editor.)
	
	As always, I trust that others will elaborate on, as well as correct,
	the above.  Dive in!
	
	Dave Crocker
	Digital Equipment Corp.
	

P.S.  On review, I note that I did not respond to your query about 
federal requirements for CMOT support:  There is strong governmental
pressure for moving to OSI.  This is embodied in the GOSIP document.
In general, however, the requirements are careful to allow use of
alternatives.  Perhaps the most extreme way of viewing this is that a
vendor certainly cannot consider ignoring the OSI CMOT.  I am less clear
about their ability to dodge CMOT (but am sure that someone out there in
tcp-land will chime in to clarify, please?)  Enough vendors have stated
intent to support CMOT and enough are working on it, that I would expect it
to start showing up in the future.

P.P.S.  I should use this opportunity to suggest a personal bias.  It is NOT
about which protocol I prefer.  In fact, the brouhaha has, in my opinion,
distracted us from worrying about how to manage multi-administration
inter-networks.  The chosen protocol is not irrelevant to this, but my
suspicion is that we could start with a hopelessly incomplete one and 
still not know how to use it to its fullest.

That is, our general understanding and pursuit of specifying and
developing management (application) SERVICES has been quite limited
and that we would do well to focus on MIB enhancement and specification
of standard applications for management.  (I.e., focus on the bottom
and top of the management architecture.)

D/
-----------[000018][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 15:55:12 GMT
From:      bin@primate.wisc.edu (Brain in Neutral)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliability of TCP/IP

From article <3582@asylum.SF.CA.US>, by karl@asylum.SF.CA.US (Karl Auerbach):
> This brings to mind another bit of mis-information:  Seems that down
> in Los Angeles some IBM-oriented MIS group was saying, in a knowing
> authoritative voice, that Ethernet should not be used to carry
> financial information because it has collisions and drops digits.  And
> since token rings don't have collisions, they don't lose digits and
> are thus much better for moving critical data!

Gosh!  You mean... that *isn't true*?!?

-----------[000019][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 19:37:14 GMT
From:      amanda@intercon.uu.net (Amanda Walker)
To:        comp.protocols.tcp-ip,comp.protocols.appletalk
Subject:   Announcing 'IPTalk' mailing list

I have just created a mailing list for the discussion of issues relating
to running AppleTalk protocols over IP networks.  These issues include but
are not limited to:

 - Encapsulation techniques
 - Routing issues
 - Broadcast and name binding issues

and so on.  The goal of this list is to hash out a draft RFC.

Submissions should be sent to "iptalk@intercon.uu.net".  Requests to be
added or deleted should be sent to "iptalk-request@intercon.uu.net".

Usenet users may find the addresses "...!uunet!intercon!iptalk" and
"...!uunet!intercon!iptalk-request" to be more acceptable to old mailers.

This list is not moderated, but since we only poll our mail connection
approximately hourly, there will be a little bit of latency before messages
get redistributed.

--
Amanda Walker
InterCon Systems Corporation

amanda@intercon.uu.net    |    ...!uunet!intercon!amanda

-----------[000020][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 19:45:34 GMT
From:      medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: Using the 4.2 broadcast addr with 4.3 systems


Vint, I feel the same way as Phil does.  If you get a packet recieved 
via link level broadcast, you should NEVER forward it.  If it is a packet
that is trying to do directed broadcast (always questionable in 
my opinion), then that packet should have been unicast to the
gateway in question, not broadcast.  If you do things this way, you
stomp on almost all the broken cases, and still have the flexibility 
to do directed broadcast, if you think this is a good thing.  

In most implementations that don't support this, you'd probably end up
modifying device drivers, but I feel this is well worth it.  The reason 
we have so many problems with broadcasts in that in most implementations,
you end up throwing away info you hear at layer 2, and then trying
to make up for it by using some incomplete hueristic at layer 3.  This
is a case where violating layering by passing info from layer 2 to layer
3 wins big.

					Thanks,
					   Milo

-----------[000021][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 19:48:00 GMT
From:      YEHAVI@HUJIVMS.BITNET (Yehavi Bourvine +972-2-584279)
To:        comp.protocols.tcp-ip
Subject:   Announcing: NJE over TCP (VMnet protocol) for VAX/VMS systems.




                 HUJI-NJE version 1.3 for VAX/VMS systems
                    (Unix will support in the future)
                     emulating the BITNET-II protocol

                           Product description


       HUJI-NJE is a program written for VAX/VMS and Unix  systems  (the
  latter  is  a limited capability version) which connects these systems
  to the RSCS/NJE network.  The program can send and receive mail, files
  (punch, print, netdata), intercative messages and commands.  Supported
  carriage controls are:  for outgoing files:  ASA (both  in  PRINT  and
  NetData  with  CC), punch and normal NetData.  For incoming files also
  machine carriage-control is  supported,  which  is  converted  to  ASA
  during the reception process.

       The VAX/VMS version works in cooperation with the HUyMail  mailer
  which  prepares  the  files  for the NJE program and accepts mails and
  files for local delivery.  The Unix version hasn't been  tied  yet  to
  the  Unix  mailer.   VAX/VMS systems are transparent if placed between
  two IBM  systems  or  compatibles.   The  Unix  system  is  not  fully
  transparent  for  files in transit (will be corrected in the future as
  demand arrise).

       The HUyMail is a store and forward mailer for  VAX/VMS.   It  can
  route  mail/files  via  the  NJE emulator, via DECnet links (including
  sending mail to VMS/MAIL user's interface), using PMDF links and  SMTP
  (EXOS,  MultiNet,  and  in  the  future DEC's TcpIp).  The mailer is a
  table driven, but can query name server for MX and A records.

       The VAX/VMS NJE emulator supports the following  type  of  links:
  BiSync  via  a DMF or DMB card, TcpIp using EXOS and MultiNet packages
  (VMnet  version  2),  Async  terminal  lines  (not  useful  on  loaded
  systems), and DECnet links.  The Unix version supports only TCP links.
  We expect to support DEC's TcpIp package in the future.
  Note:  Currently Wollogong and MultiNet are  compatible  at  the  $QIO
  level;  as  long  as  this compatibility exists, the binary can be run
  using Wollogong TcpIp package also.
  The program has a limit of 255 lines; however, most machines will  not
  be  able  to  support  more than one or two links...  A VAX-11/750 can
  support up to one BSC link and one DECnet link with small buffer size.

       The emulator executes under  the  VMS  operating  system  as  two
  detached  processes (one for the NJE emulator and one for the mailer).
  Commands are given to the NJE emulator via the  VMS  standard  mailbox
  mechanism.   The  NJE  emulator needs special privileges to access the
  DMF, DMB or TcpIp (the exact privileges  are  dependent  on  the  line
  configuration used).
  The protocols emulated are:  BiSync  (over  the  DMB,  DMF  and  Async
  lines), and BITNET-II (over the TcpIp and DECnet links).

       At present, the program is useful on stand-alone machines,  since
  its behaviour in a cluster environment was not tested.  It'll probably
  run correctly with all functions  available  to  all  members  of  the
  cluster,  except from sending interactive messages and commands, which
  is limited to the  machine  on  which  the  emulator  run.   Receiving
  messages  and  mail is done via the standard VMS services, so they are
  expected to work correctly in a cluster.
  The program does not create subprocesses, thus does not take advantage
  of  SMP  machines  (but  works  correctly  on  them, as any other user
  program).


       The current version is somewhere between  RSCS  version  1.3  and
  2.1, and does not support at present the following things:
o Multiple streams.
o SYSIN files are not supported at  present.   All  files  are  sent  as
  SYSOUT (but incoming SYSIN files will be accepted).
o Segmented records.  Each part of the segmented record is received as a
  separate  record (but preserved if forwarded to another system).  This
  includes all types of files (print, punch, NetData).  This  is  not  a
  limitation  on  VMS systems, since the editor cannot handle files with
  longer lines.
o Long  records  of  sent  files  (more  than  253  characters,  locally
  originated)  are  wrapped by the mailer, and the parts of a record are
  sent as separate records.
o Not all file types are supported (for example:  disk-dump).
o Printer links are not supported, and  probably  won't  be.   They  are
  indirectly  supported  via  the  mailer,  including  ASA  and  Machine
  carriage  control  (the  latter  one  is  converted  to   ASA   during
  reception).
o There is no JNET compatibility.  No /VMSDUMP or /BINARY files  can  be
  generated or accepted, since we could not get the description of these
  files format from Joiner.  In the future, HUJI-NJE sites will be  able
  to exchange binary files between themselves.

Hardware required

     For Unix systems no hardware or software is required, since it uses
the standard Unix's TcpIp sockets.
For VMS you need DMF or DMB for the synchronous link (if  you  use  such
links).

Software required

     EXOS or MultiNet package for the TcpIp links, or none  if  you  use
only  DECnet  or  asynchronous lines.  If you use DMB you need DEC's WAN
device driver kit (which supplies the driver for the DMB).
The Unix version should work  on  any  BSD-4.2/3  compatible.   The  VMS
version  needs  VMS-4.6  or  higher (the development is done on the most
recent VMS version, so future releases might need higher VMS versions).
You need a C compiler to compile the source code, since the programs are
written  in C.  A small routine in MACRO-32 is needed if you run the DMF
or DMB sync link.
The product takes about 2,000 disk blocks (more during compilation), and
each  program  needs about 500 pages of memory to run (they can run with
300 pages, but more memory was never a problem...).

Availability

     The programs are available only  to  non-profit  organizations,  or
organizations that fullfil the EARN criteria.
The programs are given free of charge only to the  Israeli  universities
which are members of Machba.  Others will be charged a minimal licensing
and handling fee.


     The program is given as-is,  without  any  commitment  to  support.
We'll  try  to  support  it  as  time  allows.  There are known problems
(documented in the installation guide and available upon request); these
problems  are being solved, but we do not commit ourselves to fixing all
bugs.
Since no support is promised, an annual fee is not charged.  However, in
the  future,  if  a  demand  arises,  we  might charge an annual fee for
support.


Ordering

     The packages are distributed via Yissum (research  and  development
company  of  the university), but are owned and maintained by the Hebrew
University of Jerusalem.  To  get  more  information  please  write  to:
YEHAVI@HUJIVMS (on BITnet/EARN), or send mail to:
     Yehavi Bourvine
     Computation Center
     The Hebrew University of Jerusalem
     Givat-Ram
     Jerusalem, 91904
     Israel.

     Note: the Unix version is not released yet.

                                                  Yehavi Bourvine
                                                  The Hebrew University,
                                                  Computation Center

                                                  YEHAVI@HUJIVMS

-----------[000022][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 21:02:30 GMT
From:      veizades@apple.com (John Veizades)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   InterOp '89 BOF - Macintoshes in the Internet Community

Macintoshes are found in more and more installations in the Internet.  In 
response to this at InterOp '89 there will be a birds of a feather session 
on the topic of Macintoshes and the Internet environment.  This BOF will 
open discussion on how Macintoshes can be better absorbed into this 
community.  Details that will be discussed included:

KIP (tunneling of IP packets in AppleTalk)
IPTalk (tunneling of AppleTalk in IP)
MacTCP and other TCP/IP implementation for the Mac.
Macintosh applications that use TCP/IP
etc.

Representatives from Apple and other Macintosh network vendors will be 
present.  This BOF is on October 8 from 6 to 8 P.M. the location will be 
announced at the conference.

Please contact me for any additional information.

John Veizades...
Apple Computer, Inc.

veizades@apple.com
(408)974-2672

-----------[000023][next][prev][last][first]----------------------------------------------------
Date:      1 Sep 89 21:45:29 GMT
From:      BRUCE@UMDD.UMD.EDU (Bruce Crabill)
To:        comp.protocols.tcp-ip
Subject:   Re: Broadcast flag

I think the use of a flag that is set based on network level addressing
has validity.  This is not to say that you should not use the IP broadcast
format for outgoing traffic, but using network level broadcast information
can be very useful in preventing broadcast storms.  Several years ago, I
added this very mechanism to the TCP/IP software that we use on our IBM
mainframes.  Basically, each of the network drivers will set a flag in
the packet buffer for incoming packets if the driver detects that it
received the packet as the result of a broadcast.  Later on, IP checks
this flag if it is about to forward a packet.  If it is on, it drops the
packet.  I can see the network destination address on all the currently
supported Ethernet/Pronet drivers, so everything works.  If I had a
network interface where I couldn't get to the network destination
address for incoming packets, I would probably also add an additional
check at the IP level using the IP broadcast format (I probably ought
to do that anyway).  I don't currently support broadcasts over point-to-
point links (I have mixed feelings about this).

                                       Bruce

-----------[000024][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 89 01:08:26 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems


	Since Phil Karn will point it out, I will first; over such a SLIP
link, where link-level addresses are implicit, you don't have broadcasts,
anyway.
	From PK's second posting, it seems to me that he isn't so radical
as I thought in that (and I know I'll be corrected if wrong) I THINK he
was suggesting an additional flag (only) and not a replacement for IP broadcast/
multicast addressing. That seems perfectly reasonable to me and would allow
traps for "telnet <broadcast addr>" without losing anything else.

	On the topic of single IP address per host: I used to think so too,
but I suspect it would result in routing chaos and poor choices in other ways.
Multi-connected hosts would likely suffer unnecessary outages or (just as bad)
poor routing decisions (close hosts going the long way around) because of it.
Hosts on the same network, but with different network addresses would suffer
from different levels of service-- a nightmare to keep straight-- because
distant gateways have incomplete or inconsistent information about the
"different" networks.
	After all, the whole point of IP addresses is to make routing easy;
if everything else works, humans shouldn't even have to deal with them...
	Finally, directed broadcasts (again) break; suppose you have a network
where every host on it is a gateway and each's IP address is taken from its
other network. You have a network that is not addressable, so, though you
could send packets to individual hosts, you could not broadcast to all of
them with one packet, like you can now.
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000025][next][prev][last][first]----------------------------------------------------
Date:      Sat, 02 Sep 89 09:25 PDT
From:      Michael Stein                        <CSYSMAS@OAC.UCLA.EDU>
To:        tcp-ip@SRI-NIC.ARPA
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems
>        On the topic of single IP address per host: I used to
> think so too, but I suspect it would result in routing chaos
> and poor choices in other ways.  Multi-connected hosts would
> likely suffer unnecessary outages or (just as bad) poor routing
> decisions (close hosts going the long way around) because of
> it.

Really?  I always thought it was the other way around.  Right now
my TCP connection is dead if my route fails to a milti-homed host
even if another route (to a different IP address) existed since
TCP connections are bound to an IP address pair, and NOT a host.
Isn't this an "unnecessary outage"?

> Hosts on the same network, but with different network
> addresses would suffer from different levels of service-- a
> nightmare to keep straight-- because distant gateways have
> incomplete or inconsistent information about the "different"
> networks.

That's a deficiency of the current routing implementations.
("it's a routing problem, not an addressing problem").

>        After all, the whole point of IP addresses is to make
> routing easy; if everything else works, humans shouldn't even
> have to deal with them...

It seems to me that the point of IP addresses is to avoid having
to place a route in each packet, instead only one value is needed
to indentify the target host.  Again note that TCP binds
connections to IP addresses (not hosts) and each UDP packet is
also bound that way.  Why should a PARITAL path failure cause the
data to be dropped?  I think that this whole area is just one
aspect of the general "IP routing problem".

>        Finally, directed broadcasts (again) break; suppose you
> have a network where every host on it is a gateway and each's
> IP address is taken from its other network. You have a network
> that is not addressable, so, though you could send packets to
> individual hosts, you could not broadcast to all of them with
> one packet, like you can now.

What about a multi-cast group address (or whatever it's called)?
Again since each one of those hosts is on multiple "networks"
I would assume that they are ALL involved in the routing protocols
on each of their connected networks (including comparing the
metrics of each) in making their routing decisions.

All we need is a complete routing protocol.....
-----------[000026][next][prev][last][first]----------------------------------------------------
Date:      Fri,  1 Sep 89 22:48 +0300
From:      Yehavi Bourvine +972-2-584279 <YEHAVI%HUJIVMS.BITNET@CUNYVM.CUNY.EDU>
To:        INFO-VAX@SRI-KL.ARPA
Cc:        TCP-IP@NIC.DDN.MIL
Subject:   Announcing: NJE over TCP (VMnet protocol) for VAX/VMS systems.



                 HUJI-NJE version 1.3 for VAX/VMS systems
                    (Unix will support in the future)
                     emulating the BITNET-II protocol

                           Product description


       HUJI-NJE is a program written for VAX/VMS and Unix  systems  (the
  latter  is  a limited capability version) which connects these systems
  to the RSCS/NJE network.  The program can send and receive mail, files
  (punch, print, netdata), intercative messages and commands.  Supported
  carriage controls are:  for outgoing files:  ASA (both  in  PRINT  and
  NetData  with  CC), punch and normal NetData.  For incoming files also
  machine carriage-control is  supported,  which  is  converted  to  ASA
  during the reception process.

       The VAX/VMS version works in cooperation with the HUyMail  mailer
  which  prepares  the  files  for the NJE program and accepts mails and
  files for local delivery.  The Unix version hasn't been  tied  yet  to
  the  Unix  mailer.   VAX/VMS systems are transparent if placed between
  two IBM  systems  or  compatibles.   The  Unix  system  is  not  fully
  transparent  for  files in transit (will be corrected in the future as
  demand arrise).

       The HUyMail is a store and forward mailer for  VAX/VMS.   It  can
  route  mail/files  via  the  NJE emulator, via DECnet links (including
  sending mail to VMS/MAIL user's interface), using PMDF links and  SMTP
  (EXOS,  MultiNet,  and  in  the  future DEC's TcpIp).  The mailer is a
  table driven, but can query name server for MX and A records.

       The VAX/VMS NJE emulator supports the following  type  of  links:
  BiSync  via  a DMF or DMB card, TcpIp using EXOS and MultiNet packages
  (VMnet  version  2),  Async  terminal  lines  (not  useful  on  loaded
  systems), and DECnet links.  The Unix version supports only TCP links.
  We expect to support DEC's TcpIp package in the future.
  Note:  Currently Wollogong and MultiNet are  compatible  at  the  $QIO
  level;  as  long  as  this compatibility exists, the binary can be run
  using Wollogong TcpIp package also.
  The program has a limit of 255 lines; however, most machines will  not
  be  able  to  support  more than one or two links...  A VAX-11/750 can
  support up to one BSC link and one DECnet link with small buffer size.

       The emulator executes under  the  VMS  operating  system  as  two
  detached  processes (one for the NJE emulator and one for the mailer).
  Commands are given to the NJE emulator via the  VMS  standard  mailbox
  mechanism.   The  NJE  emulator needs special privileges to access the
  DMF, DMB or TcpIp (the exact privileges  are  dependent  on  the  line
  configuration used).
  The protocols emulated are:  BiSync  (over  the  DMB,  DMF  and  Async
  lines), and BITNET-II (over the TcpIp and DECnet links).

       At present, the program is useful on stand-alone machines,  since
  its behaviour in a cluster environment was not tested.  It'll probably
  run correctly with all functions  available  to  all  members  of  the
  cluster,  except from sending interactive messages and commands, which
  is limited to the  machine  on  which  the  emulator  run.   Receiving
  messages  and  mail is done via the standard VMS services, so they are
  expected to work correctly in a cluster.
  The program does not create subprocesses, thus does not take advantage
  of  SMP  machines  (but  works  correctly  on  them, as any other user
  program).


       The current version is somewhere between  RSCS  version  1.3  and
  2.1, and does not support at present the following things:
o Multiple streams.
o SYSIN files are not supported at  present.   All  files  are  sent  as
  SYSOUT (but incoming SYSIN files will be accepted).
o Segmented records.  Each part of the segmented record is received as a
  separate  record (but preserved if forwarded to another system).  This
  includes all types of files (print, punch, NetData).  This  is  not  a
  limitation  on  VMS systems, since the editor cannot handle files with
  longer lines.
o Long  records  of  sent  files  (more  than  253  characters,  locally
  originated)  are  wrapped by the mailer, and the parts of a record are
  sent as separate records.
o Not all file types are supported (for example:  disk-dump).
o Printer links are not supported, and  probably  won't  be.   They  are
  indirectly  supported  via  the  mailer,  including  ASA  and  Machine
  carriage  control  (the  latter  one  is  converted  to   ASA   during
  reception).
o There is no JNET compatibility.  No /VMSDUMP or /BINARY files  can  be
  generated or accepted, since we could not get the description of these
  files format from Joiner.  In the future, HUJI-NJE sites will be  able
  to exchange binary files between themselves.

Hardware required

     For Unix systems no hardware or software is required, since it uses
the standard Unix's TcpIp sockets.
For VMS you need DMF or DMB for the synchronous link (if  you  use  such
links).

Software required

     EXOS or MultiNet package for the TcpIp links, or none  if  you  use
only  DECnet  or  asynchronous lines.  If you use DMB you need DEC's WAN
device driver kit (which supplies the driver for the DMB).
The Unix version should work  on  any  BSD-4.2/3  compatible.   The  VMS
version  needs  VMS-4.6  or  higher (the development is done on the most
recent VMS version, so future releases might need higher VMS versions).
You need a C compiler to compile the source code, since the programs are
written  in C.  A small routine in MACRO-32 is needed if you run the DMF
or DMB sync link.
The product takes about 2,000 disk blocks (more during compilation), and
each  program  needs about 500 pages of memory to run (they can run with
300 pages, but more memory was never a problem...).

Availability

     The programs are available only  to  non-profit  organizations,  or
organizations that fullfil the EARN criteria.
The programs are given free of charge only to the  Israeli  universities
which are members of Machba.  Others will be charged a minimal licensing
and handling fee.


     The program is given as-is,  without  any  commitment  to  support.
We'll  try  to  support  it  as  time  allows.  There are known problems
(documented in the installation guide and available upon request); these
problems  are being solved, but we do not commit ourselves to fixing all
bugs.
Since no support is promised, an annual fee is not charged.  However, in
the  future,  if  a  demand  arises,  we  might charge an annual fee for
support.


Ordering

     The packages are distributed via Yissum (research  and  development
company  of  the university), but are owned and maintained by the Hebrew
University of Jerusalem.  To  get  more  information  please  write  to:
YEHAVI@HUJIVMS (on BITnet/EARN), or send mail to:
     Yehavi Bourvine
     Computation Center
     The Hebrew University of Jerusalem
     Givat-Ram
     Jerusalem, 91904
     Israel.

     Note: the Unix version is not released yet.

                                                  Yehavi Bourvine
                                                  The Hebrew University,
                                                  Computation Center

                                                  YEHAVI@HUJIVMS
-----------[000027][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 89 04:40:26 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  DoD --> CMOT and SNMP

(Sorry.  I intended to send this to the entire list. DHC)

	From dcrocker Fri Sep  1 21:28:53 1989
	From: Dave Crocker <dcrocker>
	Subject: Re:  DoD --> CMOT and SNMP
	To: mcsun!cernvax!cgch!wasc@uunet.uu.net
	
	The Internet Activities Board has declared SNMP and CMOT to be co-equal
	standards.  If effect, this means that they both have a stamp of approval
	from a significant "standards" body.  (For the TCP/IP technology, the
	IAB fills the kind of role that ISO and CCITT and ECMA do in various
	parts of international communities.
	
	So much for the stamp of approval.
	
	Your question is more to the point and asks about actual support by
	vendors.  (A nicely practical point to have concern for.)
	
	A number of companies are currently shipping products that use SNMP.
	Further, the NSFNet is managed using it.  It is my impression that virtually
	all TCP/IP vendors have announced intent to support SNMP, if they are not
	already doing so.
	
	SNMP is unique to the TCP/IP community, although it uses the OSI ASN.1
	encoding standard, for specifying the format of objects.  CMOT is derived
	from the OSI CMOT standards effort, although I am told there are some
	differences.  It is not clear to me that these differences are in the
	management protocol, itself, it does run over a modified stack of
	support protocols.  Most significantly, is uses TCP or, perhaps, UDP,
	instead of an OSI transport.  Hence, CMOT gets you closer to the future
	of OSI network management protocol details.
	
	However, there does not appear to be any vendor that currently ships
	CMOT and, therefore, there is no field (production network) experience
	using it.  While a number of vendors have announced plans to support
	CMOT, I am not aware of any official, announced, delivery dates from
	these vendors.
	
	A further point about the recent decision to make SNMP and CMOT co-equal
	standards is that their use of the Management Information Base (MIB) was
	entirely de-coupled.  While one should expect them to continue to use the
	original 100 variable, there having additional variable in common is
	problematic.  At the least, such sharing should be expected to organic or
	accidental, rather than formally enforced.  (That should be "expected to
	be organic..."  I am on a thin wire with a poor editor.)
	
	As always, I trust that others will elaborate on, as well as correct,
	the above.  Dive in!
	
	Dave Crocker
	Digital Equipment Corp.
	

P.S.  On review, I note that I did not respond to your query about 
federal requirements for CMOT support:  There is strong governmental
pressure for moving to OSI.  This is embodied in the GOSIP document.
In general, however, the requirements are careful to allow use of
alternatives.  Perhaps the most extreme way of viewing this is that a
vendor certainly cannot consider ignoring the OSI CMOT.  I am less clear
about their ability to dodge CMOT (but am sure that someone out there in
tcp-land will chime in to clarify, please?)  Enough vendors have stated
intent to support CMOT and enough are working on it, that I would expect it
to start showing up in the future.

P.P.S.  I should use this opportunity to suggest a personal bias.  It is NOT
about which protocol I prefer.  In fact, the brouhaha has, in my opinion,
distracted us from worrying about how to manage multi-administration
inter-networks.  The chosen protocol is not irrelevant to this, but my
suspicion is that we could start with a hopelessly incomplete one and 
still not know how to use it to its fullest.

That is, our general understanding and pursuit of specifying and
developing management (application) SERVICES has been quite limited
and that we would do well to focus on MIB enhancement and specification
of standard applications for management.  (I.e., focus on the bottom
and top of the management architecture.)

D/

-----------[000028][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 1989 12:00-EDT
From:      CERF@A.ISI.EDU
To:        medin@NSIPO.ARC.NASA.GOV
Cc:        jupiter!karn@FLASH.BELLCORE.COM, tcp-ip@NIC.DDN.MIL
Subject:   Re: Using the 4.2 broadcast addr with 4.3 systems
Milo,

I understand your point. Something still seems to be missing.
Suppose the intent is to do directed broadcast (we can argue
separately about whether this is a good idea - I'm prepared to
come to the conclusion that it isn't and that the intent is
better served with multicast). The target of the broadcast
may be at the far end of the Internet. One would have to
somehow identify the target net, for routing purposes, and
the also indicate that the packet is to be broadcast there.
This information needs to be contained in the destination IP
address, because that is all that survives as the packet
is encapsulation and decapsulated on its journey through
an indeterminate number of nets and routers.

The only way to achieve this is to have the destination IP
address show the target net and the "rest" show "broadcast."

If the source is on a LAN, the packet clearly should NOT
show a level two "broadcast" indication at the LAN level,
since the intent is to broadcast only at the destination.

Multicasting is more complex because the multicast address
format in IP is not network specific, so more machinery
is needed.

I agree that it is never appropriate to resend or forward
a packet marked "broadcast" at level two.

Are we in disagreement at this point?

Vint
-----------[000029][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 89 16:00:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Using the 4.2 broadcast addr with 4.3 systems

Milo,

I understand your point. Something still seems to be missing.
Suppose the intent is to do directed broadcast (we can argue
separately about whether this is a good idea - I'm prepared to
come to the conclusion that it isn't and that the intent is
better served with multicast). The target of the broadcast
may be at the far end of the Internet. One would have to
somehow identify the target net, for routing purposes, and
the also indicate that the packet is to be broadcast there.
This information needs to be contained in the destination IP
address, because that is all that survives as the packet
is encapsulation and decapsulated on its journey through
an indeterminate number of nets and routers.

The only way to achieve this is to have the destination IP
address show the target net and the "rest" show "broadcast."

If the source is on a LAN, the packet clearly should NOT
show a level two "broadcast" indication at the LAN level,
since the intent is to broadcast only at the destination.

Multicasting is more complex because the multicast address
format in IP is not network specific, so more machinery
is needed.

I agree that it is never appropriate to resend or forward
a packet marked "broadcast" at level two.

Are we in disagreement at this point?

Vint

-----------[000030][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 89 16:25:00 GMT
From:      CSYSMAS@OAC.UCLA.EDU (Michael Stein)
To:        comp.protocols.tcp-ip
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems

>        On the topic of single IP address per host: I used to
> think so too, but I suspect it would result in routing chaos
> and poor choices in other ways.  Multi-connected hosts would
> likely suffer unnecessary outages or (just as bad) poor routing
> decisions (close hosts going the long way around) because of
> it.

Really?  I always thought it was the other way around.  Right now
my TCP connection is dead if my route fails to a milti-homed host
even if another route (to a different IP address) existed since
TCP connections are bound to an IP address pair, and NOT a host.
Isn't this an "unnecessary outage"?

> Hosts on the same network, but with different network
> addresses would suffer from different levels of service-- a
> nightmare to keep straight-- because distant gateways have
> incomplete or inconsistent information about the "different"
> networks.

That's a deficiency of the current routing implementations.
("it's a routing problem, not an addressing problem").

>        After all, the whole point of IP addresses is to make
> routing easy; if everything else works, humans shouldn't even
> have to deal with them...

It seems to me that the point of IP addresses is to avoid having
to place a route in each packet, instead only one value is needed
to indentify the target host.  Again note that TCP binds
connections to IP addresses (not hosts) and each UDP packet is
also bound that way.  Why should a PARITAL path failure cause the
data to be dropped?  I think that this whole area is just one
aspect of the general "IP routing problem".

>        Finally, directed broadcasts (again) break; suppose you
> have a network where every host on it is a gateway and each's
> IP address is taken from its other network. You have a network
> that is not addressable, so, though you could send packets to
> individual hosts, you could not broadcast to all of them with
> one packet, like you can now.

What about a multi-cast group address (or whatever it's called)?
Again since each one of those hosts is on multiple "networks"
I would assume that they are ALL involved in the routing protocols
on each of their connected networks (including comparing the
metrics of each) in making their routing decisions.

All we need is a complete routing protocol.....

-----------[000031][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 89 19:49:01 GMT
From:      romkey@asylum.SF.CA.US (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Re: Using the 4.2 broadcast addr with 4.3 systems

In article <8909011945.AA00826@cincsac.arc.nasa.gov> medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) writes:
>The reason 
>we have so many problems with broadcasts in that in most implementations,
>you end up throwing away info you hear at layer 2, and then trying
>to make up for it by using some incomplete hueristic at layer 3.  This
>is a case where violating layering by passing info from layer 2 to layer
>3 wins big.

I agree. I like being able to keep around control information about
received packets. In my recent designs for IP implementations, I've
always made sure there was a way for layer 2 to mark a packet as
broadcast so layer 3 could then decide what not to do with it. I do
outgoing broadcast the same way (with a different bit). Keeping
around timestamps can also be useful.

-----------[000032][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 89 19:57:40 GMT
From:      dls@mentor.cc.purdue.edu (David L Stevens)
To:        comp.protocols.tcp-ip
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems


	Re: "what about a multicast group." You can't. That's my whole point.
Multicast, broadcast and host addresses all have an IP network part and if
it's a collection of hosts (multicast or broadcast), they have to have the
same IP network part (otherwise you can't route there!). Thus, you can't
address a set of machines on the same physical network with different IP
network parts.
	If you still can't see that, try it. Set up 3 networks, A, B and C.
The gateway on A and C have the A and C IP net numbers and are the only ones
on B; B has no IP net number. How do you address a broadcast packet for "B"
(ie, to go to both A and C gateways) in your scheme?
	And I'll turn it around, since you don't seem to agree that routing
is more of a problem with single IP addresses. What do you gain from having
IP addresses identify "machines."? Right now, I can debug routing problems
by depending on the fact that I can address individual interfaces. If you
take that away from me, shouldn't there be a reason? Further, user-level
programs like gated, can choose route advertising using correct masks [what is
the netmask on one of these proposed multi-IP-address networks?] and special
processing per interface based on high-level things, like IP network numbers,
and not low level things, like interface device numbers.
	You can (and should) already have a single hostname for the multiple
IP addresses on a multihomed host, so you can always use names or, for that
matter, pick any one of the IP addresses. What do you gain by making me lose
flexibility?
	From where I sit, it looks like a gratuitous change that would break
lots of things that you haven't thought about. Things that I haven't thought
about yet, either. And what you gain you could get (if you really wanted it)
by using the IP address you have to get a DNS canonical name and then using
the canonical name to get an IP address (not necessarily the same one you
started with). Every interface address, with this, would get you to a single of
the interface addresses and you wouldn't break all of the goodies I've grown
fond of. We'd both be happy. Right?
-- 
					+-DLS  (dls@mentor.cc.purdue.edu)

-----------[000033][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 89 21:46:23 GMT
From:      LARSON@CRVAX.SRI.COM (Alan Larson)
To:        comp.protocols.tcp-ip
Subject:   routing - very strange stuff


  IP routing has become more and more of a concern to many of us,
as routes become stranger and stranger.  Earlier this morning, we
were unable to find any routes to milnet.  Just now, I tried again,
and found that the route is, to say the least, a bit strange.

  It looks like the mailbridges are doing quite a bit of passing
the buck between each other.  I have attached some traceroute
outputs to the bottom of this message.  They were all taken in
a one minute period.

	Alan




$ multi trace nic.ddn.mil
traceroute to NIC.DDN.MIL (26.0.0.73), 30 hops max, 38 byte packet

 1: 128.18.10.254 (128.18.10.254)  10 ms  0 ms  0 ms
 2: SRI-GW.ARPA (128.18.1.1)  10 ms  0 ms  10 ms
 3: MARINA-DEL-REY-MB.DDN.MIL (10.6.0.22)  200 ms MCLEAN-MB.DDN.MIL
    (10.3.0.111)  350 ms MARINA-DEL-REY-MB.DDN.MIL (10.6.0.22)  180 ms
 4: NIC.DDN.MIL (26.0.0.73)  290 ms  240 ms  210 ms
$ 
$ multi trace nic.ddn.mil
traceroute to NIC.DDN.MIL (26.0.0.73), 30 hops max, 38 byte packet
 1: 128.18.10.254 (128.18.10.254)  10 ms  10 ms  0 ms
 2: SRI-GW.ARPA (128.18.1.1)  0 ms  10 ms  0 ms
 3: RESTON-DCEC-MB.DDN.MIL (10.6.0.20)  170 ms MOFFETT-FLD-MB.DDN.MIL
    (10.4.0.51)  250 ms  50 ms
 4: NIC.DDN.MIL (26.0.0.73)  170 ms  190 ms  150 ms
$ 
$ multi trace nic.ddn.mil
traceroute to NIC.DDN.MIL (26.0.0.73), 30 hops max, 38 byte packet
 1: 128.18.10.254 (128.18.10.254)  0 ms  10 ms  10 ms
 2: SRI-GW.ARPA (128.18.1.1)  0 ms  0 ms  10 ms
 3: MCLEAN-MB.DDN.MIL (10.3.0.111)  310 ms MOFFETT-FLD-MB.DDN.MIL
    (10.4.0.51)  120 ms MARINA-DEL-REY-MB.DDN.MIL (10.6.0.22)  140 ms
 4: NIC.DDN.MIL (26.0.0.73)  170 ms  290 ms  190 ms
$
$ multi trace nic.ddn.mil
traceroute to NIC.DDN.MIL (26.0.0.73), 30 hops max, 38 byte packet
 1: 128.18.10.254 (128.18.10.254)  10 ms  10 ms  0 ms
 2: SRI-GW.ARPA (128.18.1.1)  10 ms  10 ms  10 ms
 3: RESTON-DCEC-MB.DDN.MIL (10.6.0.20)  150 ms MARINA-DEL-REY-MB.DDN.MIL
    (10.6.0.22)  130 ms MCLEAN-MB.DDN.MIL (10.3.0.111)  310 ms
 4: NIC.DDN.MIL (26.0.0.73)  260 ms  440 ms  250 ms
$
$ multi trace nic.ddn.mil
traceroute to NIC.DDN.MIL (26.0.0.73), 30 hops max, 38 byte packet
 1: 128.18.10.254 (128.18.10.254)  10 ms  0 ms  0 ms
 2: SRI-GW.ARPA (128.18.1.1)  10 ms  0 ms  0 ms
 3: MOFFETT-FLD-MB.DDN.MIL (10.4.0.51)  90 ms RESTON-DCEC-MB.DDN.MIL
    (10.6.0.20)  160 ms MCLEAN-MB.DDN.MIL (10.3.0.111)  270 ms
 4: NIC.DDN.MIL (26.0.0.73)  160 ms  140 ms  310 ms
-------

-----------[000034][next][prev][last][first]----------------------------------------------------
Date:      2 Sep 89 23:01:39 GMT
From:      amanda@intercon.uu.net (Amanda Walker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems

In article <3842@mentor.cc.purdue.edu>, dls@mentor.cc.purdue.edu (David L
Stevens) writes:
> Multicast, broadcast and host addresses all have an IP network part and if
> it's a collection of hosts (multicast or broadcast), they have to have the
> same IP network part (otherwise you can't route there!).

Actually, from what I understand of the current state of IP multicasting,
IP multicast groups do *not* have an IP network part--they are class D
addresses.  For them to work across gateways, the gateways have to (a)
know about multicast groups and (b) have a protocol by which to communicate
current multicast routing informatin to and from other gateways.

Aside from that, I pretty much agree that "one IP address per interface"
is a reasonable thing to do.  For one thing, it lets subnetting work...

--
Amanda Walker
InterCon Systems Corporation

amanda@intercon.uu.net    |    ...!uunet!intercon!amanda
--
"The trouble with doing something right the first time is that nobody
 appreciates how difficult it was"       --Walt West

-----------[000035][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 89 06:07:12 GMT
From:      amanda@intercon.uu.net (Amanda Walker)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   IPTalk mailing list

Well, the "iptalk" has yet to have a submission (except from me) and we're
up to 42 people on it.  This leads me to make a request:

The mailing list was meant as a working group, not a way for everyone who
is interested to "keep up with what's going on."  Please don't ask to be
added to the list unless you plan to *actively* contribute to the effort of
hashing out the issues and getting an RFC together.  If all you want is
information, just keep reading news and/or the TCP/IP mailing list.  It'll
show up here, I promise.

I don't want to re-invent the point-to-point protocol discussion, folks.
I want to codify something that works well enough  for long enough that
people can actually implement it and use it.  Soon.  As in something solid
in the way of a draft RFC to talk about over Chinese food at Interop (which
is only four weeks away).

For the moment, I'll keep adding whoever asks, but if things keep going the
way they have been for the last few days, I'm going to dub this a failure,
and go back to the traditional method of setting up a private conspiracy...
1/2 :-).

--
Amanda Walker
InterCon Systems Corporation

amanda@intercon.uu.net    |    ...!uunet!intercon!amanda
--
"The trouble with doing something right the first time is that nobody
 appreciates how difficult it was"       --Walt West

-----------[000036][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 89 13:44:49 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  routing - very strange stuff

Alan,

You are seeing much the same thing as described in my Internet monthly
report for July. While I have no hard evidence and have lost direct
ARPANET connectivity formerly used to diagnose such zoo events as
EGP route churn, the characteristics of the problem appear very much
like multiple EGP routes with the same "metric," causing route changes
on every EGP update. We all know that EGP is being used as a routing
algorithm in many places in the Internet, although such was not the intent
in the design. However, considering that pragmatic fact, there are a number
of things that could be done to EGP in order to improve its "routing"
performance, some already done to at least some implementations of EGP.
I have in mind split-horizon, hold-down, hysterisis and other tricks of
the trade. The question in most minds, it seems, is whether we should go
to the trouble of doing these gruesome things as against waiting for
something better to come along. Unfortunately, this question has been in
our communal minds since 1983 and only recently has led to what appears to
be real progress in various working groups of the IETF.

Dave

-----------[000037][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 89 14:37:26 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Using the 4.2 broadcast addr with 4.3 systems

In article <8909011945.AA00826@cincsac.arc.nasa.gov> medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) writes:

   If you get a packet recieved via link level broadcast ..
   you end up throwing away info you hear at layer 2, and then trying
   to make up for it by using some incomplete hueristic at layer 3.  This
   is a case where violating layering by passing info from layer 2 to layer
   3 wins big.

But are you *really* violating layering?  All you're passing is an
indication that the packet in question was broadcast, not *how* it was
broadcast.  You can get *too* silly about layering.  After all, if you
don't pass any information at all, you have *perfect* information
hiding between layers.  :-)
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])|(70441.205@compuserve.com)|
       (Russ.Nelson@f360.n260.z1.fidonet.org)|(BH01@GEnie.com :-)

-----------[000038][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 89 22:05:50 GMT
From:      Dave_Katz@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Encore Annex Terminal server dies as NSFNET grows.

Encore has a fix that UMich was able to get in beta test.  It
allows one to turn off RIP listening via "na".

-----------[000039][next][prev][last][first]----------------------------------------------------
Date:      3 Sep 89 22:31:32 GMT
From:      pprindev@wellfleet.com (Philip Prindeville)
To:        comp.protocols.tcp-ip
Subject:   NSFnet and time sync.

Does anyone know how closely the clocks on the NSFnet routers
are synchronized?  Do they run any sort of time protocol?  Are
any tools in use that require accurate time keeping?  Such as
IP Internet Timestamp options?  Dave?  Hans-Werner?

Thanks,

-Philip

-----------[000040][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 89 00:07:44 GMT
From:      ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins)
To:        comp.protocols.tcp-ip
Subject:   rfc 647

Does anyone have RFC 647 online?  (647 Padlipsky, M.A.  Proposed
protocol for connecting host computers to ARPA-like networks via front
end processors (Not online)  1974 November 12; 20 p.)

Thanks,
Drew

-----------[000041][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 89 04:56:06 GMT
From:      medin@NSIPO.ARC.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: Using the 4.2 broadcast addr with 4.3 systems


Vint, I understand your point, and don't think we disagree.  A packet
received via link level broadcast should NEVER be forwarded.  I don't
think anyone disagrees with that.  But the only way I can think of to verify
that is to tag the packet at link layer as recieved by broadcast.

As for what happens at the remote end of the packet's travel, well, that
gets hairy.  If you support the concept if directed broadcast (which, as
I've said before, I do not), then the packet's destination IP address 
should probably be set to the all 1's network broadcast or subnet broadcast
address.  Clearly, you can't send to a subnet broadcast address without
knowing the mask, and while you there are hacks you can perform, such
as sending an ICMP netmask request message to one of the gateways on
that net (or a host for that matter), they are all inadequate.  For
one thing, you have to deal with the existance of variable length subnet
masks, and that means that there may not be one subnet mask for the entire 
network.  While this typically hasn't been the case so far, routing protocols
like OSPF are being implemented that support that functionality.  Then
you have to worry about how to find a gateway or host on the piece of plumbing
you are trying to get to, and you may not be able to figure that without
a priori knowledge...  All this means you basically have to settle for
directed network broadcast, if that.

I think all this shows is that directed broadcast is a flawed concept, at
least given the current way addressing works in the Internet.  I
think multicasting is really the right way to go, and gateway vendors
should put their emphasis into that approach, and put the issue of
directed broadcast to bed.  

All this directed broadcast discussion is really orthogonal to the 
issue of link level broadcast tagging.  You can still have directed 
broadcast even if you do link level tagging.  As far as I am concerned,
there is no way you can make sure you don't forward broadcast packets
without doing that tagging.  Gateway vendors who don't implement tagging
aren't being 1009 compliant.

						Thanks,
						    Milo

-----------[000042][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 89 05:10:35 GMT
From:      medin@NSIPO.ARC.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: Encore Annex Terminal server dies as NSFNET grows.


Phil, that's not quite true.  From na you can set an annex parameter
that shuts off routed.  The gateways file the annex downloads can contain
a static default if that's what you want.  In general, if 4.3 BSD
can do it, so can the annex...

BTW, Annexen (?) are now built by Xylogics Inc, and I've found support is
much better since they took over.

						Thanks,
 						   Milo

PS This parameter is available in R4.1 (which we run), but I'm not quite
sure how far back it goes.  If you aren't running 4.1, you should, it's
got lots of neat stuff in it...

-----------[000043][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 89 05:20:42 GMT
From:      medin@NSIPO.ARC.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: Using the 4.2 broadcast addr with 4.3 systems


Well, I think you can legitimately say that link level tagging as
we are discussing does violate layering in that it is passing info
about link level info to the network layer.  As I understand it, you can
pass all the info you want to an upper layer, as long as you
don't pass info that is only known at your layer.  Consider passing
link level MAC addresses to IP, or passing IP checksum info to the
application.  Granted, these are extreme examples, but it does make the
point.  

This is why the ISO model is a model, and should not be construed as
an implementation guide :-)...  In general, all the layers in the world
won't help you unless you use common sense.

						Thanks,
						   Milo

-----------[000044][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 89 17:33:48 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  NSFnet and time sync.

Philip,

I don't think HW watches this frequency, so I will try to explain what I
understand is their policy. The NSS' do in fact fun a (very old and hacked)
version of NTP, but chime only among themselves and a couple of handpicked
stratum-1 tickers outside net 129.140. However, they (IBM and Merit) are
not willing to support ubiquitous NTP access for fear of abuse, either in 
numbers or evil purpose. In order to encourage a more liberal agenda, I
persuaded Ford Scientific Labs to donate their GOES receiver and Fuzzball to
Merit, if only to operate as a standalone time server, but the actual
move has not occured yet. I will of course continue to pursue this agenda
and maybe someday it will happen. Meanwhile, while NTP access is blocked,
ICMP Timestamp still works. Before you get further ideas, be advised the
NSS' do not seem to be very reliable sources of synchronized time, for what
reason I can't tell. The regional Fuzzballs are much more stable and precise,
even the stratum-2 servers.

Dave

-----------[000045][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 89 18:33:32 GMT
From:      cpw%sneezy@LANL.GOV (C. Philip Wood)
To:        comp.protocols.tcp-ip
Subject:   Encore Annex problem resolved (for better or worse)

Resolution of Annex problem.

A. First a few more facts:

1.  Our network looks something like this:

		MILNET		   	  NSFNET
		  |			     |
	 	  |           LANL           |
   "LANL ->	GW1--- ---GW2-....-GWn-----cisco
    backbone"		   |        |        | <- network X
		           other lans	lan with Annex on it and
					some local gateways.

2. We treat GW1 as our smartest gateway, its the default for the nodes
   on the LANL backbone.  It knows how to get everywhere.  The cisco shares
   what routes it knows about using RIP with those that are interested on the
   LANL backbone including GW1 by broadcasting as all good rippers do.
   Unfortunately, the cisco cannot send a default route to nodes on network X
   and all it knows about to nodes on the LANL backbone using RIP.

2. The software on our Annex gets bumbed when it receives too many routes.

3. The Annex people we have talked to did not know what to do.  Although,
   I have since heard that they might be able to ship us some beta test
   software which would allow us to tell the 'routed' to not listen to
   all the routes being advertised by the cisco.  Also, replys to my
   initial message indicate that Merit and NASA have a version of Annex
   software which can be tailored to not listen to massive RIP updates.

B. What we did.

Since the users of the Annex wanted to get work done, we solved the problem
the same day I sent the original message by modifying in_proto.c on our
Sun gateways and GW1 (4.3bsd VAX) to know about the HELLO protocol and
built new kernels.  These backbone gateways run 'gated' and are configured
to do HELLO and RIP.  The cisco now uses HELLO to relay what routes it knows
about to our backbone nodes and sends a default route using RIP (metric 1) to
network X.  The Annex is happy.

Everything is hunkydory.  I learned how easy it is to configure 'gated'
to do EGP, RIP and HELLO all at once.

Thanks to all who offered suggestions.

Phil

P.S.  If you were to look at the reachablity/routing information we share
with the core or NSFnet you would(should!) only see (128.165 and 192.5.16).

-----------[000046][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 89 20:31:16 GMT
From:      pprindev@wellfleet.com (Philip Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re:  Using the 4.2 broadcast addr with 4.3 systems

At great risk of being flamed at, what do people think of the
idea of multihomed hosts advertising host routes split-horizon?

That way, if the network that host H's interface H1 goes down,
H1 will be advertised (and reachable) via interface H2..Hn.

Supposedly the number of multihomed hosts (and the number of
interfaces they have) is not a significant number (is it MKL?),
so this should not add much overhead...

-Philip

-----------[000047][next][prev][last][first]----------------------------------------------------
Date:      4 Sep 89 20:49:33 GMT
From:      pprindev@wellfleet.com (Philip Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re:  NSFnet and time sync.

Dave,

	What I had in mind was more a question of whether anyone uses
ICMP timestamps to measure network delay.  If so, then synchronization
is fairly important.  I've been playing with the idea of hacking
wiretap into ANSI-SPF, and timestamps would be a good way to divine
performance information.  However, it would require close synchro-
nization amongst the participants...

-Philip

-----------[000048][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 89 04:48:44 GMT
From:      tml@mimir.dmt.oz (Thomas Lam)
To:        comp.protocols.tcp-ip
Subject:   Reference, sample programs on Sun Network wanted

I am doing some work that involves the possible use of
the data structure, interface and routines mentioned in
the "Network implementation notes" of the SUN Network
manual. I wonder if anybody can tell me 
1. reference articles, publications etc that explains 
   in more detail than that covered in the implementation


2. how to obtain some sample programs that are coded
   at that level/layer under 4.2 BSD/SUNOS 3.5. I merely
   want to have better insight in the usage of the data
   structure, interface and routines that are in the
   implementation notes.

   Please mail me tml@mimir.dmt.oz 
   Your help is very much appreciated.
      .
Regards 

-----------[000049][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 89 08:44:46 GMT
From:      dpz@convex.com (David Paul Zimmerman)
To:        comp.protocols.tcp-ip
Subject:   spoofing KEEPALIVE

Imagine yourself in another universe, perhaps this one, where KEEPALIVE isn't
working.  Say that you open a TCP connection to a cisco terminal server, and
you specify KEEPALIVE on the socket, but the cisco end isn't keeping alive,
choosing instead to freeze up after a random, reasonably long (~hours), amount
of time.

Is this a symptom of the cisco not doing KEEPALIVEs correctly?  That's my
current suspicion.  The program looks OK to me, and cisco tech support agrees.

I'm trying to think up ways to hack around it.  There's this select() call I
use to check the readability or writability of a pty or a network socket.  By
putting a timeout on it, I guess I can just arbitrarily close and reopen the
connection to the cisco after, oh, a half hour of waiting.

Any better ideas?

					David

David Paul Zimmerman                                             dpz@convex.com
CONVEX Computer Corp                                                 convex!dpz

-----------[000050][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 89 17:34:23 GMT
From:      tcs@BRL.MIL (Terry Slattery, SECAD)
To:        comp.protocols.tcp-ip
Subject:   ttcp.c source from the source.

The source for ttcp.c, which has been asked about recently, can be obtained
from vgr.brl.mil:~ftp/pub/ttcp.c via anonymous FTP.  This is the original
unaltered version.  Note that some vendors take the liberty of modifying the
port number and flags, so if you encounter interoperability problems with
ttcp on other systems, check the options and port numbers.

At BRL, we use ttcp for more than network throughput testing.  It is
useful for moving directory hierarchies between machines where other
means would be more cumbersome:

	Dest machine:	ttcp -r -B | tar x
	Src machine:	tar cf - . | ttcp -t dest_machine

Network routing problems can often be avoided by extending this pipe to other
intermediate hosts.

	-tcs

-----------[000051][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 89 17:46:21 GMT
From:      pprindev@wellfleet.com (Philip Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re:  Does anyone use IP options?

> 	The current version of the NSC EN641 router code we have drops (not
> ignores, DROPS) packets with IP Record Route.
> 	Just to point out that even if your hosts do options, you might have
> troubles if your gateways (or someone else's) don't. Source route, record
> route, security compartment, etc. aren't very useful unless everyone you
> want to talk to and everyone in between honor them.

Version 5.10 is being prepared for release.  It includes all the options
(even MTU) except ESO/BSO.  It should be available from NSC sometime in
the next quarter.  If you have arrangements for beta-testing with NSC,
and you have an urgent need, this may be worth pursuing.

-Philip

-----------[000052][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 89 20:37:44 GMT
From:      pete@NCSC.NAVY.MIL (Fernandez)
To:        comp.protocols.tcp-ip
Subject:   NOVELL and TCP/IP

From pete Tue Sep  5 15:35:54 1989
Received: by ncscnavy.mil id AA04248; Tue, 5 Sep 89 15:35:47 CDT
Date: Tue, 5 Sep 89 15:35:47 CDT
From: pete (Fernandez)
Message-Id: <8909052035.AA04248@ncscnavy.mil>
To: pete
Status: R



1.  A Software solution is needed to allow users of the our Novell LAN
who are located remote to us access to the local LAN file
server via the DDN.  Following is an outline of what we have now in the form of
hardware and software, and what type of software is necessary to solve the
present hold-up:

2.  We have four (4) stripped-down 286 microcomputers slated to be DDN "host"
systems.  We've purchased four (4) Micom/Interlan NP600A Protocol Processors
(Intelligent Ethernet Cards with 80186 Microprocessors, 82586 LAN
co-processors, 5212K RAM, EPROM, and NP627-NW-DI5Q Intelligent TCP S/W for
Netware), one for each of the DDN host systems.   

3.  We would like each of the DDN host computers (with Intelligent Workstation)
to access our LAN File Server as a remote host for users accessing
the system via the DDN.  
Netware Login, program loading
(.EXE/.COM & .OVL) and database access would be sent over the Ethernet to the
pur File Server via netware Protocol.

4.  Despite earlier vendor claims, there currently is not any software on the
market (that we are aware of) that will allow TCP/IP remote host capability on
micros that are concurrently running Netware/DOS.  Any information on
software products that will support dual Protocol stacks (which the NP600A
does) and at the same time allow TCP/IP remote login and execution to a Netware
LAN Node would help out a great deal.  We would prefer to utilize the
intelligent work stations for both software requirements over installing two
controllers in each DDN host micro (one for the TCP/IP Protocol
requirements, one for accessing the LAN File Server).  The reason for
this approach is that the intelligent work station's processor(s) will take
some of the load off of our file server, the end result being a faster network
for all users whenever a user(s) accesses our file server via the DDN.  A
software solution that does not require more than 50-70K of memory in the host
computers would suit our needs best (to maximize the amount of free RAM for
program execution in each host computer).

4.  I thank you in advance for any assistance/direction you can give us in
solving this problem.

   Pete Fernandez
   Naval Coastal Systems Center/Code 02
   Panama City, FL 32407
   pete@ncsc.navy.mil
   (904) 234-4120; AV 436-4120

-----------[000053][next][prev][last][first]----------------------------------------------------
Date:      5 Sep 89 23:09:48 GMT
From:      jkp@cs.HUT.FI (Jyrki Kuoppala)
To:        comp.protocols.tcp-ip
Subject:   Using the domain name system for locating software

Motivated by the Internet Crucible's mention of the lack of new
applications of the Internet I'm posting this to the tcp-ip newsgroup.
I think it could well be possible to implement, but it certainly needs
more work.  A RFC should probably be written about the protocol
enhancements.

One of the biggest problems which does not only concern applications
like this is the failure of the tcp/ip protcols in general to cope
well with the situation that the Internet is a combination of several
networks which are not necessarily globally interconnected.  For
example, there already are several commercial sites to which direct
tcp/ip connections are possible only to a few hosts; yet these hosts
are also connected in the company's own tcp/ip networks.  Also, there
are some hosts / groups of hosts on Nordunet which are for some reason
or another not allowed to access the US side of the internet although
they may be allowed to access the Nordunet and European side of the
network.  The domain name system and the MX system don't offer tools
to handle situations like this which are rapidly becoming more and
more common as the network grows.

Well, here's the original document.  Take it as an idea put into words
for the first time; it may not be an ideal method but I think it could
be quite useful if implemented even in it's present form.

//Jyrki

Author: Jyrki Kuoppala (jkp@cs.hut.fi)
Last modified: Fri Aug  4 05:34:47 1989

The Software Location and Distrubution Service

or

How to Get All the Software In the World Without Knowing Where It Is

Document version 0.001


You all probably know the situation: you've got a new machine to get
up and working, or you just hear about a great program that is
available freely.  But where can you get it ?  You check your local
ftp server (if you are lucky enough to have one), then the one in your
state, then uunet.uu.net .. and you have to get dir -R from all of
them because you don't know what's the exact name of the software.
After an hour, you finally find the software; you ftp it home and
uncompress and untar it.  Then you take a look at the dates; it's from
year 1985, version 0.001.  Back to ftp'ing and consuming valuable
bandwidth from the network.

OK, so that's a bit overdoing it.  But there's got to be a better way
to do it.  I'm proposing the following solution: let's use the
Internet domain name server.  It already does quite a good job as a
very widely distributed database.  Also, it isn't confined to
resolving host names to addresses; already we have MX records to
handle sending mail.

That was the old days.

So let's take a time warp a year and a half to the future and see how
it works in the modern, well networked world (any resemblance to
persons, machines and software living or dead is purely coincidental
;-):

Let's see, I just read that emacs version 19.12 was published. Let's
install it.

jkp@sauna.hut.fi '~' 6: getsoftware -n emacs.gnu
Transferred edist-19.21.tar.Z from sauna.hut.fi, 6942321 bytes in 327 seconds.

The flag `-n' stands for newest version.

We were lucky, it was found near enough so we didn't have to wait for
it or for long because it was so near.  Of course, if the net was
up we could have gotten it anyhow even directly from it's home, but
now the transfer is not `costly' so we have good conscience because we
don't have to answer to the `The cost to get the software is 514
units and probably will be half that 10 hours from now, do you still
want to get it (y/n) ?' question.

So, it seems that others have already fetched it somewhere in or near
Finland.

Just for curiosity, let's see why we got it from sauna and who else
has it.

jkp@sauna.hut.fi '~' 7: nslookup
Default Server:  hut.fi
Address:  128.214.3.1

> set type=software
> emacs.gnu
Server:  hut.fi
Address:  128.214.3.1

emacs.gnu.software preference = 12, ftp server = prep.ai.mit.edu
emacs.gnu.software preference = 5, ftp server = freja.diku.dk
emacs.gnu.software preference = 3, ftp server = sauna.hut.fi
sauna.hut.fi     inet address = 128.214.3.119  pathname=pub/gnu/edist-19.21.tar.Z
etc.
> 

Some history about how this system was taken into use and what
caused it to evolve into the one we all know and use every day now:

Most software has some kind of central archive place / clearinghouse
for patches etc.  After all, software is generally written by someone
and even if the author doesn't have time to include bugfixes and do
work on the software, someone else usually does.  The problem was to
coordinate who is the 'owner' of the software; that is, who to send
the bug reports to and from where to get the newest version of the
software and all the 'official' bugfixes.

At first, the domain name server system wasn't be altered at all.  It
helps a lot even to know where to get the official version of the
software package.  Somebody just needed to register ie. the top-level
domain `.software' and coordinate the domains under that.  It was some
trouble to coordinate what domains fall under software, but many came
easily to mind:

gnu.software		for the GNU project software
net.software		for software published on the Usenet
- comp.unix.net.software: comp.sources.unix archives
- alt.net.software: alt.sources
- sources.net.amiga: comp.amiga.sources
- athena.software: the project Athena stuff
mail.software		for various mailers
editors.software	for editors

The advantages of the hierarchical system is that one person needn't
manage the huge amount of information concerning ALL the software
available.  Just as with the domain name server system, one
organisation(or person) keeps up-to-date the information about how the
reach one particular organization )or, in this case, piece or group of
software).

Of course, you may think, what did this solve, as you must anyway know
the name of the program, how does this differ from the old way of
distributing lists of where to get the software ?  Even with this
system, you still had to distribute lists - and even now, with the
system working quite well, but now they contain only the name of the
software in this domain system.

The important difference is that the list distributed (`The World
Software Catalog') now doesn't contain incorrect information, as it only
contains a list of software that has been written and not the places
where they can be gotten or version number information.  These can be
gotten from the `Software Location Service'.

Useful software quite rarely ceases to
exist, and even if it changes it's name, the old name can still be
kept in the domain name system pointing to the new name for some time.
As new software gets published, the person writing the software
allocates a name for it and write a short description of it to be added
to the distributed `Software Location Service'.  Also a mention of the
name and a very short description of the purpose of the software is
added to `The World Software Catalog'.  After we implemented the type
'software' in the domain system, we could put that additional short
description (version number, author, patchlevel) to go along with the
ftp server address.


OK, now we had implemented the Ultimate Software Location Service and
have a few thousand persons in different parts of the world keeping
the world-wide distributed database up to date.  Also, we have The
World Software Catalog (all of it freely distibutable of course, is
there any other kind of software ??) with descriptions posted monthly
to Usenet.  Of course, the catalog isn't very complete but then, if
you hear from a friend about a piece of software or happen to read
about it in a newsgroup you can always ask the software location
service more about it and look at it, even easily download it.

Back to our original problem.  We want to have the latest and greatest
version of Gnu emacs, and just want to say a command like `getsoftware
gnu.emacs' and after at most a few minutes emacs-18.54.tar.Z magically
appears in the current directory.  So, we now have an easy way to
locate the places where the software can be gotten from.

So what ?  The world still has distances, even though they are
diminishing rapidly.  With current technology, it wouldn't be very
nice if we just grab emacs from prep across the pond (remember, we are
in Finland now) when it already happens to be stored in the next-door
department's computer - nobody just happened to tell me because the
department has their own coffee room and ours has it's own.

It may also be that for some reason or another, it's not possible for
me to ftp to States at all.  There are some administrational and
political reasons this might be so; for example, Eunet (roughly the
organization responsible for uucp network in Europe) is planning to
set up a European TCP/IP network which could also be open for
commercial sites.  For these sites, specific clearance with the U.S.
networks people has to be made to connect to the U.S. side of the
world, although they might by default gain access to Nordunet, the
TCP/IP network of the universities in Scandinavia.

So the one thing we need is to decide which of the ftp servers is
closest to us, or to which the `cost' is most cheap (I damn well hope
that the `cost' isn't ever gonna be a literal cost - that is, you are charged by the
packet in an internet; it would very quickly destroy this great
community of sharing information and software, the whole idea behind
the old anonymous ftp and the present `Software Location and
Distribution Service'.  This was a bit of a problem in the internet.
It could't be easily determined.  Of course, you could ping all the
hosts which carry the software, but that's not very good use for the
network.

We needed to have a server for calculating `distances' for
different IP addresses.  Of course, it should also be distributed so
it fits the rapidly changing network where in practice the distance
from place a to place b can go to eternity in a link failure, for
example.  Ideally, this `distance server' should be integrated with
the `software location' domain server system, so when you ask for the
place where the get the software, the priorities are adjusted
according to the distance between the server and your host.  This way,
you still can get the software if you happen to be in a commercial
company whose policy is that it only has one internet gateway -
assuming that it already is somewhere at your company.

I'll skip over the implementation of the distance server as many of
you have probably studied it in connection with other network
technology; it has many more uses that this software location
services.  It wasn't be that hard to implement; with modern network
monitoring tools, much statistic information is collected to describe
the connectivity of different networks and those are easy to change
into `distance data'.  Perhaps surprisingly, however, the distance
calculation was the most difficult single obstacle to overcome in the
way to get the `Software Location and Distribution Service' into reality.

Back to business (that is, getting newest version of emacs).  Now we
know that we could get it from prep, but it isn't very wise since prep
is far, far away and net.gods will be angry if everybody overloads the
network and prep by getting emacs from there every day.  Also, now we
know that we can get it elsewhere (remember, the department next-door
has it).

But what if the next-door guy doesn't use emacs and just installed it
a few years ago to please some users and those users have left the job
?  Then the version of emacs he (pardon my sexism, I wish everyone
spoke Finnish, it doesn't have a different word for she / he) would have
probably is OLD.  You don't want that.

So, we again face the problem with old versions.  Why did old versions
stick around ?  Or, to get to the root of the problem, how did the
next-door guy get the emacs in the first place ?  You guessed it, he
manually grabbed it from prep and after that just forgot it on his
anon. ftp area.  Why did he have to do it manually ?  Yep, because
back then we didn't have this great location and distribution service.

Back in the old days, before the `Software Location System' was
working, the main channels of distribution was that somebody just
heard in a coffee or lunch break (oh mine, where would we be if we
wouldn't have to eat / dirnk coffee) about a great piece of software
and traced it to it's origin.  Then, being a nice folk, she also put it
for anonymous ftp in her machine after having to first convince her
boss that she wasn't just wasting the University's money for nothing,
that it benefited all Universities in the country (you didn't believe
this was the Real World now, did you?).  That is, almost all anonymous
ftp areas were managed by volunteers doing it on the side of their
Real jobs.

But that was in the old days.  Now, of course, there's no such thing
as an `old version' for anonymous ftp unless you specificly ask for
it.  What changed the thing ?

Remember, we have the `Software Location Service'.  Also, it
calculates the distance from the software needer and the provider.
Now, we also have the unwritten law that every organization who joins
the network as a routine matter provides at least 200 meg (or more
for commercial organizations) of disk space for the `general good' to
keep the software service working.  So, every time somebody asks for a
piece of software, the priority of it is calculated as usually.  After
that, a version number is asked from the one special `home server' of
the software and if it differs from the version number of the
`cheapest' server, a message is sent to the `cheapest' server to throw
away that software.

Also, every time somebody asks for the software, a counter is added to
keep statistics where the software is needed.  Based on these
statistics, we send messages to the ftp servers near the area where
the software asker is to get the software.  The servers may decide to
ignore the messages, if other software gets more demand.  Anyhow, the
idea is that servers keep a cache of the software needed by the
clients.  If the distance to all the servers for a certain software is
too big (in other words, the hosts are not reachable) the service
sends a message to a server nearby the client with a flag that this
order should be carried out; the client gets a message to try again
later and an approximation of the time how long the software will take
to get near enough.

That's all there is to it !

Stay tuned, now that we have this service working as well as it is, we
are taking a look at `The Worldwide Electronic Telephone Catalog' and
`The Worldwide Newspaper Archive Service'.  Of course you already
heard about `The Internet's Guide to Travelling', now in the
implementation phase, an almost-real-time travel planning system which
lets you plan your trip all across the world, calculates current
prices and even takes into account various strikes which might be
going on.

-------
Back to August of year 1989.

Don't tell me, there's OSI.  It probably has all this already
implemented and in addition to it it can cook your morning coffee and
wash your dirty laundry, huh ?  Please tell me if this is so, and
where to FTP it from ;-)

Happy hacking,
-- 
Jyrki Kuoppala    Helsinki University of Technology, Finland.
Internet :        jkp@cs.hut.fi           [128.214.3.119]
BITNET :          jkp@fingate.bitnet      Gravity is a myth, the Earth sucks!

-----------[000054][next][prev][last][first]----------------------------------------------------
Date:      Wed, 06 Sep 89 11:28:12 -0400
From:      satlas@BBN.COM
To:        Alan Larson <LARSON@crvax.sri.com>
Cc:        tcp-ip@nic.ddn.mil, hinden@BBN.COM, satlas@BBN.COM
Subject:   Re: [Alan Larson: routing - very strange stuff]
Alan,

 Can you tell me why SRI-GW.ARPA is forwarding the echo requests to
three different Mailbridges within a very short period of time?  Is
SRI-GW.ARPA running some form of loadsharing?  The Mailbridges do not
control the choice of the next hop for SRI-GW.ARPA, but can just offer
reachability information via EGP.  From the traceroute information it
appears that the Mailbridges are receiving the ICMP packets and
forwarding them to the proper destination.

Regards,
Stephen

Unrelated note:  From the traceroute information Alan forwarded the 
round trips from the west coast to the east coast appear very good.

             Truncated version of previous message.
-----------------------------------------------------------------

>  IP routing has become more and more of a concern to many of us,
>as routes become stranger and stranger.  Earlier this morning, we
>were unable to find any routes to milnet.  Just now, I tried again,
>and found that the route is, to say the least, a bit strange.


>traceroute to NIC.DDN.MIL (26.0.0.73), 30 hops max, 38 byte packet
> 1: 128.18.10.254 (128.18.10.254)  10 ms  10 ms  0 ms
> 2: SRI-GW.ARPA (128.18.1.1)  10 ms  10 ms  10 ms
> 3: RESTON-DCEC-MB.DDN.MIL (10.6.0.20)  150 ms MARINA-DEL-REY-MB.DDN.MIL
>    (10.6.0.22)  130 ms MCLEAN-MB.DDN.MIL (10.3.0.111)  310 ms
> 4: NIC.DDN.MIL (26.0.0.73)  260 ms  440 ms  250 ms
-----------[000055][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 89 11:49:55 GMT
From:      hollandm@prlhp1.prl.philips.co.uk (Martin Holland)
To:        comp.sys.ibm.pc,comp.protocols.tcp-ip
Subject:   NCSA TN3270


Can anyone help me with the following please for NCSA Telnet:-
1) How can I get a copy of the awk script newh to convert Unix host files?
2) I am currently using NCSA TN3270 with a BICC 4110 card with the ISOLAN
   packet driver written by Russell Nelson and it works fine.
   My PC is also connected to a Novell file server can I use the packet
   driver concurrently with IPX/NET3?
3) Is there any way that NCSA TN3270 can be used through an Interlan NP600
   TCP/IP gateway on the Novell file server as the NP600 package doesn't
   include a 3270 emulator.
Martin Holland.
-- 
Martin C. Holland       Internal e/mail: HOLLANDM@PHIRHV1
Philips Research Labs.  External e/mail: HOLLANDM@prl.philips.co.uk
Redhill, Surrey. U.K.
Tel: 0293 785544

-----------[000056][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 89 15:28:12 GMT
From:      satlas@BBN.COM
To:        comp.protocols.tcp-ip
Subject:   Re: [Alan Larson: routing - very strange stuff]

Alan,

 Can you tell me why SRI-GW.ARPA is forwarding the echo requests to
three different Mailbridges within a very short period of time?  Is
SRI-GW.ARPA running some form of loadsharing?  The Mailbridges do not
control the choice of the next hop for SRI-GW.ARPA, but can just offer
reachability information via EGP.  From the traceroute information it
appears that the Mailbridges are receiving the ICMP packets and
forwarding them to the proper destination.

Regards,
Stephen

Unrelated note:  From the traceroute information Alan forwarded the 
round trips from the west coast to the east coast appear very good.

             Truncated version of previous message.
-----------------------------------------------------------------

>  IP routing has become more and more of a concern to many of us,
>as routes become stranger and stranger.  Earlier this morning, we
>were unable to find any routes to milnet.  Just now, I tried again,
>and found that the route is, to say the least, a bit strange.


>traceroute to NIC.DDN.MIL (26.0.0.73), 30 hops max, 38 byte packet
> 1: 128.18.10.254 (128.18.10.254)  10 ms  10 ms  0 ms
> 2: SRI-GW.ARPA (128.18.1.1)  10 ms  10 ms  10 ms
> 3: RESTON-DCEC-MB.DDN.MIL (10.6.0.20)  150 ms MARINA-DEL-REY-MB.DDN.MIL
>    (10.6.0.22)  130 ms MCLEAN-MB.DDN.MIL (10.3.0.111)  310 ms
> 4: NIC.DDN.MIL (26.0.0.73)  260 ms  440 ms  250 ms

-----------[000057][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 89 16:32:06 GMT
From:      jpeck@hpspdra.HP.COM (Joe Peck)
To:        comp.protocols.tcp-ip
Subject:   Re: Does anyone use IP options?

Thanks for all your responses.  They confirmed my suspicions about
how well options are handled by devices out there:  some work, some
don't, eventually the situation might improve.  I'm just interested
in traffic analysis, so you don't need to worry about me creating 
another IP implementation that doesn't handle options.

I have the impression that the most commonly used IP options are 
the routing ones, Record Route, Loose Source Routing, and Strict
Source Routing.  Would anyone like to comment on this?


Thanks again,

Joe Peck

-----------[000058][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 89 16:34:20 GMT
From:      kwang@infmx.UUCP (Kwang Sung)
To:        comp.protocols.tcp-ip
Subject:   Public Domain Softwares on DDN

Hi...there,

     i could access to DDN before....,but not now. i  would like to
get some Public Domain Softwares on DDN to develop something for our
company.....
Does anyone know how to get files to USENET from DDN ???

Kwang Sung
415/926-6758(Office)
UUCP: ...!uunet!infmx!kwang

-----------[000059][next][prev][last][first]----------------------------------------------------
Date:      Wed, 6 Sep 89 18:27:41 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: THE INTERNET CRUCIBLE - Volume 1, Issue 1 (UUCP as line item)

In article <8909010312.AA03885@fernwood.MPK.CA.US> geoff@FERNWOOD.MPK.CA.US (the terminal of Geoff Goodfellow) writes:
>While few would argue the superiority of X.25 and dial-up CSNET and UUCP,
>these technologies have proved themselves both to spur innovation and to be
>accountable.  The subscribers to such services appreciate the cost of the
>services they use, and often such costs form a well-known "line item" in
>the subscriber's annual budget.

This is undoubtedly true for X.25 and dialup CSNET, but for UUCP the exact
reverse is often the case:  a network connection exists precisely because,
unlike the alternatives, a UUCP connection does *not* require a line item
in the budget.  All it requires is suitable software (present in most
versions of Unix already), dialup modems on both ends (usually present
anyway), and a bit of setup work.  If no obscure problems intervene, such
a connection can be up and running in fifteen minutes, with *no* paperwork.
If traffic remains modest -- where the exact semantics of "modest" depend
on modem type and the cost (if any) of the calls -- often no formal
justification of the connection is ever required.  When communication is
a means to an end rather than a research topic, this can be a major asset.
-- 
V7 /bin/mail source: 554 lines.|     Henry Spencer at U of Toronto Zoology
1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000060][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 89 19:29:22 GMT
From:      cam@saturn.ACC.COM (Chris Markle acc_gnsc)
To:        comp.protocols.tcp-ip
Subject:   bsd 4.2 bug ?

Folks,

(Sorry for the previous null msg; where's the system administrator when
you need 'em?)

Our TCP/IP implementation seems to be having a problem interoperating
effectively with another vendor's implementation. The other vendor's
implementation is supposedly based upon the bsd 4.2 networking code.

So...

1) Does anyone maintain a list of 4.2 networking code bugs/problems?
If so, could they point me to it or send it to me via US- or e-mail
(preferably email)?

2) The specific trouble involves the FTP data connection. We are sending
to the "4.2" system. One of our packets gets lost/mangled/whatever. We
have transmitted segments into the receiver's window beyond the lost
segment. Eventually we retransmit the lost segment which gets ack'ed by
the receiver. 

But somewhere in here it seems as if our notion of the receiver's window 
and the receiver's ("4.2") notion may have become different. 

After the packet get retransmitted, the receiver seems to continously 
discard two (2) packets from the "righthand" side of the receiver's 
receive space, even though the segments are within the calculated receiver 
window. (Also, although the receiver varies the rwindow up to the point
of the packet lost, after that the receiver seems stuck on a 8192 rwindow;
maybe that's what he really thinks but it seems curious.)

Does this sound familiar to anyone who knows the 4.2 networking code?

3) Are there some secret / "under-the-cover" trace or debugging facilities
in 4.2 that can easily be manipulated to help us get more doc on this 
situation?

Thanks in advance for anyone's help with this...

(Reply to me or to the net, as you see fit...)

Chris Markle 

ACC
10220 Old Columbia Rd.
Columbia, MD 21046

(301)290-8100
(301)290-8106 (fax)

-----------[000061][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 89 20:07:46 GMT
From:      schoff@SOLBOURNE.NYSER.NET ("Marty Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: DoD --> CMOT and SNMP


    

    >From one of our network devices suppliers I got the information,
    that the DoD will request from all suppliers, that their
    respective products support CMOT. 
    I did not hear the same for SNMP. Is this valid for SNMP too?

On paper according to the RFC's they are both to be implemented by
vnedors/suppliers.  SNMP exists and this for the most part all TCP/IP
vendors either ship SNMP in their product or are committed to in
their next release.   Marketing research orgnizations are responsible
for exact numbers and analysis but I'm aware of 20-25 implementations
that you can buy today.

    What are the advantages of CMOT compared with SNMP, which
    make the DoD chose CMOT as their favorite network management
    vehicle? (Both, CMOT and SNMP use the same management information
    base!?)

CMOT's advantage is that it is theoretically aligned with the International
Standard Organizations (ISO) program.

    Who knows of or runs a CMOT implementation? I would like
    to have a direct contact.

To my knowledge no one runs this in an operational network and I haven't
heard of the availablility of interoperable CMOT implementations.

Marty

-----------[000062][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 89 20:45:53 GMT
From:      jg@max.crl.dec.com (Jim Gettys)
To:        comp.protocols.tcp-ip
Subject:   Re: Nagle algo. in Unix-TCP

As noted, 4.3BSD has a socket option to defeat delayed ACK's,
specifically put there on our request
(X happened to be the first application to run into the problem, during
beta test of 4.3, back well
before X11).

This has been picked up by essentially everyone.  Ultrix had the option
since V2 days.

The option (found in /usr/include/netinet/tcp.h) is TCP_NODELAY.

/*
 * User-settable options (used with setsockopt).
 */
#define TCP_NODELAY     0x01    /* don't delay send to coalesce packets */

				- Jim Gettys

-----------[000063][next][prev][last][first]----------------------------------------------------
Date:      6 Sep 89 20:58:12 GMT
From:      brian@hfh.edu (Brian A. Wolfe)
To:        comp.protocols.tcp-ip,comp.dcom.lans
Subject:   remote lan bridge?

Can anyone recommend a (relatively!) inexpensive remote
ethernet bridge? I've been told that $6500 is a good price
on an ethernet -> T1 bridge.

We are considering linking 2 or 3 satellite facilities
to our main campus for records purposes and remote login.
Traffic would be fairly light, probably under 5 megabytes of
data per day.
 
Are there any remote bridges that exist that could multiplex
several T1 lines to a single ethernet (see below)

                      ___
                   __|Box| Satellite A
                  /  |___|
________       T1/
        |       /
        |  ____/           ___
Main    |-|Box |----------|Box| Satellite B
Facility|  ----\   T1     |___|
Ethernet|       \
________|      T1\   ___
                  \_|Box| Satellite C
                    |___|



Please excuse my artwork and/or ignorance in this matter.

Regards,

Brian.


-- 
Brian Wolfe            Internet: brian@hfh.edu  BITNET: USERW18Y@UMICHUM
Systems Analyst        UUCP:     {rutgers,itivax,uunet}!sharkey!hfhrv!baw
Henry Ford Hospital    Voice:    (313)-876-7461
Detroit MI 48202       FAX:      (313)-875-0315

-----------[000064][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Sep 89 16:59:54 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        jarvis.csri.toronto.edu!utgpu!utzoo!henry@rutgers.edu, tcp-ip@NIC.DDN.MIL
Subject:   Re: THE INTERNET CRUCIBLE - Volume 1, Issue 1 (UUCP as line item)
References: <1989Sep6.182741.23239@utzoo.uucp>
            <8909010312.AA03885@fernwood.MPK.CA.US>

>In article <8909010312.AA03885@fernwood.MPK.CA.US> geoff@FERNWOOD.MPK.CA.US (the terminal of Geoff Goodfellow) writes:
>>While few would argue the superiority of X.25 and dial-up CSNET and UUCP,
>>these technologies have proved themselves both to spur innovation and to be
>>accountable.  The subscribers to such services appreciate the cost of the
>>services they use, and often such costs form a well-known "line item" in
>>the subscriber's annual budget.
>
>This is undoubtedly true for X.25 and dialup CSNET, but for UUCP the exact
>reverse is often the case:  a network connection exists precisely because,
>unlike the alternatives, a UUCP connection does *not* require a line item
>in the budget.

University of Toronto must be a unique institution.  Until now I have never
heard of an institution without a budgetary line item to cover telephone
equipment, maintenance, service, or use.  Then again the cost of some of
the ornithological studies may be defrayed by providing pigeons to satisfy
the universities communications requirements.

>                All it requires is suitable software (present in most
>versions of Unix already), dialup modems on both ends (usually present
>anyway), and a bit of setup work.  If no obscure problems intervene, such
>a connection can be up and running in fifteen minutes, with *no* paperwork.
>If traffic remains modest -- where the exact semantics of "modest" depend
>on modem type and the cost (if any) of the calls -- often no formal
>justification of the connection is ever required.  When communication is
>a means to an end rather than a research topic, this can be a major asset.
>

This is more to the point!  The spur to innovation is to keep the telephone
usage costs down in the "noise level".  Until you exceed the "noise level"
you're just part of the institutions normal budgetary line item for telephone
usage.  Once you exceed the "noise level", you'll find a new line item in
the department's budget which needs to be justified.
 
Merton

-----------[000065][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 89 10:31:29 GMT
From:      RIDOUT@ddnvx1.afwl.af.mil (Brian Ridout AFWL/SCEV (av) 244-1654 (505) 844-1654)
To:        comp.protocols.tcp-ip
Subject:   Printing in a Heterogeneous environment (info wanted)

A while back someone asked for suggestions for printing in a heterogeneous 
environmment. Several Unix and VMS type machines.  I haven't seen the 
summery posted so if some one has a summery please email it to me.  I am
intrested in the VMS TCP/IP solutions.

Thanks

Brian Ridout
ridout@ddnvx1.afwl.af.mil

-----------[000066][next][prev][last][first]----------------------------------------------------
Date:      Thu, 7 Sep 89 16:31 CDT
From:      Michael Califf <CALIFFM%BAYLOR.BITNET@ricevm1.rice.edu>
To:        tcp-ip@sri-nic.ARPA
Subject:   RE: WD8003EBT
Bill -

I too got a couple of WD8003EBT boards (they came in a filtering bridge
which we junked shortly after purchase.)  We were able to get them working
in our environment (TOPS/NCSA Telnet) after downloading the docs from
Western Digital's BBS (714) 852-8951.  If you cannot get access to a modem
let me know and I can forward the info to you.

From talking to the WD tech support, the 8003EBT is just a 8003E with
support for a boot prom, and some restrictions about RAM buffer size and
location.

Mike Califf
Communications Software Coord  Internet: CALIFFM@BAYLOR.CCIS.BAYLOR.EDU
Baylor University C.C.I.S.     Bitnet:   CALIFFM@BAYLOR
B.U. Box 7268                  THEnet:   BAYLOR::CALIFFM
Waco, TX 76798-7268            Phone:    (817) 755-2711
-----------[000067][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 89 12:31:43 GMT
From:      gary@dvnspc1.Dev.Unisys.COM (Gary Barrett)
To:        comp.protocols.tcp-ip
Subject:   Re: Domain Names

> The question:  "Does anyone know where I could find information in the
> public domain about host or domain names  - excluding RFC's?"
> 
> I will pass on your replies or postings.  

Thanks to those of you who tried to help me.  I've learned that it
doesn't pay to be an intermediary for net queries, if nothing else!

But I did get a good lead. Thank you.  I was pointed to Comer's book 
Internetworking with TCP/IP, which contains a chapter on domain naming.  
I also found some info in Comer's Operating System Design, Volume II.
That seemed to do the trick.


Thanks again.


Gary Barrett
Unisys 
Devon Engineering Facility
Wayne, PA

-----------[000068][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 89 13:55:58 GMT
From:      oconnor@SCCGATE.SCC.COM (Mike O'Connor)
To:        comp.protocols.tcp-ip
Subject:   MIL-STD 1780 doing double duty


        Under the Military Standards list in the NIC/Query database, 
MIL-STD 1780 is cited as the standard for both IP and FTP.  Obviously
this is a typo that should be corrected.
 
        My question is, what is the correct entry for IP?  Has MIL-STD 1777
been replaced, possibly with a MIL-STD specification that resolves the
problems cited in RFC963?     
        If MIL-STD 1777 has not been replaced or modified, I have the 
(seemingly) age-old problem of how to respond to a DoD request for an
implementation of MIL-STD 1777.    
 
                Thanks, 
                        Mike

-----------[000069][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 89 14:31:24 GMT
From:      wbc@cabot.dartmouth.edu
To:        comp.protocols.tcp-ip
Subject:   Ping with Record Route Option

I recently requested information on tracing the route that
packets take,  and got some very helpful information, especially
about traceroute.  Someone also mentioned ping, with the record
route option, but didn't have source available.  Does someone
know where I can get this kind of ping, or should I hack one up
myself?




	Wayne Cripps
	wbc@DARTMOUTH.EDU		wbc@sunapee.dartvax.uucp
	Bradley Hall, Dartmouth College, Hanover N.H. 03755 (603) 646-3198

-----------[000070][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 89 14:53:07 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   re: does anyone use ip options?




look for the security options to show up more and more.



"thats right, dont you dare look into this packet, its secure!"


stev knowles
stev@ftp.com


"The only use I can see for IP security options is an Internet poker game."
				- William A. Brackenridg

-----------[000071][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 89 15:01:23 GMT
From:      alan@cunixc.cc.columbia.edu (Alan Crosswell)
To:        comp.protocols.tcp-ip
Subject:   Re: Encore Annex Terminal server dies as NSFNET grows.

In article <8909040510.AA21672@nsipo.arc.nasa.gov> medin@NSIPO.ARC.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office) writes:

>PS This parameter is available in R4.1 (which we run), but I'm not quite
>sure how far back it goes.  If you aren't running 4.1, you should, it's
>got lots of neat stuff in it...

The routed parameter is new to R4.1.
/a

-----------[000072][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 89 16:05:48 GMT
From:      billn@kinetics.UUCP (Bill Northlich)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Re: IPTalk mailing list


At the moment I don't see a need for a separate IPTalk mailing list/group.
I would personally rather read/comment about it in comp.protocols.appletalk,
for now.  I certainly appreciate Amanda's enthusiasm though, as I think 
there is a small but enthusiastic group wanting to discuss IPTalk & etc.
The RFC's the key, and I think that some headway should be made on it at
the recently announced BOF to be held at Interop.

/b

-----------[000073][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 89 17:38:59 GMT
From:      robert@TRWIND.IND.TRW.COM (Robert W. Snyder)
To:        comp.protocols.tcp-ip
Subject:   Re:  DoD --> CMOT and SNMP

>>From one of our network devices suppliers I got the information,
>that the DoD will request from all suppliers, that their
>respective products support CMOT. 
>I did not hear the same for SNMP. Is this valid for SNMP too?
>

A major Air Force contract (ULANA) is considering requiring either SNMP
or CMOT implementations.  There are two major contractors on this
contract that are competing against one another.  One contractor
(TRW - us) is supporting SNMP, the other contractor (EDS teamed with
3com/bridge) is supporting CMOT.  Since the government is 
considering requiring the code after the contract award, 
they were sort of forced into excepting both or getting into a hassle
with one of the two vendors by giving the other an unfair advantage. 

Since this contract will be a buying vehicle DoD wide, it could
by that this is what your vendor is talking about.  I could give
you a good breakdown of vendor support for both, but I dont think
that would be fair since I do not represent a disinterested third
party.  For anyone interested in gathering this information.  I
suggest that they attend Interop in San Jose where all the vendors
will be available to ask.

If anyone is aware of anything else that might be influencing
SNMP vs CMOT in the DOD world I would appreciate a reply

Hope this helps

Robert Snyder       Disclaimer  --  nobody claims dis, but me
TRW Information Networks Division 23800 Hawthorne Blvd, Torrance CA 90505
USENET: trwind!robert
INTERNET: robert@trwind.TRW.COM                   Phone 213-373-9161

-----------[000074][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 89 17:51:15 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   Bridges in large networks

Good morning all!
		I seem to remember seeing a report or two written by the folks
at the DEC Western Research Labs (I think) that was a technical analysis
of bridges in large networks, with a slant toward the DECNET aspects. Am I
imagining seeing this or does someone have an idea where documents like this
can be obtained? I know DEC publishes a fair amount of tech lit so there much
be way of grabbing a copy.
		If someone could point me in the right direction of let me
know of a contact I would be very grateful,
			Thanks,
				Chris VandenBerg - ACC
				chris@salt.acc.com
				(805)963-9431

-----------[000075][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 89 19:53:16 GMT
From:      karl@asylum.SF.CA.US (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re:  DoD --> CMOT and SNMP

In article <8909021142.AA08148@ucbvax.Berkeley.EDU> dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) writes:
>	SNMP is unique to the TCP/IP community,

Not quite true -- one could use SNMP to manage an OSI network.

			--karl--

-----------[000076][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 89 21:31:00 GMT
From:      CALIFFM@BAYLOR.BITNET (Michael Califf)
To:        comp.protocols.tcp-ip
Subject:   RE: WD8003EBT

Bill -

I too got a couple of WD8003EBT boards (they came in a filtering bridge
which we junked shortly after purchase.)  We were able to get them working
in our environment (TOPS/NCSA Telnet) after downloading the docs from
Western Digital's BBS (714) 852-8951.  If you cannot get access to a modem
let me know and I can forward the info to you.

From talking to the WD tech support, the 8003EBT is just a 8003E with
support for a boot prom, and some restrictions about RAM buffer size and
location.

Mike Califf
Communications Software Coord  Internet: CALIFFM@BAYLOR.CCIS.BAYLOR.EDU
Baylor University C.C.I.S.     Bitnet:   CALIFFM@BAYLOR
B.U. Box 7268                  THEnet:   BAYLOR::CALIFFM
Waco, TX 76798-7268            Phone:    (817) 755-2711

-----------[000077][next][prev][last][first]----------------------------------------------------
Date:      7 Sep 89 23:37:49 GMT
From:      glenn@extro.ucc.su.oz (G. Geers [ext 3241])
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Public domain TCP/IP anyone ?


Are there any public domain TCP/IP packages including things like 
nameservers, etc ? What archive sites have them ? We are after something
that will run on sys V and BSD.
				Thanks in advance
						Glenn

Glenn Geers 
Dept Theoretical Physics
Uni of Sydney

glenn@extro.ucc.su.oz

-----------[000078][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 89 02:44:55 GMT
From:      sob@harvisr.harvard.edu (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   router testing - round II

TCP/IP Router Tests, v2

Well here we go again.  I've just finished another batch of tests on
some routers.  There is real data later on in this posting but first
what was tested, how it was tested and other miscellany.

The info in this posting was first presented at the IBM user's group
SHARE last month. (parenthetical aside, don't give me a hard time
about the venue for the talk, once upon a time IBM & TCP/IP did not
quite see eye to eye and that problem may still be there with some
other 3 letter companies & their 3 letter operating systems, but
in the last few years IBM has done much to introduce TCP/IP products
for its line of computers and many of these products have evolved
into packages that are quite good - now if only the salesmen could
learn how to spell TCP/IP :-) ), copies of the slides for this 
talk can be ftp'ed from husc6.harvard.edu, look in the pub/rtests
directory.  Retrieve the README to find out what is what.

For those of you going to INTEROP, I've been asked to give the SHARE
talk again as a BOF (Wed at 2:30). Come give me a hard time if you
think it is warranted.

I asked all of the companies that 1) producing routers that support
TCP/IP & 2) I could find a phone # for, if I could get a router from
them for 2 days of tests ( I told them 2 days but most of the tests 
took longer than that ), I asked for a router & SE who could set it
up for one day & just the set-up router for the 2nd day.  I asked for the
SE so there would be no way that it could be claimed that we had set
things up wrong.

A number of companies responded "we will get back to you" or "yes,
we will get back to you" and when the time came, the router did not.
I will admit that I gave some of the vendors very short notice and
that was a legit reason for some, an excuse for others.  What I did get
were boxes from cisco, Network Systems and Proteon.  We beat up on these
quite a bit and found problems with all of them.  And for all of them
we reported the problems, got to talk to people that knew what they
were talking about and were able to give us assurances that the
problems were understood and in most cases fixed.  We did get follow up
software for cisco & Proteon that did fix many of the problems found.

I'm going to be a bit of a pain here and not tell you all what some of the
problems were since some of them can be used to easily crash a router,
some times in ways that would require someone to manually power cycle
before it would work again.  The problems that fit into this category
are fixed in software that we have tested or that we are assured will
be shipped "any day now".  Publishing what these problems are could 
lead to some crashing of NSF regional nets and that can get to be 
a bit of a drag.

What should be tested?  

All we really tested were the  things that were easy to test,
max throughput under various router setups and various basic
measurements.  What we did not test was something that looked
like a version of the real world.  The real world has many routes,
we had one, the real world has many source-destination sets,
we had one etc.  These tests were done on the cheap, they will
be redone later with additional capabilities.
We tested devices that provided ethernet to ethernet TCP/IP
routing.  We would have liked to test other things like the 
PC based router that has been floating around the net and
the use of a minicomputer, like a microvax or a sun, as a router,
but did not get to it, next time.

Next time we will also include bridges in the tests.  If you people
out there in netland have specific suggestions about tests and/or
devices please let me know.

well, on to the test setup.

We (actually, Dan Lanciani) put together software that runs using
a Micom Interlan NI5210 in a IBM PC/AT. The software made use
of some of the Intel LAN chip's features to
produce packets at a reasonable rate.  We could not get the
interpacket intervile shorter than 55 usec, far longer than the
spec's 9.6 min, so the max packet rate was not up to what it 
should have been, but, I hope, still useful.

(We are working on new hardware to do better, and will redo these tests
about November, by better I mean 9.6 usec gap )

The LAN chip works on a linked buffer list of packet descriptors
to use, if one points the last one at the first one, one has a loop.
(you say that coming, didn't you?)  We just set things up so that
a packet in the loop was addressed to the router and the other
packet was addressed elsewhere and then adjusted the size of the
"other" packet to get the desired packet rate to the router.
(The new hardware will do it right & vary the ipi. ) The software
that was used to run this is named "hammer", don't run it on a live
network.

The other end of the router was attached to a Tandy PC clone with another
NI5210.  This one was put into resource exhaustion mode ( i.e. it
was made to think that there was no place to put incoming packets ).
When the chip gets a packet that it does not have space for, it tosses it
but it also increments a counter.  This counter was displayed
both in a cumulative mode and a packets per second mode.  Note that the
clock that was being used for the packets per second display was the
one in the Tandy and its accuracy is suspect, but seemed to be at least
repeatable.( If you have not already guessed, the counter program is called
"anvil". )

The inputs & outputs of the router were connected to a good 2 trace
Tektronics scope so the actual packets could be seen.

The packets that were used were captured "ping" packets from the
BSD ping program, the packet size changed with the command line
option.

The tests that were run:
   Delay through router:
	The scope was used to measure the delay from the end of a 
	packet going into the router to the beginning of the packet 
	coming out.
	
	Although much concern has been expressed on the net about
	the delay though routers, we found that the tested routers
	all had small (<3ms) and consistent delays under light
	loading, it is not easy to do this test for heavy loads.

   Idle state:
	Run anvil & count the number of packets over a min.

	Again, there has been discussion on the net about the
	load that a router (or bridge) can place on a net just
	by being there and being turned on.  We found very low
	loads from the tested routers. 1 packet every 3 to 30 sec.
	Note that we did not have routing info in the test setup
	the addition of this type of thing would add a lot to
	the traffic generated.

   max good throughput
	Hammer was run generating packets into the router,
	anvil was run counting what came out.  The input rate
	was adjusted for the max rate where the calculated
	packets-to-router-rate matched to rate shown by anvil. 
	Packets of length 64, 128, 256, 512, 1024 and 1518 were
	tested.

	This is a common but flawed test.  The actual "good" rate
	should be the max rate at which no packets are lost.  Since
	one lost packet can have quite an impact on the application
	to application throughput of a system.  We hope that the
	new hardware will be able to do this test correctly.

	The rates varied quite a bit.  While the slowest router was
	still faster than the current average load on the Harvard 
	backbone (since we have segmented things) it is only a
	small fraction of the throughput of the best router.

   +25%
	To test simple overload conditions, the packet rate found
	above was raised by 25% and the output rate was measured.

	See data for results, some of the routers were too fast for 
	hammer to be able to generate the +25% rate.

   flood 
	Packets were sent to the router as fast as hammer could generate
	them.

	This flood condition, something that one could see with broadcast
	storms, caused many problems.  The most common problem was that
	the processor in the router stopped responding to the console
	port so that an operator could not get in there and disable
	things.

   filter 1
	A single filter condition was added to the router configuration
	and the max good rate was determined

	In most routers, the addition of a filter condition did effect
	the max throughput.

   filter 10
	Nine additional filter conditions were added to the configuration
	and the max rate was determined.

	This had an effect on some routers, no effect on others.

   back to back
	A series of packets were sent to the router as fast as hammer
	could send them and the point was found where the router
	started losing packets. In the real world, NFS servers
	can often generate back to back packets.

	The test equipment was not quite up to doing a good test here
	but the results might be useful.  In particular the Proteon
	router showed much better performance under the episodic
	load conditions of this test than it showed under constant
	load.

   counter accuracy
	The counters in the router were tested by passing a known
	number of packets through the router and checking the before
	and after counts.

	All of the counters were accurate.

   errors
	Packets with errors were sent to the routers to see 1/  that
	the router would toss the packets and 2/ if there were stats
	kept on the discarded packets.  The errors tested were
	crc errors, runt & giant packets.

	All routers discarded the packets.
	Most routers did not have all of the counter required to
	keep track of all of the errors.
----------------------------------------------------------------------------
Data:
	
size - packet size including CRC
theor - theoretical bandwidth of ethernet if 9.6 usec ipi
hammer - all that hammer could do
max - max rate that seemed to pass all packets
+25% - max +25% offered
flood - offered at hammer's max rate
f1 - one filter condition
f10 - ten filter conditions

cisco between MCI cards
size	theor	hammer	max	+25%	flood	f1	f10
64	14880	8919	5782	5782	5782	4463	3650
128	8445	6121	4320	4320	4320	3578	3023
256	4528	3757	2917	2917	2917	2544	2279
512	2349	2123	1772	1772	1772	1628	1516
1024	1197	1139	990	990	990	943	901
1518	812	782	695	695	695	672	651

cisco within MCI card
size	theor	hammer	max	+25%	flood	f1	f10
64	14880	8919	8919	8919	8919	6808	5338
128	8445	6121	6121	6121	6121	6083	5226
256	4528	3757	3757	3757	3757	3757	3757
512	2349	2123	2123	2123	2123	2123	2123
1024	1197	1139	1139	1139	1139	1139	1139
1518	812	782	782	782	782	782	782

nsc between interface cards
size	theor	hammer	max	+25%	flood	f1	f10
64	14880	8919	5216	6245	6245	4454	4454
128	8445	6121	3759	3980	3980	3526	3526
256	4528	3757	3741	3741	3741	3741	3741
512	2349	2123	2123	2123	2123	2123	2123
1024	1197	1139	1139	1139	1139	1139	1139
1518	812	782	782	782	782	782	782

nsc within interface card
size	theor	hammer	max	+25%	flood	f1	f10
64	14880	8919	6797	6797	6797	4672	4672
128	8445	6121	5572	5572	5572	3816	3816
256	4528	3757	3748	3748	3748	3740	3740
512	2349	2123	2123	2123	2123	2123	2123
1024	1197	1139	1139	1139	1139	1139	1139
1518	812	782	782	782	782	782	782

Proteon p4200
size	theor	hammer	max	+25%	flood	f1	f10
64	14880	8919	994	889	1017	994	994
128	8445	6121	971	995	266	971	971
256	4528	3757	902	738	33	902	902
512	2349	2123	764	704	107	764	764
1024	1197	1139	469	456	4	469	469
1518	812	782	324	318	39	324	324

Wellfleet (data from tests 6 months ago)
size	theor	hammer	max	+25%	flood	f1	f10
64	14880	8919	1594
128	8445	6121	1562
256	4528	3757	1555
512	2349	2123	1365
1024	1197	1139	979
1518	812	782	741

-----------------------------------------------------------------------------
Cpu under load:

How does the cpu respond while sending 1024 byte packets at
listed rates.

router		max	+25	flood
cisco b		ok	ok	dead
cisco w		ok	ok	ok
nsc b		ok	ok	ok
nsc w		ok	ok	ok
Proteon		ok	ok	dead

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

back to back

how many packets can one send to the router before it starts to
drop packets?

router		64	256	1024

theoretical	140	59	17
cisco b		90	45	15
cisco w		device is faster than the test setup
nsc b		22	57	17
nsc w		device is faster than the test setup
Proteon		20	15	6

Something does look wrong with the nsc between interface cards
values but redoing the test came up with the same results.

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

errors

cisco
    bad crc	- CRC error counter incremented.
    runt	- Runt error counter incremented.
    giant	- Giant error counter incremented

nsc
    bad crc	- Alignment error counter incremented, CRC error
		  counter was not.
    runt	- No counter.
    giant	- No counter.

Proteon
   bad crc	- CRC error counter incremented.
   runt		- No counter
   giant	- No counter
   


-----------[000079][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 89 03:24:13 GMT
From:      tom@wcc.oz (Tom Evans)
To:        comp.protocols.tcp-ip
Subject:   Re: Using the 4.2 broadcast addr with 4.3 systems

In article <3801@mentor.cc.purdue.edu>, dls@mentor.cc.purdue.edu (David L Stevens) writes:
> 	I have to admit I can't think of any (honorable, anyway) uses of
> directed broadcast, but it's not clear to me that there are none.

Running AppleTalk over IP may not be an honorable thing to do to an IP
network, but there's a lot of us doing it. Anyone who finds a better way
of doing this (i.e. eliminating the broadcasts) is going to have a lot
of ROMS to swap :-).

Guess who finds out that a network is using a broken mix of 4.2 1nd 4.3
Broadcasts? Me, and everyone else who tries to use an existing
"working" IP network for AppleTalk networking.

tom@wcc.oz.au

-----------[000080][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 89 04:05:00 GMT
From:      gnb@bby.oz (Gregory N. Bond)
To:        comp.protocols.tcp-ip
Subject:   Need advice configuring ntpd on an isolated network

Hi.  I hope this is the appropriate place for this.

I run an isolated network of approx 20 Sun workstations, split into 2
nets joined by a somewhat overloaded 48kbps line.  We are having
great problems with clock sync, as our application area (finance) has
some large realtime element.  We would like all hosts syncronised to
within a few sec and accurate to within say 10 sec.

I have measured the drift of a few handy machines (mainly the various
servers, and the workstations in the systems area) by comparison with
the talking clock on the telephone, and have found 2 that have drifted
by about +2sec/wk over the last few weeks. One of these happened
(luck!) to be my workstation (which is also an nd server and on all
the time), the other a diskless node that is turned off over weekends.
All the others I checked had -ve drifts of seconds per day. None of
the clocks I checked had small -ve drifts. Unfortunatly our main
server is drifting about -5sec/day!

I have ntpd version "89/05/18 Revision: 3.4.1.6" according to the
README file, patched at level 13 (according to patchlevel.h).

I am wondering how I should set up my ntp system, given that I have no
IP links to stratum-1 derived hosts to peer with.  My initial though
is to have the two least-drifting clocks as active peers (stratum 3?
stratum 1?), perhaps with another if I can find one with -ve drift,
and all the others as clients.  The remote server will be a peer and
the remote clients will be clients of the remote peer to reduce net
load (ok, not that it is a lot...)

Given that I have 3 main hosts peered at stratum n, each with a
"natural" drift, how will they drift as a whole? If A = B = + 2sec/wk,
and C = -1sec/day free running, will the combination go at -6sec/wk?
-5? Some other number? (A+B+C)/3?  And how would this be adjusted -
could I use "date -a" on one of the three and have it propagate, or do
I need to do it to all three?

Another alternative is to have one host with known low drift as a
stratum-1 host and peer the other 2 servers at stratum-2.  I can then
use date -a to adjust the server.  Can I somehow inform ntp that this
stratum-1 server has a known drift?

In all this I'm not looking to get millisecond accuracy, indeed drift
of < 5sec/week would be quite acceptable.

Thankyou for your assistance.

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

-----------[000081][next][prev][last][first]----------------------------------------------------
Date:      Fri, 08 Sep 89 15:48:20 -0400
From:      Karen Roubicek <roubicek@NNSC.NSF.NET>
To:        tcp-ip@nic.ddn.mil
Subject:   Information for Bibliography

The USER-DOC Working Group of the Internet Engineering Task Force (IETF) is
seeking information on documents (both online and hardcopy), reference
materials, and training tools addressing general networking information and
"how to use the Internet".  Our purpose is to put together a bibliography
targeted to assist end-users and those who provide direct services to
end-users.  We solicit your help and would appreciate any suggestions on items
to include.

In addition to text documents, the bibliography will reference media such as
audiotapes, videotapes, and fiche.  Suggestions of categories for which
we hope to publish entries include:

	* introductory material on TCP/IP
	* guides for network administrators
	* information about electronic mail
	* services documents (directories)
	* selected RFCs
	* mailing lists
	* pointers to map collections
	* regularly scheduled courses, workshops, and conferences
	* information servers (how-to-use)
	* security
	* newsletters

The appended template outlines some of the information that is necessary for
each entry in the bibliography.  While we prefer to receive completed
templates, we will appreciate less detailed contributions that will lead us to
the right sources.  (In other words, short is better than nothing!)

A research board will pursue the additional information that is needed for
entries and a review board will verify the accuracy and appropriateness of the
references.  A first draft of the bibliography will be published in early
November.

Please send templates or other information to:

	Karen Roubicek                        phone: (617)873-3361
	NNSC                                  fax:   (617)873-3776
	BBN Systems and Technologies Corp.    email: roubicek@nnsc.nsf.net
	10 Moulton Street
	Cambridge, MA 02138

Thanks in advance for your help,

Karen Roubicek and Tracy LaQuey
Chairpersons, USER-DOC Working Group


		USER-DOC BIBLIOGRAPHY TEMPLATE


Name of Entry:

Type of Entry (book, article, videotape):

Author Name:

Journal or book containing article:

Online Source(s):

Page Number(s):

Approximate length (pages/bytes):

Issuer (publisher):

Date of Publication:

Copyright info (owner:individual/organization):

Order Source/Contact:

Pathname:

Version:

Abstract:





Conference: 
	topic/name:

        sponsor(s):

	frequency:





Your name:
Organization:
Email:
Phone:
				
-----------[000082][next][prev][last][first]----------------------------------------------------
Date:      Fri, 8 Sep 89 14:39:54 EDT
From:      "Karen L. Bowers" <kbowers@NRI.Reston.VA.US>
To:        tcp-ip@nic.ddn.mil
Subject:   On-Line Directories: IETF and Internet-Drafts

Several months ago the Internet Engineering Task Force (IETF)
announced the availability of two newly revised directories 
installed at NIC.DDN.MIL: "IETF:" and "Internet-Drafts:". This
message repeats the brief description of those directories and
provides a NEW list of the most recently installed Internet-Drafts.

The IETF directory has been established as an aid to both veteran IETF
members and newcomers. It comprises files containing: a general
description of the IETF (history, organization, goals); a description
of the Internet Activities Board; a summary of active Working Groups 
within the IETF; IETF meeting dates/locations; upcoming meeting 
information and an associated RSVP form; the upcoming meeting
agenda; and a README file with an overview of directory contents.  In
addition, individual files have been dedicated to each Working Group
and their particular activities. These files contain respective Charters,
Status Updates and Current Meeting Reports. The WG files are named in
the following fashion:

		<WG NAME>.charter
		<WG NAME>.status
		<WG NAME>.report

The Internet-Drafts directory presents drafts for review and comment. 
It contains documents that will be submitted to the RFC Editor for
consideration, or will be simply discarded when their purpose has been
served. Comments are welcomed and should be addressed to the responsible 
persons whose names and email addresses are listed on the first page of 
each draft. Each Internet-Draft is placed in a separate file; the following 
standard naming scheme is used:

File Format		Naming Scheme

ascii text		DRAFT-<TFNAME>-<WGNAME>-<ABBREVTITLE>-<REVNO>.TXT
Postscript		DRAFT-<TFNAME>-<WGNAME>-<ABBREVTITLE>-<REVNO>.PS
unix compressed ascii	DRAFT-<TFNAME>-<WGNAME>-<ABBREVTITLE>-<REVNO>.TXTZ
unix compressed 	DRAFT-<TFNAME>-<WGNAME>-<ABBREVTITLE>-<REVNO>.PSZ
  Postscript

If the document is not being authored in a Task Force, then the author's name
will be substituted for the Working Group name (WGNAME) and an organizational 
affiliation will be submitted for the Task Force name (TFNAME). Example:
 
         DRAFT-<ORG>-<AUTHORNAME>-<ABBREVTITLE>-<REVNO>.TXT


DRAFTS RECENTLY INSTALLED INCLUDE THE FOLLOWING:

<DRAFT-IETF-ALERTMAN-ASYNCALERTMAN-	Managing Asynchronously Generated
 00.TXT>				Alerts

<DRAFT-IETF-AUTH-IPOPTION-00.TXT>	The Authentication of Internet 
					Datagrams

<DRAFT-IETF-OSPFIGP-SPEC-07.PS>		Draft OSPF Specification

<DRAFT-IETF-PDN-CLUSTERSCHEME-00.TXT>	Internet Cluster Addressing Scheme

<DRAFT-IETF-PDN-PDNCLUSTER-00.TXT>	Application of the Cluster Addressing
					Scheme to X.25 Public Data Networks
					and Worldwide Internet Network
					Reachability Information Exchange

<DRAFT-IETF-PDN-PDNCLUSTERNETASSIGNM-	Assignment/Reservation of Internet
 00.TXT>				Network Numbers for the PDN-Cluster

<DRAFT-IETF-PERFCC-GWCC-00.TXT>		Gateway Congestion Control Policy

<DRAFT-IETF-PPP-REQ-00.TXT>		Requirements for an Internet Standard
					Point-to-Point Protocol

<DRAFT-IETF-PPP-IPDATAGRAMSTX-01.TXT	The Point-to-Point Protocol(PPP):
					A Proposed Standard for the 
					Transmission of IP Datagrams over
					Point-to-Point Links

<DRAFT-UCL-KILLE-UUCPMAPPING-00.TXT>	Mapping between Full RFC 822 and
					RFC 822 with Restricted Encoding

<DRAFT-UCL-KILLE-X400RFC822-01.TXT	Mapping between X.400 (1988) and\
					RFC822


The Internet-Draft directory also contains a README file and an
Index-Abstract file to aid the reader in locating drafts of interest.

As stated earlier, both the IETF and Internet-Drafts directories are 
available on-line at NIC.DDN.MIL (west coast). The directory names
are: "IETF:" and "Internet-Drafts:". By the end of September shadow
directories will be installed at NNSC.NSF.NET for the convenience
of the east coast Internet community. (The directory names will not be
quite the same: "IETF" and "Internet-Drafts". The colon is placed in the
NIC.DDN.MIL-installed directories' names to accommodate the TOPS 20 
system employed.)

The current directories can be accessed by anonymous ftp. The "ls" or 
"dir" command will permit a review of what files are available and the 
specific naming scheme to use for a successful anonymous ftp action.
For more information, please contact:  

	ietf-request@venera.isi.edu.

























-----------[000083][next][prev][last][first]----------------------------------------------------
Date:      Fri, 08 Sep 89 16:00:46 EDT
From:      David Rubin <RUBIN@graf.poly.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   Tranceiver cable wiring
We are in the process of putting the DB-15 connectors on the ends of
tranceiver cable. The tranceiver cable comes with 3 22-gauge pairs and
1 20-gauge pair.  Does anyone have the specification handy and can
tell me which pins should get the 20-gauge pair and which should get
the 22-gauge pairs (if it really matters).

Thanks...

--
Dave Rubin
rubin@graf.poly.edu
Polytechnic University
-----------[000084][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 89 15:18:49 GMT
From:      hughes@silver.bacs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip
Subject:   Re: Printing in a Heterogeneous environment (info wanted)

In article <2187@ddnvx1.afwl.af.mil> RIDOUT@ddnvx1.afwl.af.mil (Brian Ridout AFWL/SCEV (av) 244-1654 (505) 844-1654) writes:
>A while back someone asked for suggestions for printing in a heterogeneous 
>environmment. Several Unix and VMS type machines.  I haven't seen the 
>summery posted so if some one has a summery please email it to me.  I am
>intrested in the VMS TCP/IP solutions.
>

I am the "guilty" party!  I've been busy for several weeks moving
offices, and haven't quite regrouped yet.

I received several suggestions in response to my query:

(1) lpr, supported natively under UNIX, and by various third party
    TCP/IP solutions for VMS and MVS (assuming one has a front end
    processor for the IBM system, of course).  Not all fep's support
    lpr, and some only unidirectionally (into the IBM, usually
    spooled into a JES queue).

(2) Project Athena's Palladium distributed print spooling system.
    This appears to be quite a sophisticated and viable solution,
    if one can afford to go strictly TCP/IP.  It operates under a
    client-server model, much like lpr, but the similarities stop
    there.  It uses Hesiod for name services, Kerberos for 
    authentication services, and Zephyr for notification services.

    To my knowledge, neither the client nor server software has
    been ported to VMS or other non-UNIX platforms.

    For more information on Palladium, reference the Usenix
    Conference Proceedings, Winter 1988 (Dallas).

    I also have an 8 or 10 page document (Postscript format), 
    compliments of a friend at MIT and published by several DEC
    and OSF employees, which describes Palladium.  If anyone is
    interested, please request via email to me, not by posting.

(3) NJE, which is native to the IBM world, is supported under
    VMS by JNET, and under UNIX by UREP (UNIX RSCS Emulation
    Program).

(4) The University of Illinois has a home-grown distributed
    printing system, which appears very well architected.
    Like Palladium, it is TCP/IP-based, runs under UNIX, and 
    it interfaces with lpr.  It also has an accounting component.

(5) Delft University of Technology (Delft, Holland) also has
    developed a TCP/IP-based lpr-like system, with enhancements
    for accounting, filtering, and more.

I have contacts at Illinois and Delft, but am unwilling to
broadcast names or detailed information without permission.
Contact me via email if you're interested.

I think this sums it up, for the most part.  Thanks for prompting
me to share this information.

 //=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\\
|| Larry J. Hughes, Senior Programmer ||  hughes@silver.bacs.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: See quote above.     ||
 \\=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=//

-----------[000085][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 89 15:53:20 GMT
From:      karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste)
To:        comp.protocols.tcp-ip
Subject:   SLIP route advertisement problem

I am having a problem convincing a couple of my systems to do the
right things in advertising and using a route to/through a SLIP
connection.

There is one host (Giza, 128.146.8.61, netmask 0xffffff00) on which
exists a SLIP line out to another host.  The SLIP connection is
configured as 128.146.60.6 at Giza's end and 128.146.60.14 at the
remote end.  The connection between these two hosts runs just fine.

I would like to be able to reach Giza's and the remote host's SLIP
interfaces using Giza's ...8.61 interface as the gateway.  Routed
seems unable to advertise the route automatically.  This is a problem,
but not fatal in and of itself.  It was suggested to me that routed
cannot find interface sl0 when it first starts up on Giza because sl0
is not configured at that time - the slattach to the SLIP port is done
much later.

Lacking routed support, it seemed reasonable to try adding a route
from another host manually.  There are at least two peculiar things
happening here.

First, I attempted "route add 128.146.60.0 128.146.8.61 1" from
another host (Cheops, 128.146.8.62), upon which I was informed that a
route to "host" ...60.0 was added.  Attempts to reach ...60.6 did not
work.  It seems odd that route considered this to be a host and not a
network.  I would think that route should be able to infer the subnet
mask based on configuration of other network interfaces, thus
determining that the indicated destination is a (sub)network and add
the route appropriately.

So I deleted that route, and added it back in with an explicit "net"
keyword.  This works.  Ping, telnet, rlogin, and other stuff to both
...60.6 and ...60.14 now work.  However, most peculiarly, my routing
table (from netstat -r) now shows two default routes, one through our
backbone ethernet's Proteon connection to the campus ring (which is
correct) and one through Giza's ...8.61.  It's a bona fide default
route: I can delete it again via "route delete 0 128.146.8.61" and I
am informed blandly that the route to network 0 is removed.  The final
kicker is that this extra default route is not a problem, no matter
how strange it looks: while that extra default route is in place, I
can reach any other host I want with no trouble, e.g., telnet to
nic.ddn.mil worked just fine.

I'd be most interested in any clues anyone can give me about any of
the 3 problems (lack of routed advertisement, probably now understood
due to non-existence of sl0 at routed startup; lack of route's
comprehension of ...60.0 as a network; extra default route).

--Karl

-----------[000086][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 89 16:25:38 GMT
From:      jxxl@acrux (John Locke)
To:        comp.protocols.tcp-ip
Subject:   Re: Need advice configuring ntpd on an isolated network

In article <GNB.89Sep8140500@baby.bby.oz> gnb@bby.oz (Gregory N. Bond) writes:
>We are having great problems with clock sync...
 
>I am wondering how I should set up my ntp system...

We had the same problem. We didn't use ntp, though. We used rdate. You define
one machine as a server and run rdate on the rest. Sun advises running it
from /etc/rc.local but there's no reason you couldn't run it from the
crontab once a day. From the man:

SYNOPSIS
     /usr/ucb/rdate hostname

AVAILABILITY
     This program is available with the Networking Tools and Pro-
     grams software installation option.  Refer to Installing the
     SunOS for information on how to install optional software.

Sun Release 4.0   Last change: 17 December 1987

-----------[000087][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 89 18:31:53 GMT
From:      eddjp@althea.UUCP (Dewey Paciaffi)
To:        comp.mail.elm,comp.mail.misc,comp.mail.sendmail,comp.protocols.tcp-ip,comp.unix.xenix
Subject:   UUCP and SMTP Mail Routing

Hi. I've been having a little problem with my mail lately, and was hoping
someone could come to my rescue.

I run elm and smail on a Xenix 386. I am connected to some local PCs that run
uupc-mail. The local and uucp mail to the PCs run fine. Last week I made
a TCP-IP connection to a local machine. Mail moves well over that connection
using the vendor supplied SMTP package. 

My problem is that I would like to have elm/smail hand mail over to the
SMTP package when appropriate. Currently any bang or domain address mail
goes to uux, when I use elm.

Can I make smail cognizant of the fact that I have a TCP host connected
and route mail to it? Is this something that requires sendmail, and if
so, does anyone know where I could locate a copy of it?

I would appreciate any insight that anyone could offer. I have crossposted
this to a few groups, and so would prefer email replies where possible.

Thanks very much,
Dewey Paciaffi			eddjp@althea.UUCP

-----------[000088][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 89 18:39:54 GMT
From:      kbowers@NRI.RESTON.VA.US ("Karen L. Bowers")
To:        comp.protocols.tcp-ip
Subject:   On-Line Directories: IETF and Internet-Drafts


Several months ago the Internet Engineering Task Force (IETF)
announced the availability of two newly revised directories 
installed at NIC.DDN.MIL: "IETF:" and "Internet-Drafts:". This
message repeats the brief description of those directories and
provides a NEW list of the most recently installed Internet-Drafts.

The IETF directory has been established as an aid to both veteran IETF
members and newcomers. It comprises files containing: a general
description of the IETF (history, organization, goals); a description
of the Internet Activities Board; a summary of active Working Groups 
within the IETF; IETF meeting dates/locations; upcoming meeting 
information and an associated RSVP form; the upcoming meeting
agenda; and a README file with an overview of directory contents.  In
addition, individual files have been dedicated to each Working Group
and their particular activities. These files contain respective Charters,
Status Updates and Current Meeting Reports. The WG files are named in
the following fashion:

		<WG NAME>.charter
		<WG NAME>.status
		<WG NAME>.report

The Internet-Drafts directory presents drafts for review and comment. 
It contains documents that will be submitted to the RFC Editor for
consideration, or will be simply discarded when their purpose has been
served. Comments are welcomed and should be addressed to the responsible 
persons whose names and email addresses are listed on the first page of 
each draft. Each Internet-Draft is placed in a separate file; the following 
standard naming scheme is used:

File Format		Naming Scheme

ascii text		DRAFT-<TFNAME>-<WGNAME>-<ABBREVTITLE>-<REVNO>.TXT
Postscript		DRAFT-<TFNAME>-<WGNAME>-<ABBREVTITLE>-<REVNO>.PS
unix compressed ascii	DRAFT-<TFNAME>-<WGNAME>-<ABBREVTITLE>-<REVNO>.TXTZ
unix compressed 	DRAFT-<TFNAME>-<WGNAME>-<ABBREVTITLE>-<REVNO>.PSZ
  Postscript

If the document is not being authored in a Task Force, then the author's name
will be substituted for the Working Group name (WGNAME) and an organizational 
affiliation will be submitted for the Task Force name (TFNAME). Example:
 
         DRAFT-<ORG>-<AUTHORNAME>-<ABBREVTITLE>-<REVNO>.TXT


DRAFTS RECENTLY INSTALLED INCLUDE THE FOLLOWING:

<DRAFT-IETF-ALERTMAN-ASYNCALERTMAN-	Managing Asynchronously Generated
 00.TXT>				Alerts

<DRAFT-IETF-AUTH-IPOPTION-00.TXT>	The Authentication of Internet 
					Datagrams

<DRAFT-IETF-OSPFIGP-SPEC-07.PS>		Draft OSPF Specification

<DRAFT-IETF-PDN-CLUSTERSCHEME-00.TXT>	Internet Cluster Addressing Scheme

<DRAFT-IETF-PDN-PDNCLUSTER-00.TXT>	Application of the Cluster Addressing
					Scheme to X.25 Public Data Networks
					and Worldwide Internet Network
					Reachability Information Exchange

<DRAFT-IETF-PDN-PDNCLUSTERNETASSIGNM-	Assignment/Reservation of Internet
 00.TXT>				Network Numbers for the PDN-Cluster

<DRAFT-IETF-PERFCC-GWCC-00.TXT>		Gateway Congestion Control Policy

<DRAFT-IETF-PPP-REQ-00.TXT>		Requirements for an Internet Standard
					Point-to-Point Protocol

<DRAFT-IETF-PPP-IPDATAGRAMSTX-01.TXT	The Point-to-Point Protocol(PPP):
					A Proposed Standard for the 
					Transmission of IP Datagrams over
					Point-to-Point Links

<DRAFT-UCL-KILLE-UUCPMAPPING-00.TXT>	Mapping between Full RFC 822 and
					RFC 822 with Restricted Encoding

<DRAFT-UCL-KILLE-X400RFC822-01.TXT	Mapping between X.400 (1988) and\
					RFC822


The Internet-Draft directory also contains a README file and an
Index-Abstract file to aid the reader in locating drafts of interest.

As stated earlier, both the IETF and Internet-Drafts directories are 
available on-line at NIC.DDN.MIL (west coast). The directory names
are: "IETF:" and "Internet-Drafts:". By the end of September shadow
directories will be installed at NNSC.NSF.NET for the convenience
of the east coast Internet community. (The directory names will not be
quite the same: "IETF" and "Internet-Drafts". The colon is placed in the
NIC.DDN.MIL-installed directories' names to accommodate the TOPS 20 
system employed.)

The current directories can be accessed by anonymous ftp. The "ls" or 
"dir" command will permit a review of what files are available and the 
specific naming scheme to use for a successful anonymous ftp action.
For more information, please contact:  

	ietf-request@venera.isi.edu.

-----------[000089][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 89 18:45:28 GMT
From:      hnt@altmuc.altce (Michael Hentrich)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   RFS over TCP/IP on an IBM-PC

Hiya,

We are running a LAN using TCP/IP and RFS. What we need is
an so called PC-RFS, which helps to connect an (IBM)-PC 
running under {MS|PC}-DOS.

We heard some rumors, that this SW is already existing.

What we need is the Information, who made or sells this
package, and if soemone has already experience with it.

Thanks in advance

Michael Hentrich

Altos Computer Systems Central-Europe
-- 
Michael Hentrich c/o Altos Computer Systems GmbH Wuermstr.55
	D-8032 Graefelfing/Munich Western Germany
Voice:+49898548440 uucp:hnt@altger.uucp bang:..!uunet!mcvax!unido!altger!hnt
-------------------------------------------------------------------------------

-----------[000090][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 89 19:02:09 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.sys.ibm.pc,comp.protocols.tcp-ip
Subject:   Re: NCSA TN3270

In article <969@prlhp1.prl.philips.co.uk> hollandm@prlhp1.prl.philips.co.uk (Martin Holland) writes:

   2) I am currently using NCSA TN3270 with a BICC 4110 card with the ISOLAN
      packet driver written by Russell Nelson and it works fine.

I didn't write that packet driver.  Consulting SUPPORT.TXT, included with
the packet driver collection, I see that Ranier Toebbicke wrote it.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])|(70441.205@compuserve.com)|
       (Russ.Nelson@f360.n260.z1.fidonet.org)|(BH01@GEnie.com :-)

-----------[000091][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 89 19:09:43 GMT
From:      zweig@brutus.cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   Router/Gateway laziness question

I was just thinking about what would happen if I had a relatively slow
controller routing packets between two nets with lots of excess bandwidth, and
decided to punt a few things. For example, how about if the router just
checked the checksum, looked at the destination IP-address, and forwarded the
packet out the appropriate interface without checking that the options are all
acceptable, etc., etc. Basically, I would trade the possibility of wasting
bandwidth on brain-damaged packets and other garbage off against wasting
controller cycles checking things over and over again.

Would this violate any extant or soon-to-be-released conformance criteria
(i.e. RFCs, or other documents)? It seems dumb to check the correctness of the
packets over and over again if it has to go through several hops on not-too-
loaded nets, but I know RFC792 (etc.) often say "if <such-and-such is
messed up> the packet MUST be dropped".

-Johnny Speculative

-----------[000092][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 89 19:48:20 GMT
From:      roubicek@NNSC.NSF.NET (Karen Roubicek)
To:        comp.protocols.tcp-ip
Subject:   Information for Bibliography


The USER-DOC Working Group of the Internet Engineering Task Force (IETF) is
seeking information on documents (both online and hardcopy), reference
materials, and training tools addressing general networking information and
"how to use the Internet".  Our purpose is to put together a bibliography
targeted to assist end-users and those who provide direct services to
end-users.  We solicit your help and would appreciate any suggestions on items
to include.

In addition to text documents, the bibliography will reference media such as
audiotapes, videotapes, and fiche.  Suggestions of categories for which
we hope to publish entries include:

	* introductory material on TCP/IP
	* guides for network administrators
	* information about electronic mail
	* services documents (directories)
	* selected RFCs
	* mailing lists
	* pointers to map collections
	* regularly scheduled courses, workshops, and conferences
	* information servers (how-to-use)
	* security
	* newsletters

The appended template outlines some of the information that is necessary for
each entry in the bibliography.  While we prefer to receive completed
templates, we will appreciate less detailed contributions that will lead us to
the right sources.  (In other words, short is better than nothing!)

A research board will pursue the additional information that is needed for
entries and a review board will verify the accuracy and appropriateness of the
references.  A first draft of the bibliography will be published in early
November.

Please send templates or other information to:

	Karen Roubicek                        phone: (617)873-3361
	NNSC                                  fax:   (617)873-3776
	BBN Systems and Technologies Corp.    email: roubicek@nnsc.nsf.net
	10 Moulton Street
	Cambridge, MA 02138

Thanks in advance for your help,

Karen Roubicek and Tracy LaQuey
Chairpersons, USER-DOC Working Group
 

		USER-DOC BIBLIOGRAPHY TEMPLATE


Name of Entry:

Type of Entry (book, article, videotape):

Author Name:

Journal or book containing article:

Online Source(s):

Page Number(s):

Approximate length (pages/bytes):

Issuer (publisher):

Date of Publication:

Copyright info (owner:individual/organization):

Order Source/Contact:

Pathname:

Version:

Abstract:





Conference: 
	topic/name:

        sponsor(s):

	frequency:





Your name:
Organization:
Email:
Phone:
				

-----------[000093][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 89 20:00:46 GMT
From:      RUBIN@GRAF.POLY.EDU (David Rubin)
To:        comp.protocols.tcp-ip
Subject:   Tranceiver cable wiring

We are in the process of putting the DB-15 connectors on the ends of
tranceiver cable. The tranceiver cable comes with 3 22-gauge pairs and
1 20-gauge pair.  Does anyone have the specification handy and can
tell me which pins should get the 20-gauge pair and which should get
the 22-gauge pairs (if it really matters).

Thanks...

--
Dave Rubin
rubin@graf.poly.edu
Polytechnic University

-----------[000094][next][prev][last][first]----------------------------------------------------
Date:      8 Sep 89 20:08:00 GMT
From:      jbx@datacube.datacube.com (John Boudreaux)
To:        comp.protocols.tcp-ip
Subject:   Re: Encore Annex Terminal server dies as NSFNET grows.

In article <1850@cunixc.cc.columbia.edu> alan@cunixc.cc.columbia.edu (Alan Crosswell) writes:
>>PS This parameter is available in R4.1 (which we run), but I'm not quite
>>sure how far back it goes.  If you aren't running 4.1, you should, it's
>>got lots of neat stuff in it...

Hey im still on 4.0 how can i go about getting 4.1?






-- 
----------------------------------------------------------------------
			jbx@datacube.com
				uunet!datacube!jbx
I dont even exist for someone to care what i write about

-----------[000095][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 89 19:42:24 GMT
From:      lin@cs.wmich.edu (Lite Lin)
To:        news.sysadmin,comp.protocols.tcp-ip
Subject:   Why are we seeing so many old messages?

I'm wondering why are we seeing old messages posted on 8/18, 8/17, or
even as early as 8/15.  They appear like new messages, while I did read
them before.  What happened?  Is that because part of the
network was partitioned for a while?  I'd appreciate it if someone could
tell me why.

	Lite


-- 
-----------------------------------------------------------------------
|  See you in Washington DC|  I hope I can one day read and contribute|
|on October 1st!           |to this newsgroup from China...           |
-----------------------------------------------------------------------

-----------[000096][next][prev][last][first]----------------------------------------------------
Date:      9 Sep 89 20:50:30 GMT
From:      chip@vector.Dallas.TX.US (Chip Rosenthal)
To:        comp.mail.elm,comp.mail.misc,comp.mail.sendmail,comp.protocols.tcp-ip,comp.unix.xenix
Subject:   Re: UUCP and SMTP Mail Routing

In article <301@althea.UUCP> eddjp@althea.UUCP (Dewey Paciaffi) writes:
>Can I make smail cognizant of the fact that I have a TCP host connected
>and route mail to it? Is this something that requires sendmail, and if
>so, does anyone know where I could locate a copy of it?

You don't mention the vendor, but I faced this problem when I tried to
use Excelan's SMTP.  At the time, the solution required two parts, and
the second part hinged upon Chip Salzenberg's deliver program.

The first part is to use the little-known but documented feature of
pathalias to generate something besides "bang-paths".  For example,
if you just say:

	mysite	othersite(COST)

then pathalias will say:

	othersite!%s

However, if you say:

	mysite	%othersite(COST)

then pathalias will say:

	%s%%othersite	(the double-% sprintf's down to user%othersite)

To smail, this is a local address, and therefore invokes the local delivery
agent rather than uux.  The second step is to use "deliver" rather than
"execmail" as the local delivery agent.  You then may make an entry in
your system delivery control file which recognizes:

	*%othersite

and passes it off to the SMTP client for delivery.

This solution works, but is a bit ugly because of all the pieces you need
to maintain.  "Deliver" is available from your friendly neighborhood
comp.sources.unix archives, with a newer version in the queue for release
(if I put on my optimist's hat).
-- 
Chip Rosenthal / chip@vector.Dallas.TX.US / Dallas Semiconductor / 214-450-5337
Someday the whole country will be one big "Metroplex" - Zippy's friend Griffy

-----------[000097][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 89 05:55:25 GMT
From:      pprindev@wellfleet.com (Philip Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re:  Router/Gateway laziness question

> Would this violate any extant or soon-to-be-released conformance criteria
> (i.e. RFCs, or other documents)? It seems dumb to check the correctness of the
> packets over and over again if it has to go through several hops on not-too-
> loaded nets, but I know RFC792 (etc.) often say "if <such-and-such is
> messed up> the packet MUST be dropped".

You can start with the TTL.  That's the biggest waste of time.  Butterflies
got this right...

-Philip

-----------[000098][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 89 06:40:49 GMT
From:      pprindev@wellfleet.com (Philip Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re:  DoD --> CMOT and SNMP

>> 	SNMP is unique to the TCP/IP community,
 
> Not quite true -- one could use SNMP to manage an OSI network.
 
Or DECnet, or XNS, or NetWare, or even a bridge (via SNMP over Ethernet).
(We don't have bridge control yet).

-Philip

-----------[000099][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 1989 19:19-EDT
From:      CERF@A.ISI.EDU
To:        brutus.cs.uiuc.edu!north@TUT.CIS.OHIO-STATE.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Router/Gateway laziness question
Johnny,

The temptation is clear, but even Jon Postel's dictum:

"Be liberal in what you accept and strict about what you
generate" has its limits. The propagation of malformed
packets is not helpful - especially if somewhere down the
line there is a limited capacity channel through which
the damaged packets must travel.

I would move very cautiously in the direction you seem
to be heading. 

Vint
-----------[000100][next][prev][last][first]----------------------------------------------------
Date:      Mon, 11 Sep 89 05:35:14 -0700
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        fernwood!asylum!karl@apple.com, pprindev@wellfleet.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  DoD --> CMOT and SNMP
>>>      SNMP is unique to the TCP/IP community,

>> Not quite true -- one could use SNMP to manage an OSI network.

Excuse me, I'm confused.  I thought that OSI was a model which described
the procedures (steps) to establish a connection and transfer data between
two nodes on a network regardless of the protocol suite employed.  The ISO
IP/TPn and Internet TCP/IP protocol suites can be described by the model
as can networks based on Digital's DCA protocol suite, IBM's BSC protocol,
and the ISO 1745 protocol.

Merton

-----------[000101][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 89 19:51:10 GMT
From:      mar@ATHENA.MIT.EDU
To:        comp.protocols.tcp-ip
Subject:   Need advice configuring ntpd on an isolated network


   From: cs!acrux!jxxl@ames.arc.nasa.gov  (John Locke)

   We had the same problem. We didn't use ntp, though. We used rdate. You define
   one machine as a server and run rdate on the rest. Sun advises running it
   from /etc/rc.local but there's no reason you couldn't run it from the
   crontab once a day.

There are good reasons for not running something like this out of
crontab if you have more than a handful of machines.  Since you're
running a clock synchronization protocol, your machines are probably
all within a couple of seconds of each other.  That means that each
machine's cron will attempt to check the time at the same time,
causing a large number of simultaneous requests first to page in the
binary of rdate from the file server, then all of the requests to the
master timeserver.  Things like this can cause massive collisions on
an ethernet, and tie up the network for a couple of minutes.

One solution is to make sure that each machine has a different crontab
to check the time at a different time, but that makes for a headache
to manage many machines and make sure that they all use different
times.  Another solution is to use a command like this in your
crontab:
    sleep `echo $ADDR | awk -F. '{ print $4 * 7 }' `; rdate
(anything started by our /etc/rc has $ADDR set to the machine's IP
address, but you could just as easily use "host `hostname`" to get the
IP address.

I don't want to go too much into Unix specifics on TCP-IP, but the
point is that you need to avoid certain kinds of synchronization in
networks, particularly when there are large numbers of similar
machines.
					-Mark Rosenstein

-----------[000102][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 89 22:49:26 GMT
From:      chris@cs.UMD.EDU (Chris Torek)
To:        comp.protocols.tcp-ip
Subject:   Re:  Why are we seeing so many old messages?

Someone---I think site `jfh001' on USENET---is pumping old messages back
into the system, and since their message IDs have expired in most places,
they are being propagated everywhere.

Chris

-----------[000103][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 89 23:19:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Router/Gateway laziness question

Johnny,

The temptation is clear, but even Jon Postel's dictum:

"Be liberal in what you accept and strict about what you
generate" has its limits. The propagation of malformed
packets is not helpful - especially if somewhere down the
line there is a limited capacity channel through which
the damaged packets must travel.

I would move very cautiously in the direction you seem
to be heading. 

Vint

-----------[000104][next][prev][last][first]----------------------------------------------------
Date:      10 Sep 89 23:46:44 GMT
From:      harish@guille.ece.orst.edu (Harish Pillay)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Query on NetBIOS on TCP/IP

The RFCs 1001 and 1002 define using TCP/IP over NetBIOS systems.  After
reading the RFCs, I'm confused over one point. Assuming an implementation 
of TCP/IP over NetBIOS, can a user on a Unix box say ftp into the PC (assuming 
a ftp server is running in the PC)?  My understanding is that the user on the 
Unix box has to have a NetBIOS-specific TCP/IP implementation.  Is that right?
If not, it is unclear to me how that user can ftp from the pc.  Conversely, can
we ftp etc from the same PC to other Unix boxes who *don't* have the NetBIOS 
stuff?  I think I'm missing something here and would appreciate any hints and 
pointers.  I hope this is not a RTFM-type of question :-).

While on the same subject, is there any PD implementations of TCP/IP over
NetBIOS systems?

Thanks.

---------------------------------------------------------------------------
Harish Pillay                               Internet: harish@ece.orst.edu
Electrical and Computer Engineering         UUCP: uunet!ece.orst.edu!harish
Oregon State University                     MaBell:   503-758-1389  (home)
Corvallis, Oregon 97331                               503-737-2554 (office)
United States of America
========     'Give a man a fish, and he'll starve for life,        ========
========  Show him how to fish, and he'll feed himself for life.'  ========
---------------------------------------------------------------------------

-----------[000105][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 89 12:41:46 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  Router/Gateway laziness question

Have you seen the Internet's answer to Center Court at Wimbleton?

CAMBRIDGE
RESTON
CAMBRIDGE
RESTON 
CAMBRIDGE
RESTON
CAMBRIDGE 
RESTON

-----------[000106][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 89 14:20:28 GMT
From:      oconnor@interlan.interlan.COM (Mary O'Connor)
To:        comp.protocols.tcp-ip
Subject:   Testin IP Options



I'm in the process of testing an implementation of IP Options.  I was
searching for some nodes to test the Routing (Record Route, Loose and
Strict Source Route) and Timestamp Options against. Any help would be
appreciated.

              Thanks in advance,
               Mary O'Connor
               Racal InterLan

-----------[000107][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 89 15:12:43 GMT
From:      little@SAIC.COM (Mike Little)
To:        comp.protocols.tcp-ip
Subject:   Re:  DoD --> CMOT and SNMP


>> Not quite true -- one could use SNMP to manage an OSI network.
 
>Excuse me, I'm confused.  I thought that OSI was a model which described
>the procedures (steps) to establish a connection and transfer data between
>two nodes on a network regardless of the protocol suite employed.  The ISO
>IP/TPn and Internet TCP/IP protocol suites can be described by the model
>as can networks based on Digital's DCA protocol suite, IBM's BSC protocol,
>and the ISO 1745 protocol.

OSI is an architectural model (one of many and the one with the most
name recognition).  I believe the confusion arises here from what I
find to be common misspeak - refering to OSI when one actually should
refer to ISO.  Particularly, the phrase "an OSI network" where the 
intention is "a network based upon the ISO protocol suite".  This may not
be exactly what Phillip intended (Phillip please interject if this is 
nowhere close), but looks like where the confusion is arising from.

					-Mike

-----------[000108][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 89 15:27:42 GMT
From:      whna@cgch.UUCP (Heinz Naef)
To:        comp.protocols.tcp-ip
Subject:   OSPF Area Routing

Hello Neighbors,

the article on OSPF in ConneXions Aug. 89 says:

  "... An area is a generalization of a subnetted network; it should be noted
   that all subnets of a network must be contained within a single area."

Assume a large organization having a single Class B Network Number divided
into subnets. The subnet number space is partitioned into groups to form
clusters of a certain amount of autonomy. It would be highly desirable to
treat each of these groups as an OSPF routing area in order to establish a
hierarchical routing scheme, combined with routing firewalls for enhanced
overall availability, reliability and security.

Is our interpretation correct that OSPF, instead of allowing to break down
a subnetted network into areas, is based on a model which groups subnetted
networks together within one area? If yes, then this is a new form of the
Autonomous System concept, isn't? What's the difference?

Any suggestions what could be done to implement *our* model? Remember, the
network described above is *not* connected to The Internet.

Could anyone who is actively dealing with OSPF send a short message back
including references to further information available about OSPF? We are
very interested in this development and would like to discuss further
aspects.

Thanks in advance, and best regards,
Heinz Naef, c/o CIBA-GEIGY AG, R-1045.3.37, P.O.Box, CH-4002 Basel, Switzerland
  UUCP:     cgch!whna
  Internet: whna%cgch.uucp@uunet.uu.net              Phone: (+41) 61 697 26 75
  BITNET:   whna%cgch.uucp@cernvax.bitnet            Fax:   (+41) 61 697 32 88

-----------[000109][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 1989 0348-PDT (Tuesday)
From:      Philip Almquist <almquist@jessica.Stanford.EDU>
To:        brutus.cs.uiuc.edu!north@tut.cis.ohio-state.edu  (Johnny Zweig)
Cc:        almquist@jessica.Stanford.EDU, tcp-ip@nic.ddn.mil
Subject:   Re: Router/Gateway laziness question
Johnny,
> ...how about if the router just checked the checksum, looked at the
> destination IP-address, and forwarded the packet out the appropriate
> interface without checking that the options are all acceptable, etc...

	If you're going to play fast and loose with the rules, I
don't understand why you're bothering to verify the checksum...

	But seriously: although your scheme may save some programming
effort, I doubt it it would save very many instructions.  A router has
to do route lookup.  It may have to do an additional lookup to obtain a
link layer address to send the packet to.  It has to strip off the link
layer headers when the packet arrives and add new ones before sending it
back out.  It has to decrement the TTL if you don't like to have packets
live forever in your network (or want to be compliant with RFC1009).
Routers must process certain IP options (RFC1009 requires source route,
record route, and timestamp), and must therefore parse all IP options
sufficiently to determine their type and length.  Last but not least,
routers have to take interrupts and massage their network interface
cards.

	There may be a few instructions you can save here and there by
skipping validity checks, but the the real determinants of router
performance are the network interface cards, the bus bandwidth, and the
choices of data structures and algorithms used in performing the tasks
listed in the previous paragraph.
						Philip
-----------[000110][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 89 22:32:44 GMT
From:      kwang@infmx.UUCP (Kwang Sung)
To:        comp.protocols.tcp-ip
Subject:   Network tools to monitor network activities under DBMS environments

Hi... there,

      Does anyone have network tool software based on SNMP, 
CMIS/CMIP, or CMOT to monitor network activities such as who is accessing
to which databases remotely under distributed DBMS environments ???

Let me know ....

Thanx,  

          Kwang Sung
          Informix Software, Inc
          415/ 926-6758
          UUCP: ...!uunet!infmx!kwang

-----------[000111][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 89 22:34:52 GMT
From:      Dave_Katz@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  DoD --> CMOT and SNMP

>name recognition).  I believe the confusion arises here from what I
>find to be common misspeak - refering to OSI when one actually should
>refer to ISO.  Particularly, the phrase "an OSI network" where the
>intention is "a network based upon the ISO protocol suite".  This may not
 
I don't believe that the term "OSI network" is incorrect.  There are
numerous protocols with ISO standards numbers, but only a subset of
those are protocols intended to support the OSI service definitions of
particular layers.  For example, the official title of ISO 8473,
commonly known as "ISO IP", is "Protocol for providing the connectionless
mode network service" (where said service is defined by the OSI network
service definition).
 
For what it's worth, in my experience folks around the standards community 
commonly refer to these things as "OSI protocols" and "OSI networks."
 
[cue the sound of a hair splitting]

-----------[000112][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 89 22:41:49 GMT
From:      n2dsy@cbnewsh.ATT.COM (j.gordon.beattie)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   NIST Network Management Activities


Does anyone know what the current NIST network management activities
are and who the contacts might be?
Thanks,
Gordon Beattie
201-615-4168

-----------[000113][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 89 23:02:57 GMT
From:      sr16+@andrew.cmu.edu (Seth Benjamin Rothenberg)
To:        comp.protocols.tcp-ip
Subject:   Terminal Concentrators


Pending a call-back from either of the 2 local dealers I contacted,
I am interested in first-hand reports on use of Annex (or other)
terminal concentrators as ethernet-based multiplexors.  i.e., a
terminal concentrator on either end, with hosts hooked to the
ports of one and terminals/printers on the ports of the other.

We need the kind of reliability like we would get from running
a 25-conductor cable (for 5 terminals) to each site.  (It is not
a hostile environment).

Also, how is a backbone created?  Do I just run a thick Ethernet cable
from the ground to the roof and put a transceiver on each floor?
(our plan is to have the terminal concentrators be th only thing on
the ethernet.

We will ultimately eliminate the terminal concentrators on the
host side when we have a machine that can go on the ethernet.

-----------[000114][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 89 23:30:19 GMT
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Bridges in large networks

In article <8909071751.AA06392@salt.acc.com> chris@SALT.ACC.COM (Chris VandenBerg) writes:
>		I seem to remember seeing a report or two written by the folks
>at the DEC Western Research Labs (I think) that was a technical analysis
>of bridges in large networks, with a slant toward the DECNET aspects. Am I
>imagining seeing this or does someone have an idea where documents like this
>can be obtained? I know DEC publishes a fair amount of tech lit so there much
>be way of grabbing a copy.

I am sure that this was not written by someone at DECWRL; it might have
been written by someone else within Digital.

You can get information on DECWRL documents (Research Reports, mostly)
by sending a message to "wrl-techreports@decwrl.dec.com", with the word
"help" on the subject line.  I don't know a contact for other Digital
tech report series.

-Jeff

-----------[000115][next][prev][last][first]----------------------------------------------------
Date:      11 Sep 89 23:35:30 GMT
From:      pprindev@wellfleet.com (Philip Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re:  DoD --> CMOT and SNMP

I don't think I'm the one who originally mentioned ISO, though
Mike is correct about the loose general use of ISO vs OSI.
Since ISO seems to be the only stack that is strictly compliant 
(complacent?) with the 7 layer model, most people mix the two.
I believe I only mentioned XNS and DECnet.  Karl Auerbach
originally threw out OSI [sic].

I assumed that Karl was referring to ISO 8473 (CLNS), etc.  Did
I misunderstand?

-Philip

P.S.	Merton: Did you switch employers recently?

-----------[000116][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 89 01:26:51 GMT
From:      bob@kahala.hig.hawaii.edu (Bob Cunningham)
To:        comp.protocols.tcp-ip
Subject:   RDP code?

Any idea where I might find some skeleton (or UNIX-specific) Reliable Data
Protocol (RDP, ref RFC908) code?
Bob Cunningham
Hawaii Institute of Geophysics, University of Hawaii
bob@kahala.hig.hawaii.edu

-----------[000117][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 89 01:55:37 GMT
From:      medin@NSIPO.NASA.GOV ("Milo S. Medin", NASA ARC NSI Project Office)
To:        comp.protocols.tcp-ip
Subject:   Re: OSPF Area Routing


Not true.  In an older draft of the spec, that was the case.  In the current
spec (which has just been submitted for publication as an RFC - should be out
soon), the area boundaries can occur on internal subnet boundaries.  That is,
you could collapse the area routing information on subnet boundaries
(with a given mask) and not to the natural mask of the network.  The 
packet formats were changed so that this could occur.  Van Jacobson at
LBL and John Larson (who used to be at Xerox PARC) all had very good reasons
for why the spec should be this way.  The reason it wasn't that way in the
first place was an attempt to try and simplify the protocol, but upon
careful examination, it didn't really simplify much (except configuration)
since you already had to deal with variable length subnet mask support.

If you think it was bad for you, think of a large company who uses a
single Class A network number for their internal system.  Running such
a system as a single area would have defeated the whole reason areas
were introduced in the specification.  In addition, since the authentication
type is configurable on a per area basis, areas can be fairly autonomous.
Since OSPF areas also act as routing firewalls (an intra-area path is
NEVER overriden by an inter-area path), there are reasons why one
would use areas in cases where the topological complexity wouldn't justify
it alone.

Also note, that it's VERY hard to do this unless you have variable length
subnet mask support.  Since OSPF handles this, it's not a problem, but
this issue can a very sticky one to deal with.


						Thanks,
						   Milo

-----------[000118][next][prev][last][first]----------------------------------------------------
Date:      Tue, 12 Sep 89 14:57:18 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        eru!luth!sunic!maxim!prc@bloom-beacon.mit.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Remote Printer Access protocol?
I believe that the only "public" printing protocol
is part of the Berkeley r-command series aand is
documented only in the code.

Curiously, however, this very issue was discussed at the
recent Internet Engineering Steering Group meeting.  Stay tuned to
this channel.

Dave Crocker
-----------[000119][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 89 10:33:07 GMT
From:      prc@erbe.se (Robert Claeson)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Remote Printer Access protocol?

(Strange. Nobody seems to have been thinnking of this before. Still, it's
one of the more common uses of networks.)

Is there anybody who knows if there exists such a thing like a Remote
Printer Access Protocol or something like that in the TCP/IP or ISO
world?

-- 
          Robert Claeson      E-mail: rclaeson@erbe.se
	  ERBE DATA AB

-----------[000120][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 89 10:48:00 GMT
From:      almquist@JESSICA.STANFORD.EDU (Philip Almquist)
To:        comp.protocols.tcp-ip
Subject:   Re: Router/Gateway laziness question

Johnny,
> ...how about if the router just checked the checksum, looked at the
> destination IP-address, and forwarded the packet out the appropriate
> interface without checking that the options are all acceptable, etc...

	If you're going to play fast and loose with the rules, I
don't understand why you're bothering to verify the checksum...

	But seriously: although your scheme may save some programming
effort, I doubt it it would save very many instructions.  A router has
to do route lookup.  It may have to do an additional lookup to obtain a
link layer address to send the packet to.  It has to strip off the link
layer headers when the packet arrives and add new ones before sending it
back out.  It has to decrement the TTL if you don't like to have packets
live forever in your network (or want to be compliant with RFC1009).
Routers must process certain IP options (RFC1009 requires source route,
record route, and timestamp), and must therefore parse all IP options
sufficiently to determine their type and length.  Last but not least,
routers have to take interrupts and massage their network interface
cards.

	There may be a few instructions you can save here and there by
skipping validity checks, but the the real determinants of router
performance are the network interface cards, the bus bandwidth, and the
choices of data structures and algorithms used in performing the tasks
listed in the previous paragraph.
						Philip

-----------[000121][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 89 12:53:47 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  DoD --> CMOT and SNMP

Over the past year, I've noticed the more frequent use of OSI in briefings
and publications to refer to the ISO suite of protocols.  I was beginning to
wonder if while mucking about with AUTODIN, IDHS, and a host of other lesser
known networks I had missed something.

Merton

P.S.  Phil:  I'm still at the same stand.  Since Bunker Ramo was formed by
             Martin and Ramo Woolridge, we've been Allied, Eaton, and Contel.
             The last change occurred a year ago but the domain name change
             didn't occur until June.

-----------[000122][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 89 13:25:00 GMT
From:      brian@hfhrv.UUCP (Brian A. Wolfe)
To:        comp.protocols.tcp-ip
Subject:   Remove us from the list.

Please remove us from the list (hfhrv), our address might be
tcpip%hfhrv@mailgw.cc.umich.edu or hfhrv!tcpip@mailgw.cc.umich.edu
  
thanks,
Brian.

Brian Wolfe            Internet: brian@hfh.edu  BITNET: USERW18Y@UMICHUM
Systems Analyst        UUCP:     {rutgers,itivax,uunet}!sharkey!hfhrv!baw
Henry Ford Hospital    Voice:    (313)-876-7461
Detroit MI 48202       FAX:      (313)-875-0315

-----------[000123][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 89 13:49:38 GMT
From:      jmoy@proteon.com (John Moy)
To:        comp.protocols.tcp-ip
Subject:   OSPF Area Routing

Heinz-

OSPF is an Internal Gateway Protocol, which means that it is a routing
protocol that runs internal to a single Autonomous System. OSPF further
lets you break the Autonomous System into areas. OSPF areas provide a
means for hiding, condensing and protecting routing information.

OSPF areas are defined to be lists of IP address ranges. This means
that several subnetted networks can be contained within a single OSPF
area; for example, if the two class B networks 128.185.0.0 and
128.186.0.0 are subnetted, an OSPF area could be defined as:

	OSPF area 1:	128.185.0.0 - 128.185.255.255 and
			128.186.0.0 - 128.186.255.255

Alternatively, a single subnetted network can be broken up into
multiple OSPF areas. This is what I think you would want to do. For
example, the above subnetted network 128.185.0.0 could be split into
the OSPF areas:

	OSPF area 1:	128.185.0.0 - 182.185.15.255
	OSPF area 2:	128.185.16.0 - 128.185.31.255
			...
	OSPF area 16:	128.185.240.0 - 128.185.255.255

The OSPF specification is available for anonymous ftp from the
Internet Engineering Task Force's Internet-Draft directory on
NIC.DDN.MIL. It's in postscript format, file name
DRAFT-IETF-OSPFIGP-SPEC-07.PS.

John

-----------[000124][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 89 14:21:52 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   wang and tcp


did wang ever ship their tcp code? last i heard, they had been in beta 
for a while, with no firm date set.

-----------[000125][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 89 18:26:16 GMT
From:      chip@ateng.com (Chip Salzenberg)
To:        comp.mail.elm,comp.mail.sendmail,comp.protocols.tcp-ip,comp.unix.xenix
Subject:   Re: UUCP and SMTP Mail Routing

According to eddjp@althea.UUCP (Dewey Paciaffi):
>My problem is that I would like to have elm/smail hand mail over to the
>SMTP package when appropriate. Currently any bang or domain address mail
>goes to uux, when I use elm.

My solution to this problem is:

    1.  Use a TCP/IP implementation that has a socket library; in my
	case, it's SCO TCP/IP controlled release.
    2.  Get Smail 3.1.
    3.  Compile Smail 3 with "HAVE_BSD_NETWORKING=yes" in configuration.
    4.  Install Smail 3 as /usr/lib/sendmail.
    5.  Configure Elm to use /usr/lib/sendmail.
    6.  Let Smail 3 figure out how to deliver each message.

Of course, Smail 3 isn't generally available.  IMHO, the solution posted by
Chip Rosenthal using Deliver is the next best idea.
-- 
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering;  <chip@ateng.com> or <uunet!ateng!chip>
          "If you push something hard enough, it will fall over."
		   -- Fudd's First Law of Opposition

-----------[000126][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 89 18:27:25 GMT
From:      veizades@apple.com (John Veizades)
To:        comp.protocols.appletalk,comp.protocols.tcp-ip
Subject:   Macintosh BOF at InterOp '89

My earlier message announcing the Macintosh Birds of a Feather session at 
InterOp had the incorrect date it should have read Thursday October 5th 
from 6 to 8 PM.  The corrected text is as follows:

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

Macintoshes are found in more and more installations in the Internet.  In 
response to this at InterOp '89 there will be a birds of a feather session 
on the topic of Macintoshes and the Internet environment.  This BOF will 
open discussion on how Macintoshes can be better absorbed into this 
community.  Details that will be discussed included:

KIP (tunneling of IP packets in AppleTalk)
IPTalk (tunneling of AppleTalk in IP)
MacTCP and other TCP/IP implementation for the Mac.
Macintosh applications that use TCP/IP
etc.

Representatives from Apple and other Macintosh network vendors will be 
present.  This BOF is on Thursday October 5 from 6 to 8 P.M. the location 
will be announced at the conference.

Please contact me for any additional information.

John Veizades...
Apple Computer, Inc.

veizades@apple.com
(408)974-2672

-----------[000127][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 89 20:37:53 GMT
From:      ronald@ibmpcug.co.uk (Ronald Khoo)
To:        comp.protocols.tcp-ip
Subject:   TCP for RSTS ??

Does anyone know who does a TCP/IP package for RSTS that will plug-and-go ?
(ie not require someone to re-compile it, etc :-)  The person who is
SCREAMING for this has no compiler :-) but is willing to pay $$ for it.

Required: IP/ICMP and telnet/ftp clients (we think) and anything else...

E-mail please, I will summarise if there's interest (doubt it tho... :-)
-- 
Ronald.Khoo@ibmpcug.CO.UK (The IBM PC User Group, PO Box 360, Harrow HA1 4LQ)
Path: ...!ukc!slxsys!ibmpcug!ronald Phone: +44-1-863 1191 Fax: +44-1-863 6095
$Header: /users/ronald/.signature,v 1.1 89/09/03 23:36:16 ronald Exp $ :-)

-----------[000128][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 89 21:57:18 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  Remote Printer Access protocol?

I believe that the only "public" printing protocol
is part of the Berkeley r-command series aand is
documented only in the code.

Curiously, however, this very issue was discussed at the
recent Internet Engineering Steering Group meeting.  Stay tuned to
this channel.

Dave Crocker

-----------[000129][next][prev][last][first]----------------------------------------------------
Date:      12 Sep 89 23:58:46 GMT
From:      glen@aecom.yu.edu (Glen M. Marianko)
To:        comp.protocols.tcp-ip
Subject:   Re: WD8003EBT

In article <8909080006.AA20875@ucbvax.Berkeley.EDU>, CALIFFM@BAYLOR.BITNET (Michael Califf) writes:
> 
> From talking to the WD tech support, the 8003EBT is just a 8003E with
> support for a boot prom, and some restrictions about RAM buffer size and
> location.
> 

What specifically are the restrictions, if you know that information?
It seemed to me that the buffer in the EBT can beset to 8/16/32k in size
by jumpers and the RAM base address by software to anything within
its possible range (something like 9000-F000).  Is the restriction on
where the RAM can start on a given page (like only at x000 or x800, etc.)?


Thanks.
-- 

-- Glen M. Marianko, Supervisor of Data Communications and Hardware Support
   glen@aecom.yu.edu - {uunet}!aecom!glen - CIS: 76247,450

-----------[000130][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 89 01:33:00 GMT
From:      w8sdz@WSMR-SIMTEL20.ARMY.MIL (Keith Petersen)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP dynamic windowing improvements specification

I would appreciate a pointer to a precise description of the dynamic
windowing improvements which were added to the Berkeley TCP/IP code.
I believe it was at or about the same time the "slow start" was added.

Berkeley source code is not needed because the application will be
TOPS-20, not Unix.

I would also appreciate hearing from anyone who has already added slow
start and/or dynamic windowing to the TOPS-20 TCP/IP code.

--Keith Petersen

<w8sdz@WSMR-SIMTEL20.Army.Mil>

-----------[000131][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 89 02:59:30 GMT
From:      hampton@dustbin.cisco.com (David Hampton)
To:        comp.protocols.tcp-ip
Subject:   Re: Tranceiver cable wiring

From the Cabletron ST-500 booklet:

      1 Logic Ref         
      2 Collision +       9 Collision -
      3 Transmit +       10 Transmit -
      4 Logic Ref        11 Logic Ref
      5 Receive +        12 Receive -
      6 Power Return     13 Power
      7 N/C              14 Logic Ref
      8 Logic Ref        15 N/C

The 20-guage wire is most likely for pins 6 and 13.  The 22-guage
pairs would then go to 2 & 9, 3 & 10, and 5 & 12.

BTW, Ethernet V2.0 and IEEE 802.3 specs call for four pair of 20-guage
wire.

David

+-------------------------------------------------------+
| David R. Hampton      \     email:  hampton@cisco.com |
| cisco Systems, Inc.    \                              |
| 1350 Willow Road        \                             |
| Menlo Park, CA 94025     \     Phone:  (415) 326-1941 |
+-------------------------------------------------------+
--
David

+-------------------------------------------------------+
| David R. Hampton      \     email:  hampton@cisco.com |
| cisco Systems, Inc.    \                              |
| 1350 Willow Road        \                             |
| Menlo Park, CA 94025     \     Phone:  (415) 326-1941 |
+-------------------------------------------------------+

-----------[000132][next][prev][last][first]----------------------------------------------------
Date:      Wed, 13 Sep 89 16:08:53 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        gary@dvnspc1.dev.unisys.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   re: TCP Optimizations/Enhancements

Gary:

    Instead of trying to explain all the concepts, here's the list
of papers.  They are all quite readable, and it is generally better
to get things from the source...

    Nagle: There are two algorithms, and thus, two papers. RFC 970
    (which also appeared in IEEE. Trans. Communications, Vol 35, No. 4)
    and RFC 896.

    Karn: P. Karn and C. Partridge, Improving Round-Trip Time Estimates
    in Reliable Transport Protocols.  Proc. ACM SIGCOMM '87, pp. 2-7.

    Jacobson: V. Jacobson, Congestion Avoidance and Control, Proc.
    ACM SIGCOMM '88, pp. 314-329

Craig
-----------[000133][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 89 15:09:03 GMT
From:      rwolski@lll-lcc.UUCP (Richard Wolski)
To:        comp.protocols.tcp-ip
Subject:   Re: Nagle algo. in Unix-TCP



Hello one last time.

Some time ago I posted a request for information about the Nagle algorithms
included in various flavors of Unix and got a rather surprising response from
John Nagle himself.  As I indicated in my previous posting, my questions
regarded an RPC system that a colleague of mine had written which sent
messages each in two "send" calls (instead of one which we now know is the 
accepted Unix method).  After returning from vacation and reading the various
correspondence in which I had been engaging, he felt compelled to contribute
his thoughts, but unfortunately does not have access to a machine which gets
a news feed.  I am, therefore, posting this reply on his behalf in an objective
manner as possible.

Rich Wolski

P.S.
Please reply directly to John Fletcher as I don't relish the prospect of 
intercepting scores of nasty-grams.

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

In article Article 8533 of comp.protocols.tcp-ip John Nagle writes:


>       What seems to have happened here is that several mechanisms in TCP
>are interacting with a strange kind of application to produce poor performance.
>
>       First, "silly window syndrome" is irrelevant here.  Silly window
>syndrome occurs when the window is full most of the time, but here,
>we have the tinygram problem, which occurs when the window is empty most
>of the time.  It's a common misconception that the two problems are the
>same.  They are not.  They are handled by separate code in the UNIX
>implementation, incidentally.

				.
				.
				.

>But here, we have someone who is trying something that has the property
>that it does
> 
>        SEND
>        SEND
>        wait for reply.
> 
>This doesn't take turns the way a typical transaction protocol does, so
>the guesses built into TCP are bad for this situation.

				.
				.
				.

>TCP is trying to protect the network from dumb applications.  We fixed it
>back in 1985 so that when the application is dumb, the application suffers,
>not the network.  We have here a dumb application layer.

John Fletcher (the author of a locally designed RPC package) replies:

My colleague Rich Wolski recently inquired over the net in regard to the
poor performance of TCP sockets when the typical behavior was alternately to
send two buffers and then to receive two similar buffers.  A rate of ten
buffer pairs per second was obtained.  As I understand it, the second buffer
in a pair was not actually sent by the interface until the first was 
acknowledged, and that acknowledgement was delayed.

The responses he received were not very helpful.  The most detailed one
suggested using library calls that would copy the two buffers into one, an
overhead that we are seeking to avoid.  It also described the behavior 
of the application as "dumb" and therefore presumably not deserving of
adequate support; this approach, if extended more broadly, could put us all out
of work.

On our own we found that the difficulty was avoided by using the "sendmsg" call
to send the two buffers in one call rather than using two "send" calls, one
for each buffer.  Later, one correspondent suggested the same.

Wolski's more fundamental question remains unanswered:  What exactly is the
model of TCP socket communication that the applications programmer should
have in his mind, such that he can correctly determine the most appropriate
way to achieve his purposes?  Is there such a model, and is it machine-
independent so that portable yet efficient programs can be written?  It was
mainly our experience as systems programmers, who have implemented
communication systems of our own, that lead us to suspect that "sendmsg"
_might_ consolidate  multiple buffers into one packet and that one packet
_might_ fare better than more.  The typical applications programmer has likely 
never heard of packets; to him the choice of one "sendmsg" vs. many "sends"
is mainly one of programming convenience, which might well come down in
favor of the latter.  In fact, in our case the multiple "send" approach
yields the shortest, cleanest program.

My own suspicion is that there is no clear model, because in general I find
that such is characteristic of Unix.  I was raised as a physicist and therefore
always carry the hope that the rule of parsimony will apply;  Learn a few
universal rules, and derive all else from them.  I am almost prepared to
believe that Unix and its milieu are the exact opposite:  No matter how
many rules you learn, there is always one more, and it will affect the next
thing that you do.

John Fletcher
fletch@ocfmail.ocf.llnl.gov
P.O. Box 808, L-60
Livermore, CA. 94550

-----------[000134][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 89 15:35:48 GMT
From:      gary@dvnspc1.Dev.Unisys.COM (Gary Barrett)
To:        comp.protocols.tcp-ip
Subject:   TCP Optimizations/Enhancements

I have seen mention of the "Nagle algorithm" to improve TCP
performance.  And I've seen reference to TCP enhancements by Nagle,
Jacobsen and Karn.

Would someone out there post a summary of these TCP enhancements?
What do they do?  

Thanks.


Gary Barrett
Unisys 
Devon Engineering Facility
Wayne, PA

-----------[000135][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 89 17:57:39 GMT
From:      randy@chinet.chi.il.us (Randy Suess)
To:        comp.mail.elm,comp.mail.sendmail,comp.protocols.tcp-ip,comp.unix.xenix
Subject:   Re: UUCP and SMTP Mail Routing

In article <250D4A4A.6226@ateng.com> chip@ateng.com (Chip Salzenberg) writes:
]    2.  Get Smail 3.1.
]Of course, Smail 3 isn't generally available.  

	How does one go about getting 3.1?  I have 3.0, but is too
	buggy to use (on a SysVr3.1 system).

	-randy

-- 
Randy Suess
randy@chinet.chi.il.us

-----------[000136][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 89 19:02:01 GMT
From:      akobayas@cvbnet.UUCP (Andrew Kobayashi)
To:        comp.protocols.tcp-ip
Subject:   Subnet 0

I have a question about the use of 0 as a legitimate sub-network number.

My site is running a Class B address which we have carved up into
Class C subnets for convenience.  One of them is subnet 0, that is,
the addresses are XX.XX.0.YY, where XX.XX is our Class B address and
YY is the host number.  Things have apparently been running fine for
about eight months.

The question is whether this is "allowed" and (as a separate issue)
whether it is a "good idea", and specifically whether we should change
the subnet number to something else.  The concern is apparently with the
use of XX.XX.0.0 as a broadcast address by some IP implementations.
There is no host number 0 on the 0 subnet, but someone with an HP analyzer
on the 0 subnet thought he saw some strange traffic.

We are running a mixture of Suns (on 3.x and 4.0), IBM mainframes, Pixels,
and i'm not sure what else.

It is also possible that i'm completely confused and am not asking the
right question.  Any help is appreciated.

	--Andrew Kobayashi
	  Prime Computer (at least that's what they're calling it *this* week.)
	  <@en-c06.prime.com:akobayas@spica2.prime.com>
	  {sun,linus,decvax,atexnet}!cvbnet!akobayas

	  insert standard disclaimer.

-----------[000137][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 89 19:38:53 GMT
From:      doug@seismo.gps.caltech.edu (Doug Neuhauser)
To:        comp.protocols.tcp-ip
Subject:   CMU TCP/IP for VMS wanted

Can anyone point me to a name, address, phone # or email address to get
information and order CMU's TCP/IP package for VMS?  I assume they are still
distributing it.  If now, what other options (hopefully cheap and reliable)
are there for educational institutions?

----------------------------------------------------------------------------
Doug Neuhauser			Div. of Geological and Planetary Sciences
doug@seismo.gps.caltech.edu	California Institute of Technology
818-356-3993			MS 252-21, Pasadena, CA  91125

-----------[000138][next][prev][last][first]----------------------------------------------------
Date:      13 Sep 89 20:08:53 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: TCP Optimizations/Enhancements


Gary:

    Instead of trying to explain all the concepts, here's the list
of papers.  They are all quite readable, and it is generally better
to get things from the source...

    Nagle: There are two algorithms, and thus, two papers. RFC 970
    (which also appeared in IEEE. Trans. Communications, Vol 35, No. 4)
    and RFC 896.

    Karn: P. Karn and C. Partridge, Improving Round-Trip Time Estimates
    in Reliable Transport Protocols.  Proc. ACM SIGCOMM '87, pp. 2-7.

    Jacobson: V. Jacobson, Congestion Avoidance and Control, Proc.
    ACM SIGCOMM '88, pp. 314-329

Craig

-----------[000139][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 89 00:42:41 GMT
From:      dpz@convex.com (David Paul Zimmerman)
To:        comp.protocols.tcp-ip
Subject:   Re: Ping with Record Route Option

I added record route to "ping" a few months ago at Rutgers, with some more
hackery by Ron Natalie to make for a cisco-style mode.  When both are used you
can throw a bijizillion ICMP Echo packets real quickly at a host and see what
routes, and how many of each, the packets are taking.  I can mail you all the
applicable stuff if you'd like.  I'd also include some kernel mods to make
4.3BSD systems do the right thing with ICMP Echo packets w/options.

						David

David Paul Zimmerman                                             dpz@convex.com
CONVEX Computer Corp                                                 convex!dpz

-----------[000140][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 89 00:48:00 GMT
From:      dpz@convex.com (David Paul Zimmerman)
To:        comp.protocols.tcp-ip
Subject:   Re: Testin IP Options


I've found cisco routers and terminal servers to do the right thing (Thank
Ford) with the various route options, whether passing them along or being an
end-recipient of them.  Can't say about the timestamp options.  As far as
availability, them critters are underfoot all over the place on the Internet.

						David

David Paul Zimmerman                                             dpz@convex.com
CONVEX Computer Corp                                                 convex!dpz

-----------[000141][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 89 02:28:58 GMT
From:      beau@ultra.UUCP (Beau James {Manager - SW Development - Ultra Networks})
To:        comp.protocols.tcp-ip
Subject:   BSD "routed" & gateways query

I'd appreciate any insight available from those who are more
familiar with the internals of the BSD routing daemon than I.
My questions are based on the 4.3BSD-tahoe network release
sources, although the same problem occurs with the binary
releases of SunOS though 4.0.3.

The routing daemon provides the /etc/gateways file as a
mechanism for declaring routes to host machines or networks
via gateways that do not participate in the BSD routing protocol
(passive gateways) or that can participate, but can't be located
via broadcast (active gateways).  Information about passive
gateways is not redistributed by the routing daemon; active
gateways are redistributed.

Question 1: What is the benefit of hiding passive gateways
		from users on the "internal" net?

		The code comments that "internal machines should
		use the default route to a suitable gateway (like
		us)".  But that means that the internal machines
		will forward ALL traffic to otherwise-unreachable
		nets to the gateway, not just traffic for nets
		that the gateway knows how to reach.  The internal
		machines will never see ENETUNREACH; they will
		always have to wait for a timeout.

		As an aside, the BSD route daemon behaves this way
		and is documented this way.  The Sun route daemon
		behaves this way, but is documented to distribute
		both the active and passive entries from the
		gateways file.

Question 2: Why are all active gateways entered by the route daemon
		as paths to the default network (0.0.0.0)?

		This certainly seems like a bug.  They should be
		entered as paths to the network cited in the
		/etc/gateways file.  But the code initializes
		each active gateway entry of type "net" quite
		deliberately.  In the routine "addrouteforif":

		    if (ifp->int_flags & IFF_POINTOPOINT)
			    dst = &ifp->int_dstaddr;
		    else {
			    bzero((char *)&net, sizeof (net));
			    net.sin_family = AF_INET;
			    net.sin_addr =
				    inet_makeaddr(ifp->int_subnet, INADDR_ANY);
			    dst = (struct sockaddr *)&net;
		    }
	            rt = rtfind(dst);

		The gateway machine ends up with a route to the "default"
		network (0.0.0.0) for each active gateway in the
		/etc/gateways file, instead of a route to the network
		identified in the file.  And it then propogates that
		bogus route to other machines on the net.

Any BSD routing/network intimates out there who can explain
what's supposed to be going on here, or explain which of
these behaviors is a bug and how to fix it?

Beau James				beau@Ultra.COM
Ultra Network Technologies, Inc.	{sun,ames}!ultra!beau

P.S. A further note: if an entry in the /etc/gateways file happens to
     unintentionally use the "host" keyword for a network, e.g.
     
     	host Really-A-Net gateway Gateway-To-That-Net metric 1 active
     
     then the route daemon will interpret (and redistribute) that as
     a route to network 255.255.255.255, due to an untested possible
     error return in the routine "getnetorhostname".

-----------[000142][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 89 15:24:12 GMT
From:      solensky@interlan.interlan.COM (Frank Solensky)
To:        comp.protocols.tcp-ip
Subject:   Re:  MIL-STD 1780 doing double duty

In <8909071355.AA03484@sccgate.scc.com>, Mike O'Connor writes:

>        My question is, what is the correct entry for IP?  Has MIL-STD 1777
>been replaced, possibly with a MIL-STD specification that resolves the
>problems cited in RFC963?     
>        If MIL-STD 1777 has not been replaced or modified, I have the 
>(seemingly) age-old problem of how to respond to a DoD request for an
>implementation of MIL-STD 1777.    

	There is an RFC that will be coming out shortly called "Requirements
for Internet Hosts -- Communications Layers".  A working group of the
Internet Engineering Task Force (IETF), chaired by Robert Braden, got together
to correct some of the errors in and inconsistancies between the different
specifications (RFC-791, MIL-STD-1777, etc.) of what IP and others protocols
{must/should/may/should not/must not} be doing to be considered "correct".
My understanding is that this document will eventually be adopted by
DoD as the standard that will be adhered to.
					-- Frank Solensky
					   Racal InterLan

-----------[000143][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 89 17:12:08 GMT
From:      nagle@well.UUCP (John Nagle)
To:        comp.protocols.tcp-ip
Subject:   Re: Nagle algo. in Unix-TCP


      It's interesting that the sequence

	SEND
	SEND
	wait for reply

is almost the worst possible case here.  If the application did (rapidly)

	SEND
	SEND
	SEND
	SEND
	wait for reply

on a previously idle TCP connection,
the first send would take place immediately, and the remaining three would
be consolidated into one segment (assuming they are small) which would
be transmitted when the ACK was received for the first send.

      In a UNIX application, the usual way to handle this sort of thing
is to write to to the socket via the standard I/O package, specifying
buffering, and to flush the buffer just before going into a wait state
for any reason.  If you're using SELECT(II) for all input, do a SELECT
poll (with a zero timeval structure) to determine if there is any input,
and if not, flush output buffers before then doing a SELECT which will
block.  The effect of this is that the application accumulates pending
output until it needs some (any) input, then flushes the output.  This
should eliminate the round-trip waits while minimizing network traffic.

      Bypassing the tinygram prevention mechanism is not a good idea if
the software is ever to be used in a wider world than a single LAN.
The impact on gateways is well known, and filling up the gateways of
others with tinygrams is considered antisocial.

					John Nagle

-----------[000144][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 89 20:21:47 GMT
From:      bryan@resource.Resource.COM (Bryan Beck)
To:        comp.protocols.tcp-ip,comp.os.vms,comp.sys.dec,comp.unix.xenix,comp.unix.questions
Subject:   DECNET file transfer to XENIX PC


I have a 386 pc Running SCO Xenix and I'd like to make it part of a DECNET
for file transfer purposes.

Could anyone provide me with the hardware/software requirements for
both the DECNET and the 386 to make this work.

Please e-mail all responses, and all responses are welcome.

Thanks,
Bryan

-- 
Bryan M. Beck                                       Resource Systems
UUCP: osu-cis!resource!bryan                        Suite 390 2545 Farmers Drive
INTERNET: bryan@resource.com                        Columbus, Ohio  43235
VOICE: (614) 764-7800                               FAX: (614) 764-7850

-----------[000145][next][prev][last][first]----------------------------------------------------
Date:      14 Sep 89 21:54:23 GMT
From:      n2dsy@cbnewsh.ATT.COM (j.gordon.beattie)
To:        comp.protocols.iso,comp.protocols.tcp-ip,rec.ham-radio,rec.ham-radio.packet
Subject:   ROSES-1 - Open Systems Symposium




	       The Radio Amateur Telecommunications Society

       The Radio Amateur Telecommunications Society (RATS) and the
       New Jersey Institute of Technology Amateur Radio	Club (NJIT
       ARC) are	co-sponsoring the first

	    RATS Open System Environment Symposium (ROSES-1).

       ROSES-1 is a packet forum for new users,	PBBS sysops and
       network gurus focused on OSI or Open Systems.

       There will be tech talks	and roundtable discussions on many
       areas of	packet operation as well as:

	  + LICENSE EXAMS provided by the Bergen Amateur Radio
	    Association	from 8AM until 11AM.

	  + Equipment and demonstrations will be conducted and
	    literature will be available.

	  + TNC	tune-up	clinic so bring	your radio and TNC.

       The date	is November 11th from 8AM until	6PM in the Hazell
       Center on the NJIT campus in Newark, NJ.	 Admission and
       parking are free	for all	attending.

       Talk-in will be on 145.19 (-600).

       For testing information contact Pete Adely, K2MHP at 201-
       796-6622.

       For more	information including speaker requests contact
       Gordon Beattie, N2DSY at	201-387-8896 or	via packet
       n2dsy@kd6th.

-----------[000146][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 89 01:00:47 GMT
From:      samperi@marob.masa.com (Dominick Samperi)
To:        comp.protocols.tcp-ip
Subject:   rpc protocols

Could people with RPC experience comment on the relative merits of
the various RPC "standards": Sun's RPC/XDR, ASN.1 (Used by NetWise),
and Apollo's (used by DEC?).? THanks!

Dominick Samperi
Citicorp
samperi@citicorp.com

-- 
Dominick Samperi -- ESCC
samperi@marob.masa.com
uunet!hombre!samperi

-----------[000147][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 89 04:48:41 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re:  DoD --> CMOT and SNMP

Robert,  I've been away, so sorry for a late reply, but I have also
had a chance to see other replies and must add my two cents worth.

OSI stands for Open Systems Interconnection.  ISO stands for International
Organization for Standardization.  (Yes, I know that the English/American
abbreviation for that should be IOS, but it ain't that way this time...)

OSi describes a model of communication among consenting systems.  It was
described in an ISO document many years ago.  Then ISO committees
began to fill out thier interpretations of how to accomplish the lofty
goals of the OSI model.  All of those "interpretations" have come aout as ISO 
documents.  It is easy to mix the two acronyms up because of their
use of the same alphabet symbols.  I used to find it useful to make
the distinction batween OSI and OSI.  I thought (and still do think) that 
the TCP/IP suite of protocols are quite in line withthe OSI "model".
So is DECNET, so is SNA, etc.  (I mean, hey, an application has just got to
shove the bits out the "right" interface/wire to an equally receptive
application at the target system; how many ways can you describe to do that?
In 1976 it was an accomplishment to even make that description.  By this 
tim ein history it is a freshman problem, right?)

So, today, we should quit splitting haris, and let the meaning of "OSI"
be those protocols that are promulgated by ISO with regard to communications
between consenting computers.  (ISO also sets standards
for cement ingredients, numbers of threads per inch/millimeter for screws,
etc...)

In other words, it is a waste of energy for someone to say they are OSI
complinat unless they use the actual ISO protocols.  We technologists
may be able to sort his all out, but our customers should not have
to sort out our internal debates.  Let us let them see one label.
That label is OSI.

Dan
-------

-----------[000148][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 89 09:44:00 EDT
From:      "HQEIS::MCDANIEL" <mcdaniel%hqeis.decnet@hqafsc-vax.af.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   RE: DOD ---> CMOT VERSUS SNMP
Andrews AFB

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

                                        Date:      15-Sep-1989 09:40am EST
                                        From:      Mr Rodney A McDaniel 
                                                   MCDANIEL 
                                        Dept:      HQ AFSC/SCXP
                                        Tel No:    981-7909/AV 858
                                        Owner:     Mr Rodney A McDaniel  *

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


Subject: RE: DOD ---> CMOT VERSUS SNMP


I HAVE BEEN READING ALL THE VARIOUS REPLIES CONCERNING DOD CMOT 
VERSUS SNMP, HOWEVER I HAVE BEEN UNABLE TO FIND A DEFINITION FOR 
CMOT.

WHAT DOES CMOT STAND FOR???

SECONDLY,  DOES ANYONE HAVE OR KNOW THE OFFICIAL DOD POLICY 
CONCERNING THE CMOT REQUIREMENT?? PLEASE SITE A DIRECTIVE OR OFFICIAL
PUBLICATION STATING CMOT WILL BE USED VICE SNMP FOR THE FUTURE.

THIRDLY, I DON'T SEE A COMPLETE ANSWER TO THE FIRST MESSAGE CONCERNING DOD 
CMOT VERSUS SNMP. BOTH QUESTIONS HAVE BEEN SIDE-TRACKED BY THE OSI & 
ISO PROTOCOL ISSUES.  ALSO DOES ANYONE ACTUALLY HAVE A CMOT 
IMPLEMENTATION, WHICH COULD REALLY ADVISE THE REST OF THE WORLD THE 
ADVANTAGES OR DRAWBACKS VERSUS THE EXISTING SNMP BEING USED???

ATTACHED IS A LISTING OF ALL THE REPLIES CONCERNING THIS SUBJECT, 
BUT HAVE THE ORIGINAL QUESTIONS REALLY BEEN ANSWERED AND PROVIDED THE 
NEEDED INFORMATION TO END THE CONTROVERSY ON CMOT AND SNMP.

I HAVE ADDED A ASBESTOS AND THREE FOOT THICK STEEL WALLS AROUND MY 
EMAIL TERMINAL FOR ANY POSSIBLE FLAMING REPLIES OR LAUNCHING OF ANY
MISSILES. SO REPLIES CAN BE SENT TO: MCDANIEL@HQAFSC-VAX.AF.MIL.


RODNEY A. MCDANIEL
AFSC DDN PROGRAM MANAGER
PROGRAMS DIVISION

Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Fri,  1 Sep 89 22:35:28 EDT
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 1 Sep 89 11:04:39 PDT
Received: by ucbvax.Berkeley.EDU (5.61/1.37)
	id AA13385; Fri, 1 Sep 89 10:35:18 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 1 Sep 89 11:28:54 GMT
From: mcsun!cernvax!cgch!wasc@uunet.uu.net  (Armin Schweizer)
Organization: WRZ, CIBA-GEIGY Ltd, Basel, Switzerland
Subject: DoD --> CMOT and SNMP
Message-Id: <873@cgch.UUCP>
Sender: tcp-ip-relay@NIC.DDN.MIL
To: tcp-ip@NIC.DDN.MIL



From one of our network devices suppliers I got the information,
that the DoD will request from all suppliers, that their
respective products support CMOT. 
I did not hear the same for SNMP. Is this valid for SNMP too?

What are the advantages of CMOT compared with SNMP, which
make the DoD chose CMOT as their favorite network management
vehicle? (Both, CMOT and SNMP use the same management information
base!?)

Who knows of or runs a CMOT implementation? I would like
to have a direct contact.

kind regards
armin


       Armin R. Schweizer, CIBA-GEIGY AG, R1045.P.06, WRZ
                  4002 Basel / Switzerland
	          phone: -41-61-697'79'46

Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Sat,  2 Sep 89 07:38:04 EDT
Received: from ahwahnee.Stanford.EDU by NIC.DDN.MIL with TCP; Fri, 1 Sep 89 21:47:14 PDT
Received: by ahwahnee.Stanford.EDU; Fri, 1 Sep 89 21:40:26 PDT
Date: Fri, 1 Sep 89 21:40:26 PDT
From: Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
Subject: Re:  DoD --> CMOT and SNMP
To: tcp-ip@nic.ddn.mil

(Sorry.  I intended to send this to the entire list. DHC)
From dcrocker Fri Sep  1 21:28:53 1989
From: Dave Crocker <dcrocker>
Subject: Re:  DoD --> CMOT and SNMP
To: mcsun!cernvax!cgch!wasc@uunet.uu.net
	
The Internet Activities Board has declared SNMP and CMOT to be co-equal
standards.  If effect, this means that they both have a stamp of approval
from a significant "standards" body.  (For the TCP/IP technology, the
IAB fills the kind of role that ISO and CCITT and ECMA do in various
parts of international communities.
	
So much for the stamp of approval.
	
Your question is more to the point and asks about actual support by
vendors.  (A nicely practical point to have concern for.)
	
A number of companies are currently shipping products that use SNMP.
Further, the NSFNet is managed using it.  It is my impression that virtually
all TCP/IP vendors have announced intent to support SNMP, if they are not
already doing so.
	
SNMP is unique to the TCP/IP community, although it uses the OSI ASN.1
encoding standard, for specifying the format of objects.  CMOT is derived
from the OSI CMOT standards effort, although I am told there are some
differences.  It is not clear to me that these differences are in the
management protocol, itself, it does run over a modified stack of
support protocols.  Most significantly, is uses TCP or, perhaps, UDP,
instead of an OSI transport.  Hence, CMOT gets you closer to the future
of OSI network management protocol details.
	
However, there does not appear to be any vendor that currently ships
CMOT and, therefore, there is no field (production network) experience
using it.  While a number of vendors have announced plans to support
CMOT, I am not aware of any official, announced, delivery dates from
these vendors.
	
A further point about the recent decision to make SNMP and CMOT co-equal
standards is that their use of the Management Information Base (MIB) was
entirely de-coupled.  While one should expect them to continue to use the
original 100 variable, there having additional variable in common is
problematic.  At the least, such sharing should be expected to organic or
accidental, rather than formally enforced.  (That should be "expected to
be organic..."  I am on a thin wire with a poor editor.)
	
As always, I trust that others will elaborate on, as well as correct,
the above.  Dive in!
	
	Dave Crocker
	Digital Equipment Corp.
	

P.S.  On review, I note that I did not respond to your query about 
federal requirements for CMOT support:  There is strong governmental
pressure for moving to OSI.  This is embodied in the GOSIP document.
In general, however, the requirements are careful to allow use of
alternatives.  Perhaps the most extreme way of viewing this is that a
vendor certainly cannot consider ignoring the OSI CMOT.  I am less clear
about their ability to dodge CMOT (but am sure that someone out there in
tcp-land will chime in to clarify, please?)  Enough vendors have stated
intent to support CMOT and enough are working on it, that I would expect it
to start showing up in the future.

P.P.S.  I should use this opportunity to suggest a personal bias.  It is NOT
about which protocol I prefer.  In fact, the brouhaha has, in my opinion,
distracted us from worrying about how to manage multi-administration
inter-networks.  The chosen protocol is not irrelevant to this, but my
suspicion is that we could start with a hopelessly incomplete one and 
still not know how to use it to its fullest.

That is, our general understanding and pursuit of specifying and
developing management (application) SERVICES has been quite limited
and that we would do well to focus on MIB enhancement and specification
of standard applications for management.  (I.e., focus on the bottom
and top of the management architecture.)

D/

Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Wed,  6 Sep 89 22:22:50 EDT
Received: from solbourne.nyser.net by NIC.DDN.MIL with TCP; Wed, 6 Sep 89 13:14:12 PDT
Received: from localhost by solbourne.nyser.net (5.61/2.1-NYSERNet Research & Development)
	id AA06725; Wed, 6 Sep 89 16:07:48 -0400
Message-Id: <8909062007.AA06725@solbourne.nyser.net>
To: mcsun!cernvax!cgch!wasc@uunet.uu.net (Armin Schweizer)
Cc: tcp-ip@NIC.DDN.MIL
Subject: Re: DoD --> CMOT and SNMP 
In-Reply-To: Your message of 01 Sep 89 11:28:54 +0000.
             <873@cgch.UUCP> 
Date: Wed, 06 Sep 89 16:07:46 -0400
From: "Marty Schoffstall" <schoff@solbourne.nyser.net>


    

    >From one of our network devices suppliers I got the information,
    that the DoD will request from all suppliers, that their
    respective products support CMOT. 
    I did not hear the same for SNMP. Is this valid for SNMP too?

On paper according to the RFC's they are both to be implemented by
vnedors/suppliers.  SNMP exists and this for the most part all TCP/IP
vendors either ship SNMP in their product or are committed to in
their next release.   Marketing research orgnizations are responsible
for exact numbers and analysis but I'm aware of 20-25 implementations
that you can buy today.

    What are the advantages of CMOT compared with SNMP, which
    make the DoD chose CMOT as their favorite network management
    vehicle? (Both, CMOT and SNMP use the same management information
    base!?)

CMOT's advantage is that it is theoretically aligned with the International
Standard Organizations (ISO) program.

    Who knows of or runs a CMOT implementation? I would like
    to have a direct contact.

To my knowledge no one runs this in an operational network and I haven't
heard of the availablility of interoperable CMOT implementations.

Marty

Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Fri,  8 Sep 89 02:58:15 EDT
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 7 Sep 89 22:50:53 PDT
Received: by ucbvax.Berkeley.EDU (5.61/1.37)
	id AA08939; Thu, 7 Sep 89 22:42:26 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 7 Sep 89 19:53:16 GMT
From: fernwood!asylum!karl@apple.com  (Karl Auerbach)
Organization: The Asylum; Belmont, CA
Subject: Re:  DoD --> CMOT and SNMP
Message-Id: <3853@asylum.SF.CA.US>
References: <8909021142.AA08148@ucbvax.Berkeley.EDU>
Sender: tcp-ip-relay@NIC.DDN.MIL
To: tcp-ip@NIC.DDN.MIL

In article <8909021142.AA08148@ucbvax.Berkeley.EDU> dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) writes:
>	SNMP is unique to the TCP/IP community,

Not quite true -- one could use SNMP to manage an OSI network.

			--karl--

Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Fri,  8 Sep 89 23:37:26 EDT
Received: from trwind.ind.TRW.COM by NIC.DDN.MIL with TCP; Thu, 7 Sep 89 10:39:27 PDT
Received: by trwind.ind.TRW.COM (5.54/1.36)
	id AA04966; Thu, 7 Sep 89 10:38:59 PDT
Date: Thu, 7 Sep 89 10:38:59 PDT
From: robert@trwind.ind.trw.com (Robert W. Snyder)
Message-Id: <8909071738.AA04966@trwind.ind.TRW.COM>
To: mcsun!cernvax!cgch!wasc@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject: Re:  DoD --> CMOT and SNMP
Cc: robert@trwind.ind.TRW.COM

>>From one of our network devices suppliers I got the information,
>that the DoD will request from all suppliers, that their
>respective products support CMOT. 
>I did not hear the same for SNMP. Is this valid for SNMP too?
>

A major Air Force contract (ULANA) is considering requiring either SNMP
or CMOT implementations.  There are two major contractors on this
contract that are competing against one another.  One contractor
(TRW - us) is supporting SNMP, the other contractor (EDS teamed with
3com/bridge) is supporting CMOT.  Since the government is 
considering requiring the code after the contract award, 
they were sort of forced into excepting both or getting into a hassle
with one of the two vendors by giving the other an unfair advantage. 

Since this contract will be a buying vehicle DoD wide, it could
by that this is what your vendor is talking about.  I could give
you a good breakdown of vendor support for both, but I dont think
that would be fair since I do not represent a disinterested third
party.  For anyone interested in gathering this information.  I
suggest that they attend Interop in San Jose where all the vendors
will be available to ask.

If anyone is aware of anything else that might be influencing
SNMP vs CMOT in the DOD world I would appreciate a reply

Hope this helps

Robert Snyder       Disclaimer  --  nobody claims dis, but me
TRW Information Networks Division 23800 Hawthorne Blvd, Torrance CA 90505
USENET: trwind!robert
INTERNET: robert@trwind.TRW.COM                   Phone 213-373-9161

Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Sun, 10 Sep 89 14:13:32 EDT
Received: from talcott.harvard.edu by NIC.DDN.MIL with TCP; Sun, 10 Sep 89 09:52:05 PDT
Received: from tien.Wellfleet.Com by wellfleet.com (3.2/SMI-3.2)
	id AA21304; Sun, 10 Sep 89 02:42:04 EDT
Received: by tien.Wellfleet.Com (3.2/SMI-3.2)
	id AA04290; Sun, 10 Sep 89 02:40:49 EDT
Date: Sun, 10 Sep 89 02:40:49 EDT
From: Philip Prindeville <pprindev@wellfleet.com>
Message-Id: <8909100640.AA04290@tien.Wellfleet.Com>
To: fernwood!asylum!karl@apple.com
Subject: Re:  DoD --> CMOT and SNMP
Cc: tcp-ip@nic.ddn.mil

>> 	SNMP is unique to the TCP/IP community,
 
> Not quite true -- one could use SNMP to manage an OSI network.
 
Or DECnet, or XNS, or NetWare, or even a bridge (via SNMP over Ethernet).
(We don't have bridge control yet).

-Philip

Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Mon, 11 Sep 89 10:12:06 EDT
Received: from WLV.IMSD.CONTEL.COM by NIC.DDN.MIL with TCP; Mon, 11 Sep 89 05:41:00 PDT
Received: by WLV.IMSD.CONTEL.COM (5.61/1.25)
	id AA24396; Mon, 11 Sep 89 05:35:14 -0700
Date: Mon, 11 Sep 89 05:35:14 -0700
From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
Message-Id: <8909111235.AA24396@WLV.IMSD.CONTEL.COM>
To: fernwood!asylum!karl@apple.com, pprindev@wellfleet.com
Subject: Re:  DoD --> CMOT and SNMP
Cc: tcp-ip@nic.ddn.mil

>>>      SNMP is unique to the TCP/IP community,

>> Not quite true -- one could use SNMP to manage an OSI network.

Excuse me, I'm confused.  I thought that OSI was a model which described
the procedures (steps) to establish a connection and transfer data between
two nodes on a network regardless of the protocol suite employed.  The ISO
IP/TPn and Internet TCP/IP protocol suites can be described by the model
as can networks based on Digital's DCA protocol suite, IBM's BSC protocol,
and the ISO 1745 protocol.

Merton

Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Mon, 11 Sep 89 14:24:26 EDT
Received: from ASLAN.SAIC.COM by NIC.DDN.MIL with TCP; Mon, 11 Sep 89 08:15:42 PDT
Received: by ASLAN.SAIC.COM (4.0/4.7)  id AA04861; Mon, 11 Sep 89 11:12:43 EDT
Date: Mon, 11 Sep 89 11:12:43 EDT
From: Mike Little <little@SAIC.COM>
Message-Id: <8909111512.AA04861@ASLAN.SAIC.COM>
To: mcc@WLV.IMSD.CONTEL.COM
Subject: Re:  DoD --> CMOT and SNMP
Cc: tcp-ip@nic.ddn.mil


>> Not quite true -- one could use SNMP to manage an OSI network.

>Excuse me, I'm confused.  I thought that OSI was a model which described
>the procedures (steps) to establish a connection and transfer data between
>two nodes on a network regardless of the protocol suite employed.  The ISO
>IP/TPn and Internet TCP/IP protocol suites can be described by the model
>as can networks based on Digital's DCA protocol suite, IBM's BSC protocol,
>and the ISO 1745 protocol.

OSI is an architectural model (one of many and the one with the most
name recognition).  I believe the confusion arises here from what I
find to be common misspeak - refering to OSI when one actually should
refer to ISO.  Particularly, the phrase "an OSI network" where the 
intention is "a network based upon the ISO protocol suite".  This may not
be exactly what Phillip intended (Phillip please interject if this is 
nowhere close), but looks like where the confusion is arising from.

					-Mike


Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Mon, 11 Sep 89 19:28:38 EDT
Received: from shadooby.cc.umich.edu by NIC.DDN.MIL with TCP; Mon, 11 Sep 89 15:37:32 PDT
Received: from ummts.cc.umich.edu by shadooby.cc.umich.edu (5.61/1.0)
	id AA01459; Mon, 11 Sep 89 18:35:22 -0400
Date: Mon, 11 Sep 89 18:34:52 EDT
From: Dave_Katz@um.cc.umich.edu
To: tcp-ip@NIC.DDN.MIL
Message-Id: <4865673@um.cc.umich.edu>
Subject: Re:  DoD --> CMOT and SNMP

>name recognition).  I believe the confusion arises here from what I
>find to be common misspeak - refering to OSI when one actually should
>refer to ISO.  Particularly, the phrase "an OSI network" where the
>intention is "a network based upon the ISO protocol suite".  This may not
 
I don't believe that the term "OSI network" is incorrect.  There are
numerous protocols with ISO standards numbers, but only a subset of
those are protocols intended to support the OSI service definitions of
particular layers.  For example, the official title of ISO 8473,
commonly known as "ISO IP", is "Protocol for providing the connectionless
mode network service" (where said service is defined by the OSI network
service definition).
 
For what it's worth, in my experience folks around the standards community 
commonly refer to these things as "OSI protocols" and "OSI networks."
 
[cue the sound of a hair splitting]

Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Mon, 11 Sep 89 21:17:50 EDT
Received: from talcott.harvard.edu by NIC.DDN.MIL with TCP; Mon, 11 Sep 89 16:56:04 PDT
Received: from tien.Wellfleet.Com by wellfleet.com (3.2/SMI-3.2)
	id AA25964; Mon, 11 Sep 89 19:36:48 EDT
Received: by tien.Wellfleet.Com (3.2/SMI-3.2)
	id AA11964; Mon, 11 Sep 89 19:35:30 EDT
Date: Mon, 11 Sep 89 19:35:30 EDT
From: Philip Prindeville <pprindev@wellfleet.com>
Message-Id: <8909112335.AA11964@tien.Wellfleet.Com>
To: little@SAIC.COM, mcc@WLV.IMSD.CONTEL.COM
Subject: Re:  DoD --> CMOT and SNMP
Cc: tcp-ip@nic.ddn.mil

I don't think I'm the one who originally mentioned ISO, though
Mike is correct about the loose general use of ISO vs OSI.
Since ISO seems to be the only stack that is strictly compliant 
(complacent?) with the 7 layer model, most people mix the two.
I believe I only mentioned XNS and DECnet.  Karl Auerbach
originally threw out OSI [sic].

I assumed that Karl was referring to ISO 8473 (CLNS), etc.  Did
I misunderstand?

-Philip

P.S.	Merton: Did you switch employers recently?

Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Tue, 12 Sep 89 12:11:22 EDT
Received: from WLV.IMSD.CONTEL.COM by NIC.DDN.MIL with TCP; Tue, 12 Sep 89 05:56:01 PDT
Received: by WLV.IMSD.CONTEL.COM (5.61/1.25)
	id AA26604; Tue, 12 Sep 89 05:53:47 -0700
Date: Tue, 12 Sep 89 05:53:47 -0700
From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
Message-Id: <8909121253.AA26604@WLV.IMSD.CONTEL.COM>
To: little@SAIC.COM, mcc@WLV.IMSD.CONTEL.COM, pprindev@wellfleet.com
Subject: Re:  DoD --> CMOT and SNMP
Cc: tcp-ip@nic.ddn.mil

Over the past year, I've noticed the more frequent use of OSI in briefings
and publications to refer to the ISO suite of protocols.  I was beginning to
wonder if while mucking about with AUTODIN, IDHS, and a host of other lesser
known networks I had missed something.

Merton

P.S.  Phil:  I'm still at the same stand.  Since Bunker Ramo was formed by
             Martin and Ramo Woolridge, we've been Allied, Eaton, and Contel.
             The last change occurred a year ago but the domain name change
             didn't occur until June.

Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Fri, 15 Sep 89 02:33:29 EDT
Received: from A.ISI.EDU by NIC.DDN.MIL with TCP; Thu, 14 Sep 89 21:53:16 PDT
Date: Fri 15 Sep 89 00:48:41-EDT
From: Dan Lynch <LYNCH@A.ISI.EDU>
Subject: Re:  DoD --> CMOT and SNMP
To: robert@trwind.ind.trw.com
cc: mcsun!cernvax!cgch!wasc@uunet.uu.net, tcp-ip@nic.ddn.mil, lynch@A.ISI.EDU
In-Reply-To: <8909071738.AA04966@trwind.ind.TRW.COM>
Message-ID: <12526341449.22.LYNCH@A.ISI.EDU>

Robert,  I've been away, so sorry for a late reply, but I have also
had a chance to see other replies and must add my two cents worth.

OSI stands for Open Systems Interconnection.  ISO stands for International
Organization for Standardization.  (Yes, I know that the English/American
abbreviation for that should be IOS, but it ain't that way this time...)

OSi describes a model of communication among consenting systems.  It was
described in an ISO document many years ago.  Then ISO committees
began to fill out thier interpretations of how to accomplish the lofty
goals of the OSI model.  All of those "interpretations" have come aout as ISO 
documents.  It is easy to mix the two acronyms up because of their
use of the same alphabet symbols.  I used to find it useful to make
the distinction batween OSI and OSI.  I thought (and still do think) that 
the TCP/IP suite of protocols are quite in line withthe OSI "model".
So is DECNET, so is SNA, etc.  (I mean, hey, an application has just got to
shove the bits out the "right" interface/wire to an equally receptive
application at the target system; how many ways can you describe to do that?
In 1976 it was an accomplishment to even make that description.  By this 
tim ein history it is a freshman problem, right?)

So, today, we should quit splitting haris, and let the meaning of "OSI"
be those protocols that are promulgated by ISO with regard to communications
between consenting computers.  (ISO also sets standards
for cement ingredients, numbers of threads per inch/millimeter for screws,
etc...)

In other words, it is a waste of energy for someone to say they are OSI
complinat unless they use the actual ISO protocols.  We technologists
may be able to sort his all out, but our customers should not have
to sort out our internal debates.  Let us let them see one label.
That label is OSI.

Dan
-------


-----------[000149][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 89 13:44:00 GMT
From:      mcdaniel%hqeis.decnet@HQAFSC-VAX.AF.MIL ("HQEIS::MCDANIEL")
To:        comp.protocols.tcp-ip
Subject:   RE: DOD ---> CMOT VERSUS SNMP

Andrews AFB

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

                                        Date:      15-Sep-1989 09:40am EST
                                        From:      Mr Rodney A McDaniel 
                                                   MCDANIEL 
                                        Dept:      HQ AFSC/SCXP
                                        Tel No:    981-7909/AV 858
                                        Owner:     Mr Rodney A McDaniel  *

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


Subject: RE: DOD ---> CMOT VERSUS SNMP


I HAVE BEEN READING ALL THE VARIOUS REPLIES CONCERNING DOD CMOT 
VERSUS SNMP, HOWEVER I HAVE BEEN UNABLE TO FIND A DEFINITION FOR 
CMOT.

WHAT DOES CMOT STAND FOR???

SECONDLY,  DOES ANYONE HAVE OR KNOW THE OFFICIAL DOD POLICY 
CONCERNING THE CMOT REQUIREMENT?? PLEASE SITE A DIRECTIVE OR OFFICIAL
PUBLICATION STATING CMOT WILL BE USED VICE SNMP FOR THE FUTURE.

THIRDLY, I DON'T SEE A COMPLETE ANSWER TO THE FIRST MESSAGE CONCERNING DOD 
CMOT VERSUS SNMP. BOTH QUESTIONS HAVE BEEN SIDE-TRACKED BY THE OSI & 
ISO PROTOCOL ISSUES.  ALSO DOES ANYONE ACTUALLY HAVE A CMOT 
IMPLEMENTATION, WHICH COULD REALLY ADVISE THE REST OF THE WORLD THE 
ADVANTAGES OR DRAWBACKS VERSUS THE EXISTING SNMP BEING USED???

ATTACHED IS A LISTING OF ALL THE REPLIES CONCERNING THIS SUBJECT, 
BUT HAVE THE ORIGINAL QUESTIONS REALLY BEEN ANSWERED AND PROVIDED THE 
NEEDED INFORMATION TO END THE CONTROVERSY ON CMOT AND SNMP.

I HAVE ADDED A ASBESTOS AND THREE FOOT THICK STEEL WALLS AROUND MY 
EMAIL TERMINAL FOR ANY POSSIBLE FLAMING REPLIES OR LAUNCHING OF ANY
MISSILES. SO REPLIES CAN BE SENT TO: MCDANIEL@HQAFSC-VAX.AF.MIL.


RODNEY A. MCDANIEL
AFSC DDN PROGRAM MANAGER
PROGRAMS DIVISION

 Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Fri,  1 Sep 89 22:35:28 EDT
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 1 Sep 89 11:04:39 PDT
Received: by ucbvax.Berkeley.EDU (5.61/1.37)
	id AA13385; Fri, 1 Sep 89 10:35:18 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 1 Sep 89 11:28:54 GMT
From: mcsun!cernvax!cgch!wasc@uunet.uu.net  (Armin Schweizer)
Organization: WRZ, CIBA-GEIGY Ltd, Basel, Switzerland
Subject: DoD --> CMOT and SNMP
Message-Id: <873@cgch.UUCP>
Sender: tcp-ip-relay@NIC.DDN.MIL
To: tcp-ip@NIC.DDN.MIL



From one of our network devices suppliers I got the information,
that the DoD will request from all suppliers, that their
respective products support CMOT. 
I did not hear the same for SNMP. Is this valid for SNMP too?

What are the advantages of CMOT compared with SNMP, which
make the DoD chose CMOT as their favorite network management
vehicle? (Both, CMOT and SNMP use the same management information
base!?)

Who knows of or runs a CMOT implementation? I would like
to have a direct contact.

kind regards
armin


       Armin R. Schweizer, CIBA-GEIGY AG, R1045.P.06, WRZ
                  4002 Basel / Switzerland
	          phone: -41-61-697'79'46
 
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Sat,  2 Sep 89 07:38:04 EDT
Received: from ahwahnee.Stanford.EDU by NIC.DDN.MIL with TCP; Fri, 1 Sep 89 21:47:14 PDT
Received: by ahwahnee.Stanford.EDU; Fri, 1 Sep 89 21:40:26 PDT
Date: Fri, 1 Sep 89 21:40:26 PDT
From: Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
Subject: Re:  DoD --> CMOT and SNMP
To: tcp-ip@nic.ddn.mil

(Sorry.  I intended to send this to the entire list. DHC)
From dcrocker Fri Sep  1 21:28:53 1989
From: Dave Crocker <dcrocker>
Subject: Re:  DoD --> CMOT and SNMP
To: mcsun!cernvax!cgch!wasc@uunet.uu.net
	
The Internet Activities Board has declared SNMP and CMOT to be co-equal
standards.  If effect, this means that they both have a stamp of approval
from a significant "standards" body.  (For the TCP/IP technology, the
IAB fills the kind of role that ISO and CCITT and ECMA do in various
parts of international communities.
	
So much for the stamp of approval.
	
Your question is more to the point and asks about actual support by
vendors.  (A nicely practical point to have concern for.)
	
A number of companies are currently shipping products that use SNMP.
Further, the NSFNet is managed using it.  It is my impression that virtually
all TCP/IP vendors have announced intent to support SNMP, if they are not
already doing so.
	
SNMP is unique to the TCP/IP community, although it uses the OSI ASN.1
encoding standard, for specifying the format of objects.  CMOT is derived
from the OSI CMOT standards effort, although I am told there are some
differences.  It is not clear to me that these differences are in the
management protocol, itself, it does run over a modified stack of
support protocols.  Most significantly, is uses TCP or, perhaps, UDP,
instead of an OSI transport.  Hence, CMOT gets you closer to the future
of OSI network management protocol details.
	
However, there does not appear to be any vendor that currently ships
CMOT and, therefore, there is no field (production network) experience
using it.  While a number of vendors have announced plans to support
CMOT, I am not aware of any official, announced, delivery dates from
these vendors.
	
A further point about the recent decision to make SNMP and CMOT co-equal
standards is that their use of the Management Information Base (MIB) was
entirely de-coupled.  While one should expect them to continue to use the
original 100 variable, there having additional variable in common is
problematic.  At the least, such sharing should be expected to organic or
accidental, rather than formally enforced.  (That should be "expected to
be organic..."  I am on a thin wire with a poor editor.)
	
As always, I trust that others will elaborate on, as well as correct,
the above.  Dive in!
	
	Dave Crocker
	Digital Equipment Corp.
	

P.S.  On review, I note that I did not respond to your query about 
federal requirements for CMOT support:  There is strong governmental
pressure for moving to OSI.  This is embodied in the GOSIP document.
In general, however, the requirements are careful to allow use of
alternatives.  Perhaps the most extreme way of viewing this is that a
vendor certainly cannot consider ignoring the OSI CMOT.  I am less clear
about their ability to dodge CMOT (but am sure that someone out there in
tcp-land will chime in to clarify, please?)  Enough vendors have stated
intent to support CMOT and enough are working on it, that I would expect it
to start showing up in the future.

P.P.S.  I should use this opportunity to suggest a personal bias.  It is NOT
about which protocol I prefer.  In fact, the brouhaha has, in my opinion,
distracted us from worrying about how to manage multi-administration
inter-networks.  The chosen protocol is not irrelevant to this, but my
suspicion is that we could start with a hopelessly incomplete one and 
still not know how to use it to its fullest.

That is, our general understanding and pursuit of specifying and
developing management (application) SERVICES has been quite limited
and that we would do well to focus on MIB enhancement and specification
of standard applications for management.  (I.e., focus on the bottom
and top of the management architecture.)

D/
 
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Wed,  6 Sep 89 22:22:50 EDT
Received: from solbourne.nyser.net by NIC.DDN.MIL with TCP; Wed, 6 Sep 89 13:14:12 PDT
Received: from localhost by solbourne.nyser.net (5.61/2.1-NYSERNet Research & Development)
	id AA06725; Wed, 6 Sep 89 16:07:48 -0400
Message-Id: <8909062007.AA06725@solbourne.nyser.net>
To: mcsun!cernvax!cgch!wasc@uunet.uu.net (Armin Schweizer)
Cc: tcp-ip@NIC.DDN.MIL
Subject: Re: DoD --> CMOT and SNMP 
In-Reply-To: Your message of 01 Sep 89 11:28:54 +0000.
             <873@cgch.UUCP> 
Date: Wed, 06 Sep 89 16:07:46 -0400
From: "Marty Schoffstall" <schoff@solbourne.nyser.net>


    

    >From one of our network devices suppliers I got the information,
    that the DoD will request from all suppliers, that their
    respective products support CMOT. 
    I did not hear the same for SNMP. Is this valid for SNMP too?

On paper according to the RFC's they are both to be implemented by
vnedors/suppliers.  SNMP exists and this for the most part all TCP/IP
vendors either ship SNMP in their product or are committed to in
their next release.   Marketing research orgnizations are responsible
for exact numbers and analysis but I'm aware of 20-25 implementations
that you can buy today.

    What are the advantages of CMOT compared with SNMP, which
    make the DoD chose CMOT as their favorite network management
    vehicle? (Both, CMOT and SNMP use the same management information
    base!?)

CMOT's advantage is that it is theoretically aligned with the International
Standard Organizations (ISO) program.

    Who knows of or runs a CMOT implementation? I would like
    to have a direct contact.

To my knowledge no one runs this in an operational network and I haven't
heard of the availablility of interoperable CMOT implementations.

Marty
 
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Fri,  8 Sep 89 02:58:15 EDT
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 7 Sep 89 22:50:53 PDT
Received: by ucbvax.Berkeley.EDU (5.61/1.37)
	id AA08939; Thu, 7 Sep 89 22:42:26 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 7 Sep 89 19:53:16 GMT
From: fernwood!asylum!karl@apple.com  (Karl Auerbach)
Organization: The Asylum; Belmont, CA
Subject: Re:  DoD --> CMOT and SNMP
Message-Id: <3853@asylum.SF.CA.US>
References: <8909021142.AA08148@ucbvax.Berkeley.EDU>
Sender: tcp-ip-relay@NIC.DDN.MIL
To: tcp-ip@NIC.DDN.MIL

In article <8909021142.AA08148@ucbvax.Berkeley.EDU> dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) writes:
>	SNMP is unique to the TCP/IP community,

Not quite true -- one could use SNMP to manage an OSI network.

			--karl--
 
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Fri,  8 Sep 89 23:37:26 EDT
Received: from trwind.ind.TRW.COM by NIC.DDN.MIL with TCP; Thu, 7 Sep 89 10:39:27 PDT
Received: by trwind.ind.TRW.COM (5.54/1.36)
	id AA04966; Thu, 7 Sep 89 10:38:59 PDT
Date: Thu, 7 Sep 89 10:38:59 PDT
From: robert@trwind.ind.trw.com (Robert W. Snyder)
Message-Id: <8909071738.AA04966@trwind.ind.TRW.COM>
To: mcsun!cernvax!cgch!wasc@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject: Re:  DoD --> CMOT and SNMP
Cc: robert@trwind.ind.TRW.COM

>>From one of our network devices suppliers I got the information,
>that the DoD will request from all suppliers, that their
>respective products support CMOT. 
>I did not hear the same for SNMP. Is this valid for SNMP too?
>

A major Air Force contract (ULANA) is considering requiring either SNMP
or CMOT implementations.  There are two major contractors on this
contract that are competing against one another.  One contractor
(TRW - us) is supporting SNMP, the other contractor (EDS teamed with
3com/bridge) is supporting CMOT.  Since the government is 
considering requiring the code after the contract award, 
they were sort of forced into excepting both or getting into a hassle
with one of the two vendors by giving the other an unfair advantage. 

Since this contract will be a buying vehicle DoD wide, it could
by that this is what your vendor is talking about.  I could give
you a good breakdown of vendor support for both, but I dont think
that would be fair since I do not represent a disinterested third
party.  For anyone interested in gathering this information.  I
suggest that they attend Interop in San Jose where all the vendors
will be available to ask.

If anyone is aware of anything else that might be influencing
SNMP vs CMOT in the DOD world I would appreciate a reply

Hope this helps

Robert Snyder       Disclaimer  --  nobody claims dis, but me
TRW Information Networks Division 23800 Hawthorne Blvd, Torrance CA 90505
USENET: trwind!robert
INTERNET: robert@trwind.TRW.COM                   Phone 213-373-9161
 
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Sun, 10 Sep 89 14:13:32 EDT
Received: from talcott.harvard.edu by NIC.DDN.MIL with TCP; Sun, 10 Sep 89 09:52:05 PDT
Received: from tien.Wellfleet.Com by wellfleet.com (3.2/SMI-3.2)
	id AA21304; Sun, 10 Sep 89 02:42:04 EDT
Received: by tien.Wellfleet.Com (3.2/SMI-3.2)
	id AA04290; Sun, 10 Sep 89 02:40:49 EDT
Date: Sun, 10 Sep 89 02:40:49 EDT
From: Philip Prindeville <pprindev@wellfleet.com>
Message-Id: <8909100640.AA04290@tien.Wellfleet.Com>
To: fernwood!asylum!karl@apple.com
Subject: Re:  DoD --> CMOT and SNMP
Cc: tcp-ip@nic.ddn.mil

>> 	SNMP is unique to the TCP/IP community,
 
> Not quite true -- one could use SNMP to manage an OSI network.
 
Or DECnet, or XNS, or NetWare, or even a bridge (via SNMP over Ethernet).
(We don't have bridge control yet).

-Philip
 
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Mon, 11 Sep 89 10:12:06 EDT
Received: from WLV.IMSD.CONTEL.COM by NIC.DDN.MIL with TCP; Mon, 11 Sep 89 05:41:00 PDT
Received: by WLV.IMSD.CONTEL.COM (5.61/1.25)
	id AA24396; Mon, 11 Sep 89 05:35:14 -0700
Date: Mon, 11 Sep 89 05:35:14 -0700
From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
Message-Id: <8909111235.AA24396@WLV.IMSD.CONTEL.COM>
To: fernwood!asylum!karl@apple.com, pprindev@wellfleet.com
Subject: Re:  DoD --> CMOT and SNMP
Cc: tcp-ip@nic.ddn.mil

>>>      SNMP is unique to the TCP/IP community,
 
>> Not quite true -- one could use SNMP to manage an OSI network.

Excuse me, I'm confused.  I thought that OSI was a model which described
the procedures (steps) to establish a connection and transfer data between
two nodes on a network regardless of the protocol suite employed.  The ISO
IP/TPn and Internet TCP/IP protocol suites can be described by the model
as can networks based on Digital's DCA protocol suite, IBM's BSC protocol,
and the ISO 1745 protocol.

Merton
 
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Mon, 11 Sep 89 14:24:26 EDT
Received: from ASLAN.SAIC.COM by NIC.DDN.MIL with TCP; Mon, 11 Sep 89 08:15:42 PDT
Received: by ASLAN.SAIC.COM (4.0/4.7)  id AA04861; Mon, 11 Sep 89 11:12:43 EDT
Date: Mon, 11 Sep 89 11:12:43 EDT
From: Mike Little <little@SAIC.COM>
Message-Id: <8909111512.AA04861@ASLAN.SAIC.COM>
To: mcc@WLV.IMSD.CONTEL.COM
Subject: Re:  DoD --> CMOT and SNMP
Cc: tcp-ip@nic.ddn.mil


>> Not quite true -- one could use SNMP to manage an OSI network.
 
>Excuse me, I'm confused.  I thought that OSI was a model which described
>the procedures (steps) to establish a connection and transfer data between
>two nodes on a network regardless of the protocol suite employed.  The ISO
>IP/TPn and Internet TCP/IP protocol suites can be described by the model
>as can networks based on Digital's DCA protocol suite, IBM's BSC protocol,
>and the ISO 1745 protocol.

OSI is an architectural model (one of many and the one with the most
name recognition).  I believe the confusion arises here from what I
find to be common misspeak - refering to OSI when one actually should
refer to ISO.  Particularly, the phrase "an OSI network" where the 
intention is "a network based upon the ISO protocol suite".  This may not
be exactly what Phillip intended (Phillip please interject if this is 
nowhere close), but looks like where the confusion is arising from.

					-Mike

 
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Mon, 11 Sep 89 19:28:38 EDT
Received: from shadooby.cc.umich.edu by NIC.DDN.MIL with TCP; Mon, 11 Sep 89 15:37:32 PDT
Received: from ummts.cc.umich.edu by shadooby.cc.umich.edu (5.61/1.0)
	id AA01459; Mon, 11 Sep 89 18:35:22 -0400
Date: Mon, 11 Sep 89 18:34:52 EDT
From: Dave_Katz@um.cc.umich.edu
To: tcp-ip@NIC.DDN.MIL
Message-Id: <4865673@um.cc.umich.edu>
Subject: Re:  DoD --> CMOT and SNMP

>name recognition).  I believe the confusion arises here from what I
>find to be common misspeak - refering to OSI when one actually should
>refer to ISO.  Particularly, the phrase "an OSI network" where the
>intention is "a network based upon the ISO protocol suite".  This may not
 
I don't believe that the term "OSI network" is incorrect.  There are
numerous protocols with ISO standards numbers, but only a subset of
those are protocols intended to support the OSI service definitions of
particular layers.  For example, the official title of ISO 8473,
commonly known as "ISO IP", is "Protocol for providing the connectionless
mode network service" (where said service is defined by the OSI network
service definition).
 
For what it's worth, in my experience folks around the standards community 
commonly refer to these things as "OSI protocols" and "OSI networks."
 
[cue the sound of a hair splitting]
 
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Mon, 11 Sep 89 21:17:50 EDT
Received: from talcott.harvard.edu by NIC.DDN.MIL with TCP; Mon, 11 Sep 89 16:56:04 PDT
Received: from tien.Wellfleet.Com by wellfleet.com (3.2/SMI-3.2)
	id AA25964; Mon, 11 Sep 89 19:36:48 EDT
Received: by tien.Wellfleet.Com (3.2/SMI-3.2)
	id AA11964; Mon, 11 Sep 89 19:35:30 EDT
Date: Mon, 11 Sep 89 19:35:30 EDT
From: Philip Prindeville <pprindev@wellfleet.com>
Message-Id: <8909112335.AA11964@tien.Wellfleet.Com>
To: little@SAIC.COM, mcc@WLV.IMSD.CONTEL.COM
Subject: Re:  DoD --> CMOT and SNMP
Cc: tcp-ip@nic.ddn.mil

I don't think I'm the one who originally mentioned ISO, though
Mike is correct about the loose general use of ISO vs OSI.
Since ISO seems to be the only stack that is strictly compliant 
(complacent?) with the 7 layer model, most people mix the two.
I believe I only mentioned XNS and DECnet.  Karl Auerbach
originally threw out OSI [sic].

I assumed that Karl was referring to ISO 8473 (CLNS), etc.  Did
I misunderstand?

-Philip

P.S.	Merton: Did you switch employers recently?
 
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Tue, 12 Sep 89 12:11:22 EDT
Received: from WLV.IMSD.CONTEL.COM by NIC.DDN.MIL with TCP; Tue, 12 Sep 89 05:56:01 PDT
Received: by WLV.IMSD.CONTEL.COM (5.61/1.25)
	id AA26604; Tue, 12 Sep 89 05:53:47 -0700
Date: Tue, 12 Sep 89 05:53:47 -0700
From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
Message-Id: <8909121253.AA26604@WLV.IMSD.CONTEL.COM>
To: little@SAIC.COM, mcc@WLV.IMSD.CONTEL.COM, pprindev@wellfleet.com
Subject: Re:  DoD --> CMOT and SNMP
Cc: tcp-ip@nic.ddn.mil

Over the past year, I've noticed the more frequent use of OSI in briefings
and publications to refer to the ISO suite of protocols.  I was beginning to
wonder if while mucking about with AUTODIN, IDHS, and a host of other lesser
known networks I had missed something.

Merton

P.S.  Phil:  I'm still at the same stand.  Since Bunker Ramo was formed by
             Martin and Ramo Woolridge, we've been Allied, Eaton, and Contel.
             The last change occurred a year ago but the domain name change
             didn't occur until June.
 
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Fri, 15 Sep 89 02:33:29 EDT
Received: from A.ISI.EDU by NIC.DDN.MIL with TCP; Thu, 14 Sep 89 21:53:16 PDT
Date: Fri 15 Sep 89 00:48:41-EDT
From: Dan Lynch <LYNCH@A.ISI.EDU>
Subject: Re:  DoD --> CMOT and SNMP
To: robert@trwind.ind.trw.com
cc: mcsun!cernvax!cgch!wasc@uunet.uu.net, tcp-ip@nic.ddn.mil, lynch@A.ISI.EDU
In-Reply-To: <8909071738.AA04966@trwind.ind.TRW.COM>
Message-ID: <12526341449.22.LYNCH@A.ISI.EDU>

Robert,  I've been away, so sorry for a late reply, but I have also
had a chance to see other replies and must add my two cents worth.

OSI stands for Open Systems Interconnection.  ISO stands for International
Organization for Standardization.  (Yes, I know that the English/American
abbreviation for that should be IOS, but it ain't that way this time...)

OSi describes a model of communication among consenting systems.  It was
described in an ISO document many years ago.  Then ISO committees
began to fill out thier interpretations of how to accomplish the lofty
goals of the OSI model.  All of those "interpretations" have come aout as ISO 
documents.  It is easy to mix the two acronyms up because of their
use of the same alphabet symbols.  I used to find it useful to make
the distinction batween OSI and OSI.  I thought (and still do think) that 
the TCP/IP suite of protocols are quite in line withthe OSI "model".
So is DECNET, so is SNA, etc.  (I mean, hey, an application has just got to
shove the bits out the "right" interface/wire to an equally receptive
application at the target system; how many ways can you describe to do that?
In 1976 it was an accomplishment to even make that description.  By this 
tim ein history it is a freshman problem, right?)

So, today, we should quit splitting haris, and let the meaning of "OSI"
be those protocols that are promulgated by ISO with regard to communications
between consenting computers.  (ISO also sets standards
for cement ingredients, numbers of threads per inch/millimeter for screws,
etc...)

In other words, it is a waste of energy for someone to say they are OSI
complinat unless they use the actual ISO protocols.  We technologists
may be able to sort his all out, but our customers should not have
to sort out our internal debates.  Let us let them see one label.
That label is OSI.

Dan
-------

-----------[000150][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 89 14:30:37 GMT
From:      alan@oetl.UUCP (Alan Strassberg)
To:        comp.protocols.tcp-ip
Subject:   Re: CMU TCP/IP for VMS wanted

In article <11891@cit-vax.Caltech.Edu> doug@seismo.gps.caltech.edu (Doug Neuhauser) writes:

>Can anyone point me to a name, address, phone # or email address to get
>information and order CMU's TCP/IP package for VMS?  I assume they are still

	Inquiries and orders to:
	Joanna Tarr
	(412) 268-5896   voice
	(412) 268-5249   fax

	JTIZ@VB.CC.CMU.EDU Arpanet
	JTIZ@CMCCVB        Bitnet

	There is a bulletin board for this unsupported package:
	CMU-TEK-TCP@CS.CMU.EDU

	Prices:
	1600 bpi magtape with manuals 	$125
	(if using a P.O. add $25)

					alan
-- 
Alan Strassberg             alan@oetl.scf.lockheed.com
(408) 425-6139              ...!uunet!lstc!oetl!alan 

-----------[000151][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 89 16:41:35 GMT
From:      freeman-andrew@CS.YALE.EDU (Andrew C. Freeman)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   TCP/IP over SNA



We need some advice on a couple of issues.  Any comments or information
would be greatly appreciated.

   Location 1: Sun 4/390s running a Sybase server
 
   Locations 2,3,4,5: Small Sun networks across the country

What we hope to accomplish is the following:

     Transparent client access from locations 2-5 to the server at 
     location 1 (i.e. ability to use Sybase as if we were one local net),
     as well as telnet, etc.

At our disposal is an SNA network connecting all the sites. We would prefer
to use it but if there are other cost effective ways we will certainly 
consider them.  The real questions here are whether TCP/IP over SNA is 
possible/feasible/tolerable and whether Sybase DB-library functions well
over an internet

A side issue involves SNA on Sun. Can we support a user (either logged in
via telnet to the server or directly from locations 2-5) who wants a 
terminal session to an IBM host on the SNA network and can we support 
application to application from the Sun server to the IBM host.

Thanks in advance for those copious, informative replies. Please reply by
mail and include a telephone number if you would'nt mind a phone call. Also,
I realize that these topics may be fairly standard to some but please, don't
let my ignorance dissuade you from replying.

                   Thanks,
                   Andrew

    

-----------[000152][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 89 19:11:24 GMT
From:      fin@UF.MSC.UMN.EDU ("Craig Finseth")
To:        comp.protocols.tcp-ip
Subject:   Subnet 0


	Is is "allowed" (i.e., technically legal)?

Undefined.  Network number 0 means "this net."  By analogy subnet
number 0 means "this subnet."  You won't find this mentioned anywhere
official, that's why it is undefined.

	Is it a "good idea?"

Definite no.  It will work mostly, in some circumstances.  It is not
guaranteed to work "properly."  If you look hard enough (or if someone
installs some new equipment on Friday afternoon), you will find some
equipment that it won't work with

I suggest that you ease the users of that subnet to a new one as soon
as convenient.

BTW, Are you the Andy Kobayashi that I knew from Carolingia?  If so,
hello.  If not, my apologies for the mistake.

Craig A. Finseth			fin@msc.umn.edu [CAF13]
Minnesota Supercomputer Center, Inc.	(612) 624-3375
(Cayle of Firwood)

-----------[000153][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 89 20:19:23 GMT
From:      denbeste@bgsuvax.UUCP (William C. DenBesten)
To:        comp.protocols.misc,comp.protocols.tcp-ip
Subject:   Looking for an out-of-band control protocol.

I am looking for information on existing or proposed protocols that
support a control message path seperate from the data path, utilizing
tcp/ip or udp/ip.

Please send replies directly to
	denbeste@bgsu.edu
	computer-science@bgsu.edu
	denbesten@bgsuopie.bitnet
Thank you.

-- 
William C. DenBesten   is   denbeste@bgsu.edu  or   denbesten@bgsuopie.bitnet

-----------[000154][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 89 20:20:45 GMT
From:      jeffr@sco.COM (Jeff Radick)
To:        comp.protocols.tcp-ip.ibmpc,comp.protocols.tcp-ip
Subject:   Re: Query on NetBIOS on TCP/IP

In article <12445@orstcs.CS.ORST.EDU> harish@guille.ECE.ORST.EDU (Harish Pillay) writes:
+The RFCs 1001 and 1002 define using TCP/IP over NetBIOS systems.  After
+reading the RFCs, I'm confused over one point. Assuming an implementation 
+of TCP/IP over NetBIOS, can a user on a Unix box say ftp into the PC (assuming 
+a ftp server is running in the PC)?  My understanding is that the user on the 
+Unix box has to have a NetBIOS-specific TCP/IP implementation.  Is that right?
+If not, it is unclear to me how that user can ftp from the pc.  Conversely, can
+we ftp etc from the same PC to other Unix boxes who *don't* have the NetBIOS 
+stuff?  I think I'm missing something here and would appreciate any hints and 
+pointers.  I hope this is not a RTFM-type of question :-).

You are confused.  RFCs 1001 and 1002 define an standardized way for
systems to provide the NetBIOS services on top of TCP/IP, not the
other way around.  RFC 1001 defines general concepts about how this
works, and RFC1002 defines the protocol to be used between the machines
providing this service.

Thus a system that has this service has TCP/IP as an underlying mechanism
in the same way TCP/IP is there as an underlying mechanism for, say,
FTP.  If your TCP/IP software has these other utilties then the NetBIOS
stuff will appear essentially to be just another service like FTP or
TELNET, except that NetBIOS uses both TCP and UDP in a certain coordinated
way as defined in the RFCs.  (This is an oversimplification, but essentially
correct.)  NetBIOS therefore should not interfere with the operation of
FTP or any of your other ordinary TCP/IP-related services, except perhaps
by virtue of resource usage, which is completely dependent upon implementation
and system usage.

More particularly in response to your question, FTP on a system with
NetBIOS will operate exactly like FTP on a system without NetBIOS,
and interoperability should not be a problem.

There are, I believe, TCP/IP implementations
on top of NetBIOS, but this is not what these RFCs are about, and in my
opinion such an idea is mostly bogus since NetBIOS presumes the existence
of some underlying mechanism such as TCP/IP for conveying information
between systems, so that putting TCP/IP on top of that would be largely
redundant if not completely bizarre.

+
+While on the same subject, is there any PD implementations of TCP/IP over
+NetBIOS systems?
+
+ ...

Assuming what you mean is NetBIOS over TCP/IP and not vice versa:
unfortunately I don't know the answer to this question.  I know it has
been asked before in this newsgroup, perhaps one of the people who
has gotten a response (or a lack thereof) can answer.

Of course I should mention that SCO's TCP/IP product (not the so-called
controlled release), as well as others, such as Excelan's, includes
a NetBIOS module as part of the standard product.  If you are not using
one of these then of course you will want a PD implementation.

Jeff Radick
The Santa Cruz Operation, Inc.
jeffr@sco.COM or ucscc!sco!jeffr or uunet!sco!jeffr or just sco!jeffr

-----------[000155][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 89 20:28:09 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re:  DoD --> CMOT and SNMP

Dan--
   Speaking of "OSI complinat" [or even compliant], I noted with great
interest in the latest issue of _conneXions_ that "some applications
(for example, X.400, version 1984) access Session services directly",
according to the lead article, "Components of OSI: The Session Service"
(p. 2).
   So even if we stipulate that it's undignified lawyering to distinguish
between "OSI" and "osi" (which is what I assume you meant to type), there's
still the fascinating question of whether we get to distinguish between
OSI, The Heralded "Reference Model" and OSI, The Not-Necessarily-Compliant
ISO-Blessed Protocols.  (Note that the question-begging phrase "Protocol
Suite" was intentionally avoided.)  For the RM, as we know, requires that all
"n-entities" communicate with their peer n-entities via "n-1 entities"
[give or take a hyphen]; the I-BP, however--perhaps in conformance to, if not
with, the by-now-ancient Padlipsky's Law which holds that "It's Layer [sic]
5-7"?--have no such compunction, as we've learned before and have just
been reminded again.
   (Aside to purists: no, "reminded again" isn't redundant--though "reminded
of again" might be a tad more idiomatic.)
   Or are the tales that X.400 is/are I-BP unfounded?
   Or maybe there's a new RM?
   I mean, I'd actually kinda like to take the Mother Knows Best approach
myself: the Fuller Context, after all, is that "a prophet is not without
honor save in his own country _and in his own house_", and that gets rather
old after the first dozen years.  But what's a dutiful child to do when
Mother keeps contradicting herself?
   perplexed cheers,
         map

P.S.  Feel free to try to influence the editor of _conneXions_ to run
your msg (with referenced typoes preserved, please) and the above as
Letters to the Editor, if you like--but remember: no copyediting of
my stuff, and I get to reply to your response if you make one....
-------

-----------[000156][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 89 20:59:34 GMT
From:      jeffr@sco.COM (Jeff Radick)
To:        comp.protocols.tcp-ip
Subject:   Use and misuse of OSI model (was Re:  DoD --> CMOT and SNMP)

In article <8909111235.AA24396@WLV.IMSD.CONTEL.COM> mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes:
> ...
>Excuse me, I'm confused.  I thought that OSI was a model which described
>the procedures (steps) to establish a connection and transfer data between
>two nodes on a network regardless of the protocol suite employed.  The ISO
>IP/TPn and Internet TCP/IP protocol suites can be described by the model
>as can networks based on Digital's DCA protocol suite, IBM's BSC protocol,
>and the ISO 1745 protocol.
> ...

I think that whether what you say is true or not depends largely upon
how you think of the OSI model.

Note first of all that regardless of the interpretation, OSI is indeed
a model but does not "describe procedures (steps) to establish a connection
... [etc]".  OSI is a model of computer communication that defines general
principles of protocol layering, and defines a particular set of
layers that are defined to profide a particular set of services that
interact in a particular set of ways, all for the purpose of communicating
between computer systems.  The OSI model does NOT define procedures for
establishing communication or for transferring data, except for the manner
in which some layers provide services to layers above them.  For the most
part, procedures are defined by the particular protocol definitions themselves.

OSI purists will generally flame about your interpretation since
the "Reference Model of Open Systems Interconnection" was defined
by ISO as a specific framework within which to develop future ISO
protocols.  Thus the OSI model per se is not, in its purest interpretation,
a general framework to be applied to other protocols.  It does
work for recent CCITT-defined protocols since CCITT has adopted
the ISO OSI model (International Standard 7498) almost verbatim
as CCITT recommendation X.200.

The non-purist will consider this quibbling, since the OSI reference
model can be taken as a general conceptual model which reasonably
describes the functions undertaken by other protocol suites, in a
reasonably modular form.

However, use of the OSI model in the non-purist sense should also
be done with care since most other protocol suites were built upon
a different model, even if only trivially different; and trying to
fit non-ISO and non-CCITT protocols into this model can often be
like trying to force a square peg into a round hole.

For example, the TCP/IP protocol suite was, as I understand it,
designed with a 4-layer model in mind (application, transport,
internet, network; see e.g. "The DARPA Internet Protocol Suite"
on p. 2-27 of volume 2 of the _DDN_Protocol_Handbook_).
The ideas comprising the OSI network layer are spread out over
both the internet and network interface layers of the TCP/IP model,
so they do not make a neat fit with each other.

As another example, SNA is designed with a 5-layer model, which
completely fails to discuss the areas covered by the OSI Application
and Physical layers, and the layers in between have their functionality
sorted out in a way different from the OSI model, so again we do not
have a neat fit.

Anyway, my point is that
(1) Only the ISO and CCITT protocols designed for the OSI model can
    be properly said to fit this model;
(2) Use of this model to describe other protocol suites can be useful
    but should be done with care.

My $.02 on the matter.

Jeff Radick
Networking & Communications
The Santa Cruz Operation, Inc.
Internet MX mailers:	jeffr@sco.COM
UUCP:			uunet!sco!jeffr or ucscc!sco!jeffr or just sco!jeffr
Also probably usable:	sco.UUCP or sco.UU.NET (to route via uunet)

-----------[000157][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 89 21:12:33 GMT
From:      joshua@athertn.Atherton.COM (Flame Bait)
To:        comp.protocols.tcp-ip
Subject:   Re: rpc protocols

In an article samperi@marob.masa.com (Dominick Samperi) writes:
>Could people with RPC experience comment on the relative merits of
>the various RPC "standards": Sun's RPC/XDR, ASN.1 (Used by NetWise),
>and Apollo's (used by DEC?).? THanks!

You want to read my paper "A Comparison of Commercial RPC Systems".
It compares Apollo, Netwise, and Sun for speed and reliablity.
The paper is available via archive-server from joshua.atherton.com.
Send mail to archive-server@joshua.atherton.com containing the line:
send other comprpc.shar

The server will reply with a copy of the paper in troff format using the ME
macros, which has been shared.  If you send the line "send other comprpc.txt"
you will get a plaintext version of the paper.  The server's UUCP address is
{hpda,decwrl,sun,coherent,pyramid}!athertn!archive-server (note: no 'o' in 
atherton for the UUCP name).  

If you can not get a reply from the archive server, send me email, or give
me a call.

My paper is based on versions of the RPC software which are now about 10 
months old, and I plan to update may paper, but not for a month or three.

A Netwise employee (Tony Andrews) has distributed a 3 page summary
of speeds as he measured them, which I also have.  Tony's work is newer
than mine, but he works for one of the competing companies.  His paper
is in my archive also,  send one of the following lines to get it:
send other netwise.me.shar
send other netwise.mm.shar

He wrote the paper using the MM macros, and I tranlated it into the ME
macros, since I do not have the MM macros.  I do not keep a plaintext
version of this paper hanging around.  Sorry.

If you want more information on the various RPCs, give me a call.

Joshua Levy
--------                Quote: "If you haven't ported your program, it's not
Addresses:                      a portable program.  No exceptions."  
joshua@atherton.com          
{decwrl|sun|hpda}!athertn!joshua    work:(408)734-9822    home:(415)968-3718

-----------[000158][next][prev][last][first]----------------------------------------------------
Date:      15 Sep 89 22:05:16 GMT
From:      AFDDN.TCP-IP@GUNTER-ADAM.AF.MIL
To:        comp.protocols.tcp-ip
Subject:   plea for help


   I've been around the internet for some time now, and routinely read this
list.  I now find that I must become a lot more knowledgeable about the
workings of certain interfaces (luckily all based on unix to some degree).
I must become the host admin and general techie for three machines we 
recently obtained.
1) Sun 386i
2) DEC uVAX II w/ Ultrix 2.2
3) AT&T 3B2-600G w/ UNIX (but not BSD)

  The Sun has an ethernet inreface.  The uVAX has a DELQA ethernet interface
and an ACC 5250 X.25 card.  The AT&T has an ethernet interface and an ACC
X.25 card.  The AT&T is running TWG's WIN3B package.  I have several naive
questions about unix and connecting networks.

  On the DEC and the AT&T there are three files in /etc.  I roughly 
understand the files as follows.  hosts has host names and IP addresses for all
the hosts which you enter.  This table can be updated from hosts.txt, or so
I assume.  networks contains the names and net numbers of all the networks, 
which is also in hosts.txt.  Last there's gateways, which contains the 
network, gateway address, netmask, broadcast address and metric for all the
networks.  I understand there's a problem in building the gateways file
from hosts.txt, although I don't know the details.  

  For all the systems, the hardware is configured with an IP address and 
brought up using ifconfig.  For the the AT&T, inetinit brings up the 
internet software and reads inetinit.cf.  On the uVAX, inetd reads inet.conf
to get things going.  That's about the limit of what I know and some of it
may be wrong.

  Some first questions are:  Can each hw interface only have one IP address
given in the ifconfig??
What are the relationships between networks, gateways, hosts, and the IP 
addresses given in ifconfigs??
What is the difference between using "route add" and editing the gateways file?
Are there any well known bugs with any of the three interfaces I should
be concerned about (considering my current limited experience)??
Any help or pointers would be apprciated.
Please send directly to me so as not to flood this list with stuff 
most other readers might know.
Darrel B.
-------

-----------[000159][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 89 01:32:25 GMT
From:      CMH117@PSUVM.BITNET
To:        comp.protocols.tcp-ip
Subject:   UUCP --> FTP

I need to download files from a machine running strictly UUCP to a machine
running only FTP.  I've heard that this is impossible.

-----------[000160][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 89 18:09:53 GMT
From:      ilham@ATHENA.MIT.EDU (Ilhamuddin Ahmed)
To:        comp.protocols.tcp-ip
Subject:   Re:  Remote Printer Access protocol?


We have an implementation of the ECMA standard for Print Services in a
distributed environment. It is called the "Athena Palladium Print
System". We are now running version 1 at Athena and will be cutting a
distribution tape for preliminary (alpha) release shortly. Version 2
which follows exactly with the ECMA standard and contains features left
out of version 1 should be completed by early next year.

There are two documents that you may want to read - one is an overview
(11 pages) and the second is the design documents (120 pages). These
will soon be available by anonymous FTP and archive mail.  I will send
another message when it is in place (should be there in a few days).

If you have any questions, I would be happy to answer them but if they
can wait till you read the documents that would be great.

						- Ilham Ahmed
						  System Programmer
						  Project Athena, MIT.
						  ilham@athena.mit.edu

-----------[000161][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 89 18:18:59 GMT
From:      ilham@ATHENA.MIT.EDU (Ilhamuddin Ahmed)
To:        comp.protocols.tcp-ip
Subject:   Remote Printer Access protocol?


>	Date: Sat, 16 Sep 89 14:09:53 -0400
>	From: Ilhamuddin Ahmed <ilham@athena.mit.edu>
 
>	There are two documents that you may want to read - one is an overview
>	(11 pages) and the second is the design documents (120 pages). These
>	will soon be available by anonymous FTP and archive mail.  I will send
>	another message when it is in place (should be there in a few days).

Its already available for anonymous ftp from :

	ATHENA-DIST.MIT.EDU   (18.71.0.38) in ~ftp/pub/palladium/

The files are :

-rw-r--r--  1 14640      208309 Sep 14 18:12 pddesign.PS.Z
-rw-r--r--  1 14640      277188 Sep  7 12:57 pddesign.dvi
-rw-r--r--  1 14640       56066 Sep 14 18:12 usenix.PS.Z
-rw-r--r--  1 14640       33400 Sep  7 13:09 usenix.dvi


						- Ilham Ahmed
						  System Programmer
						  Project Athena, MIT
						  ilham@athena.mit.edu

-----------[000162][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 89 22:41:35 GMT
From:      pprindev@wellfleet.com (Philip Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re: Nagle algo. in Unix-TCP

> On our own we found that the difficulty was avoided by using the "sendmsg" ca!
> to send the two buffers in one call rather than using two "send" calls, one
> for each buffer.  Later, one correspondent suggested the same.

You could also use writev() for doing scatter/gather writes.

> _might_ fare better than more.  The typical applications programmer has likely 
> never heard of packets; to him the choice of one "sendmsg" vs. many "sends"
> is mainly one of programming convenience, which might well come down in
> favor of the latter.  In fact, in our case the multiple "send" approach
> yields the shortest, cleanest program.

Perhaps.  But he has heard of "transactions".  If one were to assume
that one transaction => one write, then The Correct Thing would be
done by the operating system.  (I believe that UNIX just gathers all
the iov descriptors together into an MBUF chain, thus avoiding the
dreaded copy.)

If this were a disk-based application, you would want transactions
to occur atomically, and hence would use writev()s.  This way, if
the program were interrupted or the system crashed, you would have
the best chances of the operation completing.  (As opposed to taking
a signal between the first and second write.)  So "packets" are not
conceptually different from "records".

> My own suspicion is that there is no clear model, because in general I find
> that such is characteristic of Unix.  I was raised as a physicist and therefo!
> always carry the hope that the rule of parsimony will apply;  Learn a few
> universal rules, and derive all else from them.  I am almost prepared to

Unix is based on such a philosophy -- consistency is its watchword [kiss].
Perhaps you were weaned on a more "sophisticated" system, and hence have
certain expectations...

-Philip

-----------[000163][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 89 22:59:30 GMT
From:      pprindev@wellfleet.com (Philip Prindeville)
To:        comp.protocols.tcp-ip
Subject:   Re:  rpc protocols

> Could people with RPC experience comment on the relative merits of
> the various RPC "standards": Sun's RPC/XDR, ASN.1 (Used by NetWise),
> and Apollo's (used by DEC?).? THanks!

ASN.1 is also used in SNMP.

-Philip

-----------[000164][next][prev][last][first]----------------------------------------------------
Date:      16 Sep 89 23:25:18 GMT
From:      joshua@athertn.Atherton.COM (Flame Bait)
To:        comp.protocols.tcp-ip
Subject:   Re: rpc protocols

Dominick Samperi (samperi@marob.masa.com) writes:
>Could people with RPC experience comment on the relative merits of
>the various RPC "standards": Sun's RPC/XDR, ASN.1 (Used by NetWise),
>and Apollo's (used by DEC?).? THanks!

The RPC standards "game" is not as complicated as it sounds:
    Sun's RPC is the standard on UNIX machines.
    Netwise's RPC is the standard on IBM PC machines 
        (with some competition from Sun).

In terms of availablity, Sun's RPC and Apollo's RPC are available for most
UNIX, VMS, and IBM PC type platforms.  Netwise's RPC is available on VMS,
and IBM PC, and some UNIX platforms.  Call the vendors for details.

I know that this message will generate a lot of mail from various Apollo,
DEC, and/or IBM  people saying that "Sun's RPC is not standard" or "We're
just as standard as they are, etc."  This makes good marketing hype, but it
is not true.

Consider the following machines: DEC's DECstation 3100, VAXstation 3100 and
VAX 6XXX machines, IBM's RT machines, Sun's Sun-3 and Sun-4 machines, and
Apollo's 3XXX, 4XXX and 10000 machines.  All of these machines have Sun's
RPC running on them out of the box.  They might claim that Sun's RPC is not 
standard, but they all use it.  I believe that Sun's RPC system is also
used by HP machines; if fact, I can not think of any modern UNIX machine 
which does not have it, although there must be some. 

The Apollo RPC system is available for many of these machine, (and Netwise
for some of them) so you can buy them if you want, but that is very 
different from having the RPC system on the machine when you buy it.  

Joshua Levy
--------                Quote: "If you haven't ported your program, it's not
Addresses:                      a portable program.  No exceptions."  
joshua@atherton.com          
{decwrl|sun|hpda}!athertn!joshua    work:(408)734-9822    home:(415)968-3718

-----------[000165][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 89 01:37:45 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   RE: DOD ---> CMOT VERSUS SNMP

Rodney,  Your last message got me to feel guilty about my earlier reply.
Sometimes those of us who "know the answers" don't realize how those
who are asking the questions are essentially so far removed from all
the stupid insider knowledge that our answers seem very opaque.

I will try to answer your questions directly.

CMOT is an acronym for CMip Over Tcp.  (I lowercased stuff to make
the point.)  CMIP is the ISO protocol for network management.
CMOT is a design that allows the ISO CMIP applications to manage objects
on a TCP/IP network as well as on an ISO network.  (At least thats the goal
statement.)

I do not know of any official DoD policy stating that SNMP and/or CMOT 
is the preferred/required network management protocol.  The IAB (Internet
Activities Board), of which I am a member, has stated that either protocol
is acceptable as a network management protocol and that entities that
wish to be network manageable must implement at least one of those
protocols.  The history of this situation is a longish one, but essentially
SNMP was viewed as a stopgap measure (albeit an excellent one) for
network management and that CMOT was a long term measure that would
incorporate the ISO network entities that are in our future.  

The current situation in the marketplace is that there are dozens of SNMP
implementations out there.  To date, I know of no CMOT implementations
that are offered as commercial products.  A year ago there was a demonstration
of CMOT prototypes at a technical conference.  The distance from a
prototype to a product is sometimes large, eh?  

My conclusion from this is that of someone is telling you that CMOT
is mandatory for a certain equipment buy, then you are probably being
lied to.  If you are not being lied to, then whoever set the requirement
is not in tune with product avaiability and the spec should be redone.
(I'm assuming this is for a product that someone wants to install this year
or next...)

Dan Lynch
Advanced Computing Environments
415-941-3399
-------

-----------[000166][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Sep 89 14:52:09 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        LYNCH@a.isi.edu, oconnor@sccgate.scc.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   RE: DOD ---> CMOT VERSUS SNMP
Just to add to the confusion, I should note that I am beginning to
hear increasing rumblings that some vendors might wish to suggest
moving directly to full CMIP over TCP, rather than using the 
constrained CMOT.

While I don't have anything more substantial than citing 'rumor', in
terms of hearing about vendor plans, the technical distinction is
significant:

CMOT has two differences from CMIP.  The first is that it operates over
TCP, rather than OSI transport.  This turns out to be relatively
uninteresting, from the standpoint of management protocol discussions
and it is NOT the change that I am hearing rumored.

Much more importantly, CMOT specified a subset of the ASN.1 data types
and, I believe, a subset of the management protocol operations from
'pure' CMIP (draft international standard or slightly before).  Moving
to "full" CMIP, even over TCP, therefore involves some amount of
enhancement to the application protocol.

The original subsetting was done out of the usual desire to streamline
the initial implementation effort, for the demo that was schedules and
accomplished at last year's Interop.

Privately (i.e., not burdening the tcp-ip list with the traffic) I would
be interested in hearing about vendor feelings on this topic.

Dave Crocker
Digital Equipment Corp.
-----------[000167][next][prev][last][first]----------------------------------------------------
Date:      Sun, 17 Sep 89 17:22:27 EDT
From:      Philip Prindeville <pprindev@wellfleet.com>
To:        oconnor@sccgate.scc.com
Cc:        tcp-ip@nic.ddn.mil
Subject:   RE: DOD ---> CMOT VERSUS SNMP
> 	On the one hand, your last message stated that, "To date, I know of no
> CMOT implementations that are offered as commercial products."
> 	On the other hand, the INTEROP 89 brochure states that, "This year,
> the vendors who have developed CMOT-compliant software for their systems will
> be showing products which implement the CMOT network management architecture.
> Attendees will be able to see current packages which conform to this
> specification."
> 	Is the apparent dichotomy caused by time?  That is, does your message
> reflect the fact that despite INTEROP 89 plans, there are no CMOT products to
> show? 

There is no real conflict here -- Dan has two different hats.  The first was
made while wearing the Internet Engineer hat, and the second while wearing
(wearying?) a Salesman hat.

-Philip
-----------[000168][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 89 16:17:59 GMT
From:      oconnor@SCCGATE.SCC.COM (Mike O'Connor)
To:        comp.protocols.tcp-ip
Subject:   RE: DOD ---> CMOT VERSUS SNMP

Dan,
	I could use a little clarification.
	On the one hand, your last message stated that, "To date, I know of no
CMOT implementations that are offered as commercial products."
	On the other hand, the INTEROP 89 brochure states that, "This year,
the vendors who have developed CMOT-compliant software for their systems will
be showing products which implement the CMOT network management architecture.
Attendees will be able to see current packages which conform to this
specification."
	Is the apparent dichotomy caused by time?  That is, does your message
reflect the fact that despite INTEROP 89 plans, there are no CMOT products to
show? 

			Mike

-----------[000169][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 89 16:41:40 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   RE: DOD ---> CMOT VERSUS SNMP


Mike,  your conclusions are completely accurate.  6 months ago there
were solid plans for a CMOT demo of realproducts at INTEROP 89.  It
fell through because not enough vendors were able to commit to
making the deadline.  As far as i know they are still working on
making products, but they aren't ready yet.  I could be suprised by
one or two vendors showing up with actual products in the next
few weeks, but that would not be enough to bother putting
on an actual demo.  It takes a heck of a lot of coordination (read 
that as WORK) to put on a public demo of products from many sources.
We spend about 6 months each year working with the dozens of vendors
who are willing to prove to their potential customers that thier
products actually do work well together. The TCP/IP related demos
have been easier to pull together because the products are more
mature.  The OSI related demos have been tougher for the simple
reason that the products are less mature and therefore the vendors
are not as sure they can meet the deadlines.  This year we are having
two OSI related demos and the amouht of effort that has gone into
them is not small.  But, the results will be very impressive.
(With only two weeks to go, it is easy to predict what is already
known...  Paul Baran (the father of packet switching) said once
that "predicting is hard; predicting the future is even harder".)

Dan
-------

-----------[000170][next][prev][last][first]----------------------------------------------------
Date:      17 Sep 89 21:52:09 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   RE: DOD ---> CMOT VERSUS SNMP

Just to add to the confusion, I should note that I am beginning to
hear increasing rumblings that some vendors might wish to suggest
moving directly to full CMIP over TCP, rather than using the 
constrained CMOT.

While I don't have anything more substantial than citing 'rumor', in
terms of hearing about vendor plans, the technical distinction is
significant:

CMOT has two differences from CMIP.  The first is that it operates over
TCP, rather than OSI transport.  This turns out to be relatively
uninteresting, from the standpoint of management protocol discussions
and it is NOT the change that I am hearing rumored.

Much more importantly, CMOT specified a subset of the ASN.1 data types
and, I believe, a subset of the management protocol operations from
'pure' CMIP (draft international standard or slightly before).  Moving
to "full" CMIP, even over TCP, therefore involves some amount of
enhancement to the application protocol.

The original subsetting was done out of the usual desire to streamline
the initial implementation effort, for the demo that was schedules and
accomplished at last year's Interop.

Privately (i.e., not burdening the tcp-ip list with the traffic) I would
be interested in hearing about vendor feelings on this topic.

Dave Crocker
Digital Equipment Corp.

-----------[000171][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 89 09:50:13 GMT
From:      af%sei.ucl.ac.be@CUNYVM.CUNY.EDU ("Alain FONTAINE ", Postmaster - NAD)
To:        comp.protocols.tcp-ip
Subject:   X.400 on TCP

It seems that one  of the first practical results of  the OSI (1) effort
will be  the deployment of Message  Handling Systems based on  the X.400
CCITT recommendations (2). The MHS is defined at layer 7 ; in strict OSI
logic, it is  expected to use the services of  an OSI presentation layer
(which I was told it does *not*, even in a full OSI setup :_) ).

In  order to  use some  current network  infrastructure, operation  of a
X.400 MHS  on top of  TCP (which,  when applying the  OSI RM to  the DDN
suite (3), generally  ends up at layer  4, but who needs layers  5 and 6
when  one has  TCP :-)  )  will probably  be commonplace  in the  (near)
future.

The question : is there any work going on to define a standard way to do
this, in order to allow implementations of X.400 conforming to the CCITT
recommendations,  operating on  TCP  implementations  conforming to  the
relevant RFC's, to interoprate ? In one word, the reverse of RFC 1090.

Thank you in advance for any relevant comments. /AF

(1) please,  no wasting of  network ressources and readers  time arguing
about OSI vs ISO, or about the distinction between the RM and the actual
protocols, etc.
(2) please etc etc about the OSIness  of the CCITT, or the fact that one
should perhaps write X.4xx, etc.
(3) please ....... about the correctness of doing so.

Alain FONTAINE                       +--------------------------------+
Universite Catholique de Louvain     | If your mail software barks at |
Service d'Etudes Informatiques       | my address, you may try :      |
Batiment Pythagore                   |                                |
Place des Sciences, 4                |     FNTA80@BUCLLN11.BITNET     |
B-1348 Louvain-la-Neuve, BELGIUM     +--------------------------------+
phone +32 (10) 47-2625

-----------[000172][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 89 14:39:50 GMT
From:      rhc@HPLB.HPL.HP.COM (Robert Cole)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote Printer Access protocol?


You may be interested in some recent work from ECMA called: "Document
Printing Application". It will shortly be available as an ECMA
Standard, it is being submitted to ISO (JTC1/SC18) for consideration.
The latest version I have is an ECMA document numbered
ECMA/TC32-TG5/89/12.

I understand that the people doing the printing service for Athena
took this ECMA work into account.

Robert

-----------[000173][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 89 16:22:39 GMT
From:      nagle@well.UUCP (John Nagle)
To:        comp.protocols.tcp-ip
Subject:   Re: Nagle algo. in Unix-TCP

In article <8909162241.AA03169@tien.Wellfleet.Com> pprindev@wellfleet.com (Philip Prindeville) writes:
>You could also use writev() for doing scatter/gather writes.
>...
>If this were a disk-based application, you would want transactions
>to occur atomically, and hence would use writev()s.  This way, if
>the program were interrupted or the system crashed, you would have
>the best chances of the operation completing.  (As opposed to taking
>a signal between the first and second write.)  So "packets" are not
>conceptually different from "records".

      First, bear in mind that TCP really is a stream protocol.  You're
guaranteed that the bytes you write get to the other end in the same
order, but you are definitely not guaranteed that a unit of data
written with one write shows up as a single unit at the receive end.
If you need atomic transactions, a suitable protocol must be constructed
for that purpose, either on top of TCP or in some other way, such as
on top of UDP.  Sun's NFS, for example, is implemented on top of UDP.

      Second, given that we were discussing writes of small amounts of
data, copying cost isn't a big issue.  So "writev" isn't particularly
useful.

      I'd still recommend going through the standard I/O package and
doing "flush" operations at the appropriate time as the most effective
way of dealing with the problems described here.  Attempts to "increase
efficiency" by bypassing the standard I/O package generally make things
worse, rather than better, unless very large blocks are involved.

					John Nagle

-----------[000174][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 89 16:50:15 GMT
From:      mrose@CHEETAH.NYSER.NET (Marshall Rose)
To:        comp.protocols.tcp-ip
Subject:   Re: X.400 on TCP

RFC 1006 (ISO Transport Service on top of the TCP) published in May,
1987, describes a technique that can be used to host any OSI which
ultimately uses OSI transport on top of TCP/IP-based internets.

The advantage of this particular approach is two-fold: first, rfc1006
provides an emulation of the OSI transport service, as such the OSI
application is completely unaware that it is running in an TCP/IP-based
environment.  From the practical perspective, this means no change in
your code.  Considering that application code is easily two orders of
magnitude more complex, harder to debug, etc., than the lower layers,
this is a win.

Second, because the underlying paradigm is that of the OSI transport
service, you can build a "transport service bridge" between networks
with different transport services (e.g., TCP/IP, TP0/X.25, and
TP4/CLNP).  This bridge effectively shuffles packets between the
different networks allowing me, e.g., to have my TCP/IP-only host
exchange an X.400 message with an X.25-only host, providing that
somewhere there is a dual-homed host running both TCP and X.25 that both
hosts can reach.  Of course such a bridge theoretically introduces some
performance and reliability considerations, but in practice, this hasn't
been noticable.

A couple of implementations of rfc1006 have been running for a few years
now.  The original one (mine) has been running in the Internet since
March of 1987.  Right now, there are several sites running FTAM, VT,
MHS, and OSI Directory, in the Internet right now.  Of these four, the
Directory is the most notable (MHS is still in beta and not widely
distributed), as  NYSERNet has been sponsoring a white pages pilot for the
last couple of months which uses OSI Directory on top of TCP/IP.

Summary: problem solved.

/mtr

-----------[000175][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 89 17:00:10 GMT
From:      AFDDN.TCP-IP@GUNTER-ADAM.AF.MIL
To:        comp.protocols.tcp-ip
Subject:   plea for help II.

Thanx to all that responded to my first plea!!
Most responses reaffirmed things I "thought" I knew and some had a few
'kernels' of good info.  Now for the next few questions.

Does anyone know where I can get "named" and "bind" for ultrix 2.2??
  Between the AT&T, the Sun and the uVAX, I need to establish one as a name
server for a particular domain.  I believe the WIN 3B package and the sun 
already have everything, but the uVAX doesn't.

We happen to be running with two (that I know of) class C net numbers with
multiple thinnet and ether cable segments all bridged to one of several
channels on a dual broadband.  The channels are also brdiged together and
we have one gateway to milnet.  If my "systems" are on net A, I presume I
need a route entry for net B.  How do I get a host on net A to ARP for something
on net B.  

The comments I received on route and routed were interesting.  I understand it
as follows.  There is a set of routes mainted in the kernel that is established
by using "route add" commands.  There is also a set of routes in the 
/etc/gateways file.  If a route is not in the kernel set, the gateways file is
checked (yes or no)??  The kernel tables and the gateways file can be updated
by routed if its running.  Should I run routed if I'm connected to a single
net and have one static route to the rest of the world??

Next on my list is:  getting X-windows up and getting one of the machines up
  with the snmp devel kit?

As usual any hints will be appreciated (especially if I said something
obviously wrong).  
I'm also in the market for a PD mail package, something like the MM I'm
familiar with, that I can port to one or more of my machines.  

Darrle B. (ankle deep and still wading forward)
-------

-----------[000176][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 89 17:29:58 GMT
From:      drake@ibmarc.uucp (Sam Drake)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Re: TCP/IP over SNA

This isn't a commercial, but ...

IBM's VM and MVS TCP/IP products can transport TCP/IP over SNA networks,
and there's a PRPQ available from IBM to allow the RT to do the same.

Sam Drake / IBM Almaden Research Center 

-----------[000177][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 89 18:20:05 GMT
From:      hughes@silver.bacs.indiana.edu (larry hughes)
To:        comp.protocols.tcp-ip
Subject:   Printing in a Heterogenous Environment

I recently posted an article that summarized comments from
people on TCP/IP-based printing solutions in a heterogenous
environment.

In that summary, I mentioned a Postscript document that
describes Palladium, Project Athena's sophisticated 
network printing system.

My mailer has had some problems replying to some of the
people who requested how to access the Postscript
documents (actally, there's 2).  Interested parties
may anonymously ftp the following files from
cica.cica.indiana.edu (129.79.22.22):

  /pub/athena.ps        (11 pages)
  /pub/athena.design.ps (120 pages)

These are offered with compliments to MIT and the authors 
of the papers.

 //=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=\\
|| Larry J. Hughes, Senior Programmer ||  hughes@silver.bacs.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: See quote above.     ||
 \\=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=//

-----------[000178][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 89 18:40:14 GMT
From:      robert@trwind.ind.TRW.COM (Robert W. Snyder)
To:        comp.protocols.tcp-ip
Subject:   Re:  DoD --> CMOT and SNMP

Dan,
	How does your response relate to the traffic I sent?  I just
sent some traffic commenting on whether the DoD is requiring CMOT and
SNMP in future TCP/IP implemenations delivered to the government.

Robert Snyder       Disclaimer  --  nobody claims dis, but me
TRW Information Networks Division 23800 Hawthorne Blvd, Torrance CA 90505
USENET: trwind!robert
INTERNET: robert@trwind.TRW.COM                   Phone 213-373-9161

-----------[000179][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 89 21:09:00 GMT
From:      mishkin@apollo.HP.COM (Nathaniel Mishkin)
To:        comp.protocols.tcp-ip
Subject:   Re: rpc protocols

In article <12714@joshua.athertn.Atherton.COM> joshua@atherton.com (Flame Bait) writes:
>The RPC standards "game" is not as complicated as it sounds:
>    Sun's RPC is the standard on UNIX machines.
>    Netwise's RPC is the standard on IBM PC machines 
>        (with some competition from Sun).
>...
>I know that this message will generate a lot of mail from various Apollo,
>DEC, and/or IBM  people saying that "Sun's RPC is not standard" or "We're
>just as standard as they are, etc."  This makes good marketing hype, but it
>is not true.

I wouldn't want to disappoint anyone by not responding to this.  Joshua,
of course, makes some valid points, but on the other hand, Sun RPC promotion
is not free from marketing hype either.  I can't forget the time (when
Sun announced it's ONC packaging of NFS and Sun RPC) Apollo Computer's
name appeared in a glossy on a list of vendors "supporting" ONC.  That was
because we licensed the NFS trademark (I'm sure that's not the right legal
lingo by the way) for the Apollo NFS product (which, by the way, doesn't
use Sun's NFS source code -- only Sun RPC proper).  Many systems
have Sun RPC on them because they support NFS and Sun RPC comes along
for the ride.  Clearly, regardless of why it's there, it's there and that
has to be considered.  But so is "vi".  That doesn't necessarily make
it either (a) what I use, (b) useful, or (c) standard.  And just like
the presence "vi" doesn't preclude my using "gnuemacs", neither does
the presence of ONC preclude the use of NCS.

BTW, I have no particular reason to believe that Netwise RPC is the
"standard" in the MS/DOS world.  I doubt that any RPC has enough
penetration there to be deserving of the term "standard".

Anyway, if anyone wants to know more about NCS, they can contact me
(mishkin@apollo.com)  I'll spare you all any more advertising here.
-- 
                    -- Nat Mishkin
                       Hewlett Packard Company / Apollo Systems Division
                       mishkin@apollo.com

-----------[000180][next][prev][last][first]----------------------------------------------------
Date:      18 Sep 89 22:15:13 GMT
From:      jk@capone.UUCP (John Knight)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and OSI over FDDI


Hi Netlanders:
         
My company is developing an FDDI controller and is interested in 
running several different protocol stacks simultaneously over the 
controller.  At a minimum, we'd like to run both TCP/IP and OSI.  
With our current implementation of Ethernet, it is possible to 
route the packets to the appropriate protocol stack (ie. TCP/IP or 
OSI) via the type/length field in the Ethernet frame header.
         
We would like to do the same type of thing with FDDI frames.  
Unfortunately, the X3T9.5 MAC soon-to-be standard does not tell 
how one might route packets to various different protocol stacks.
         
Does anyone know if there is a document that specifies how to 
route an FDDI frame to OSI or TCP/IP protocol stacks?  Even within 
TCP/IP there is a question on how to route ARP and RARP traffic.  
The main burning question is as follows: How can/does the FDDI 
software distinguish between traffic intended for OSI, IP, RARP, 
or ARP?
         
In advance, thanks for your help.
John Knight

-----------[000181][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 89 01:53:14 GMT
From:      wingo@ncrcae.Columbia.NCR.COM (Dave Wingo)
To:        comp.protocols.tcp-ip
Subject:   tcp/ip ported to versados


I am looking for a TCP/IP implementation which works on a Versados
based system. Does anyone know of a company which provides such a
product?

Any help you can provide me will be greatly appreciated!!!

Thanks in advance David Wingo

-----------[000182][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 89 05:01:04 GMT
From:      LYNCH@A.ISI.EDU (Dan Lynch)
To:        comp.protocols.tcp-ip
Subject:   Re:  DoD --> CMOT and SNMP

Robert, excuse me, but my resposne was dead on with respect to your inquiry.
I said that to my knowledge DoD had not made a blanket requirement with
regard to network management protocols.  The IAB (which is a technical 
group, not a purchasing authority) has passed on the technical merits of
the two approaches.  The SNMP approach has a widespread implementation
base as of this date in history.  The CMOT approach does not.  A good
number of CMOT implementations are in progress, with some of them likely
to be shown publically in the next month.  But, by no means are
their actual product announcements pending.  Thus, I would infer that
anyone telling a potential buyer that he should buy from vendor X
because vendor X has CMOT and CMOT is the "LAW" is speaking an untruth;
i.e., a damn lie.  If you have information to the contrary I would
appreciate hearing it.

Dan
-------

-----------[000183][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 89 12:24:45 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re:  DoD --> CMOT and SNMP

The answer to your question will be in the amendments to the Government Open
System Interconnection Profile (GOSIP) which have been or will be published
in the Federal Register.  The NIC will probably have electronic copies of any
amendments that have been published under PROTOCOLS: along with the original
GOSIP and FIPS documents.

If the question is related to a DoD procurement, you should check directives
issued by the Office of the Secretary of Defense (OSD) which will define any
deviations from the GOSIP requirements. 

Based on my aged copy of the GOSIP document, neither SNMP nor CMOT is required.
Neither is likely to be required based on directions established in the GOSIP
document; however, it would be reasonable to expect an agency to specify CMOT
in specific procurements for interoperability with existing systems/networks.

Merton

-----------[000184][next][prev][last][first]----------------------------------------------------
Date:      Tue, 19 Sep 89 16:55:50 EDT
From:      Michael Laufer <mlaufer@cct.bbn.com>
To:        tcp-ip@nic.ddn.mil
Cc:        mlaufer@cct.bbn.com
Subject:   PC X.25 boards?
Does anyone have information on PC/AT X.25 boards?  We are looking for a board
that is DDN certified, with all or at least parts of the TCP protocol suite
(minimum of SMTP).  In addition we would like raw TCP.

I am aware of the boards from Scope Inc. and from Frontier Technology.  Scope
is discontinuing their X.25 gateway board product line so they are not an
option.  Is there another source other than Frontier?

Please reply directly to myself.  If there is general interest I will summarize
for the net.  Thanks

Michael Laufer      BBN Communications Corporation
internet:   mlaufer@bbn.com
phone:      (301) 290-5000
USMAIL:     9810 Patuxent Woods Drive, Columbia, MD 21046
-----------[000185][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 89 13:01:11 GMT
From:      verber@pacific.mps.ohio-state.edu (Mark A. Verber)
To:        comp.protocols.tcp-ip
Subject:   Re: rpc protocols

In article <5177@merlin.usc.edu> posted to comp.sys.ibm.pc was a 
a Sun press release about a project between themselves, Netwise and Novell
to create a common RPC.  [FYI: Novell uses Netwise RPC in their products.]
The bottom line is that Netwise will do it's next RPC release on top of
an enhanced version of Sun's RPC and XDR.  This new release of Netwise RPC
will run on top of the AT&T TLI.

According the the press release this technology was endorsed by
Ashton-Tate, AST Research, Automated Design, Banyan, CMC, DAZIX,
Informix, Interactive Systems, Lotus Development, Oracle, Microrim,
Relational Technologies, Sybase, 3Com and Unify. 

BTW: Novell does seem to be dominant in the PC marketplace.  The press
release from Sun said that Novell has more than four million PC nodes.
I also note that Banyan (one of Novell's prime competitors in the PC
server market seems to also support this RPC). 
-- 
Mark A. Verber
System Programmer, Physics Department, Ohio State University
verber@pacific.mps.ohio-state.edu
(614) 292-8002

-----------[000186][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 89 14:53:52 GMT
From:      pete@NCSC.NAVY.MIL (Fernandez)
To:        comp.protocols.tcp-ip
Subject:   Mailing List


  To whom it may concern:

   Please add me to the tcp-ip sig mailing list.  I used to be on it,
   but when we changed out net configuration, it went away.  We used
   to have an 1822 interface direct to the Eglin AFB IMP; we changed 
   to a Cisco gateway (with an 1822 interface) and went from ncsc.arpa
   to ncsc.navy.mil.  Thanx in advance.

   Pete Fernandez
   Naval Coastal Systems Center
   Senior IRM Official/Code 02

   pete@ncsc.navy.mil
   (904) 234-4120

-----------[000187][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 89 20:56:00 EDT
From:      "13513::DBURKE" <dburke%13513.decnet@nusc-npt.navy.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   Login.exe source for VMS 4.7 needed
Date sent:  19-SEP-1989 20:59:55 

Hi,

        I'm looking for an example Login.exe program (in either C or Pascal)
to model our sylogin after.  Please mail direct to me, as this was discussed at
length in April/May.

Thanks,
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)      ||         //       ||_____||
================================================================================

-----------[000188][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 89 18:40:42 GMT
From:      mckee@MITRE.MITRE.ORG (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote Printer Access protocol?

Ilham - One of the conclusions of the overview paper on The Athena
Palladium Print System is that, "The incorporation of centralized
management into the system will allow for easier and more effective
management of the print services ...."

"Centralized" things are worrisome, particularly in a distributed
environment.  Do the centralized management procedures run in a single
machine; are they essential to the AP Print System; what recovery
actions do you have planned when a failure occurs?  Regards - Craig

-----------[000189][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 89 20:55:50 GMT
From:      mlaufer@CCT.BBN.COM (Michael Laufer)
To:        comp.protocols.tcp-ip
Subject:   PC X.25 boards?

Does anyone have information on PC/AT X.25 boards?  We are looking for a board
that is DDN certified, with all or at least parts of the TCP protocol suite
(minimum of SMTP).  In addition we would like raw TCP.

I am aware of the boards from Scope Inc. and from Frontier Technology.  Scope
is discontinuing their X.25 gateway board product line so they are not an
option.  Is there another source other than Frontier?

Please reply directly to myself.  If there is general interest I will summarize
for the net.  Thanks

Michael Laufer      BBN Communications Corporation
internet:   mlaufer@bbn.com
phone:      (301) 290-5000
USMAIL:     9810 Patuxent Woods Drive, Columbia, MD 21046

-----------[000190][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 89 21:57:06 GMT
From:      matthews@cbnewsm.ATT.COM (john.matthews)
To:        comp.protocols.tcp-ip
Subject:   SUNs swapping with NFS


Can anyone tell me how I can identify NFS swap packets using etherfind?
I used to be able to do an "etherfind -v -t -proto nd" to see if there
were any clients that were swapping across our primary backbone segment
of the ethernet, but now that we're running 4.0, I can't.  I think I can
come up with the correct syntax if someone can tell me if there is a
unique byte pattern that is common to every NFS swap packet.
				Thanks in advance,
					John Matthews
					Matthews@Research.ATT.COM

-----------[000191][next][prev][last][first]----------------------------------------------------
Date:      19 Sep 89 22:19:43 GMT
From:      joshua@athertn.Atherton.COM (Flame Bait)
To:        comp.protocols.tcp-ip
Subject:   Reliable email protocols

A General Question:

    Given a choice between a modified TCP, RDP, or VMTP, for use as a
reliable packet oriented protocol, which would you use, and why?  Assume
that TCP has been modified to make it more packet oriented by concatenating
the open stream/send data/close stream messages into one message.  Also 
assume that availability is not a consideration at all (ie. the fact that
everyone already has TCP is not important).

The Real Question:

    What I'm really interested in is using email as a transport layer,
similar to the way RPC or TCP are used today.  I think that there are
many applications where speed is not very important, but being able to
communicate with diverse machines "far away" is.  The specific application
I'm thinking of is a distributed document system, where several authors 
are collaborating on one document, with each author working on a different
part.  Another interesting system would be one to automatically distribute
test results to various authors collaborating on an experiment.

    What I want to do is implement a reliable packet oriented communications
layer on top of email.  Since email has many of the same characteristics as
IP packets, I'm hoping that I will be able to "port" an IP based reliable
protocol into an email based reliable protocol.  

    My question really is, "Are there any protocols which have already been
designed and tested which I can use as a starting point in designing a 
reliable communications protocol based on email messages?"

Any ideas?  Or anything that I've missed?

Joshua Levy
--------                Quote: "The Street finds its own uses for technology."
Addresses:                                          -- William Gibson 
joshua@atherton.com          
{decwrl|sun|hpda}!athertn!joshua    work:(408)734-9822    home:(415)968-3718

-----------[000192][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 00:02:28 GMT
From:      darryl@batserver.cs.uq.oz (Darryl Godfrey)
To:        comp.protocols.tcp-ip
Subject:   Re: LAN adapter for IBM 3081

miw@bunyip.cc.uq.OZ (Mark Williams) writes:


>	We decided that the time had come to get a real, supported,
>IBM 8332 LAN channel station. After all, we should have a supported
>ethernet adapter. We were so serious about it that we got a quotation.
>The quotation was....
 
>		SEVENTY-SEVEN THOUSAND DOLLARS

	Maybe token ring is cheaper :-) This is one of the problems with
	dealing with companies who market antiques. I can't believe that
	they actually use an AT as a channel adaptor. Thinking about it,
	token ring plus a gateway with an ethernet controller would
	probably be cheaper. Apollo do it quite well.


-darryl
(IBM - just say *no*)

-----------[000193][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 00:56:00 GMT
From:      dburke%13513.decnet@NUSC-NPT.NAVY.MIL ("13513::DBURKE")
To:        comp.protocols.tcp-ip
Subject:   Login.exe source for VMS 4.7 needed

Date sent:  19-SEP-1989 20:59:55 

Hi,

        I'm looking for an example Login.exe program (in either C or Pascal)
to model our sylogin after.  Please mail direct to me, as this was discussed at
length in April/May.

Thanks,
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)      ||         //       ||_____||
================================================================================

-----------[000194][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Sep 89 09:30:00 CDT
From:      "David W. Dearth, Director" <C0001@UMRVMB.UMR.EDU>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: radio and VSAT networks
I don't have any info, but I would be interested in any information that
you receive.
Acknowledge-To: <C0001@UMRVMB>
-----------[000195][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 13:57:00 CST
From:      "Randall Gamby" <gamby@mdc.com>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   RE: CMOT vs. SNMP
>Dan,
>	How does your response relate to the traffic I sent?  I just
>sent some traffic commenting on whether the DoD is requiring CMOT and
>SNMP in future TCP/IP implemenations delivered to the government.
>
>Robert Snyder       Disclaimer  --  nobody claims dis, but me

Hi everybody,

I just got back from NIST and answered the above for Robert (I normally
receive DDN messages and hadn't quite mastered the art of general mailings).
He at least felt that my answer might clear up some questions so I'm putting
my life on the line and sending it out.  I apologize up front for the length
of this message but I wanted to make sure the direct sections were made avail-
able and not my own personal subjective point of view.  Certain editorials
have been added to clarify status.

I have in my possession the following document from the Defense Communications
Agency:

       "The Department of Defense Open Systems
        Interconnection (OSI) Implementation Strategy"
        Dated: May 1988 (An updated one is supposed to be in work)
        Sponsor: DCA/DCEC (Code R130)
                 Interoperability and Standards
                 Derey Engineering Building
                 1860 Wiehle Ave.
                 Reston, VA  22090

On Network Mangement it says:
"Quote"
2.4.6 Network Management

   OSI Network Mangement is in the early stages of development and completely
conformant stable products are not expected until well into 1991.  The network
mangement standard still has significant issues to be resolved before the 
specific management services and protocols can be completely defined.

   There are three interim network management efforts expected to be available
before OSI Network Management products:

   o Manufacturing Automation Protocol (MAP) interim management standard
     (General Motors Manufacturing Automation Protocol, 1987)
   o Simple Network Mangement Protocol (SNMP) for the DoD in the near-term
     (IDEA011)(Case, 1988)
   o Common Management Information System/Common Management Information Protocol
     (CMIS/CMIP) for the DoD in the mid to long-term (IDEA012)(Ben-Artiz, 1988);
     (IDEA013)(LeBarre, 1988).

The Internet Design, Engineering, and Analysis Notes (IDEA) documents (note 1:
IDEAs are IETF working documents circulated for comment.  Because IDEA documents
carry no official status and are subject to change, they should NOT be refer-
enced as standards) are in the draft stage of development and have not yet been
adopted by the DoD, however, the Internet Activities Board (IAB) has recommended
that the Internet community adopt and adapt --> SNMP <-- for use as the basis
of common network management in the short term, and that a network management
system based on the ISO CMIS/CMIP be developed, deployed and tested for the
longer term. (Cerf, 1988)  All of these, as well as other existing protocols,
are being considered by the NIST(NBS) Network Management SIG (Personal Note:
the SIG is part of the Implementors Workshop that creates North American
Implementors Agreements that are talked about later and are the base documents
for such specs. as GOSIP, MAP/TOP, COS, etc.) which is working on the creation 
of a recommendation for an OSI network management standard.  It is the goal of 
this group to develop an initial set of network management Implementors Agree-
ments (IA) by December 1988. (Personal note: At last check these were in final 
rev. and ready for vote.)  Products based on these IAs can be expected approx-
imately one year after IA acceptance.  Although any of the above interim prot-
ocols can be implemented now, there is no guarantee that any of them would 
conform to the IAs when they are eventually issued.  Therefore, until the IAs 
are available, network management will probably be handled, as it generally is 
today, with proprietary protocols or other non-open system techniques.


Hopefully so much for network management, but some will argue that CMOT is
based on CMIS/CMIP with a TCP/IP transport.  The DoD document also addresses
the question of OSI upper layer applications on DoD transports.  I quote
another section (Sorry for the length but I want to make sure everyone has
the full and direct responses!):

3.1.1 DoD/OSI Protocol Profiles

   The protocol profile specified in GOSIP is a "pure" OSI stack; that is, it
is a set of protocols drawn entirely from OSI standards for each protocol layer.
The current operational DoD protocol profile is also a pure stack.  DoD has
tasked DCA to provide support for interoperability between these two pure stack
profiles only.

   Profile implementations have been built with a mixture of DoD and OSI pro-
files at each layer.  These are sometimes referred to as "mixed protocol stack"
or "mixed protocol profile" implementations.  Such implementations take advant-
age of the similarities between the services provided by some OSI protocols and
those offered by analogous protocols in the DoD architecture.  The two main
possibilites for mixed protocol profiles are DoD applications over OSI lower
layers and OSI applications and upper layers over DoD lower layers. (Personal
note: this is CMOT or, as I saw in another inquire, X.400 on TCP/IP.)  A mixed-
protocol approach, using the second possibility, may have the advantage of 
providing a seemingly quick migration to the use of OSI application services in 
the current DoD internetworking environment.  However, it has the disadvantage 
of increased complexity of interoperation and increased costs.

   Each additional protocol profile in the transition process requires methods
for it to interoperate with every other protocol profile.  The introduction
of one addition protocol stack would require the development of two additional
interoperation procedures-one between the DoD stack and the mixed stack, and one
between the OSI stack and the mixed stack.  With only two different protocol
stacks (the current DoD and the targeted OSI), only one interoperation procedure
needs to be provided.  Additionally, provision and support of a mixed stack 
environment requires considerable development effort, and vendor focus is on the
provision of pure stack protocol products.

-->Therefore, to minimize complexity and to realize the economic benefit of 
vendor supplied and supported products, only "pure" OSI protocol profiles are
considered in the DoD's implementation strategy.<-- Mixed stack implementations
may be used only as interim transitional mechanisms to facilitate a system's
migration to a pure OSI profile.


So I won't say whether to use CMOT or SNMP but if I were spec'ing out a DoD
system, I think I personally would stay with a pure DoD SNMP or use a CMIP
on OSI transport if it's an OSI product.  I know this was long but I've got
twice as much mail on the subject than what's here.

Thanks for the listen and I hope this was worth the effort to put a little
light on the subject.

Randall Gamby
McDonnell Douglas Aircraft Co., St. Louis
(314)895-5296

-----------[000196][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 08:57:03 GMT
From:      HANK@BARILVM.BITNET (Hank Nussbacher)
To:        comp.protocols.tcp-ip
Subject:   Interesting article: Tcp/Ip vs. OSI

Computerworld, Sept 11th, page 94 & 95: "Battle of the Titans: TCP/IP vs.
OSI", by Dave Crocker.

Hank

-----------[000197][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 12:53:09 GMT
From:      len@netsys.netsys.COM (Len Rose)
To:        comp.protocols.tcp-ip,comp.periphs,misc.wanted
Subject:   Bridge Communications


 Hi.. I need a current telephone number for Bridge Communications,
 they used to be in Cupertino,Ca.. I tried directory assistance of
 course, but there was no listing.. 

 Thanks for any possible assistance..

 Len

-----------[000198][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 13:42:44 GMT
From:      Dave_Katz@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   TCP/IP and OSI over FDDI

>Does anyone know if there is a document that specifies how to
>route an FDDI frame to OSI or TCP/IP protocol stacks?  Even within
>TCP/IP there is a question on how to route ARP and RARP traffic.
>The main burning question is as follows: How can/does the FDDI
>software distinguish between traffic intended for OSI, IP, RARP,
>or ARP?
 
For TCP/IP, RFC 1103 proposes a method of framing ARP and IP
over FDDI using 802.2 LLC and SNAP headers (in which the
classic "ethertype" field is carried).  This document is only
a draft, but the fundamentals points aren't likely to change.
 
For OSI, there's no official document as to how Network Layer
protocols will be carried, although it's essentially a foregone
conclusion that 802.2 LLC will be used, with an LSAP value
of "OSI Network Layer Protocol."
 
So, to answer the question directly, the algorithm is something
like:
  If FDDI LLC frame
    [assume 802.2 LLC in use]
    if LSAP = SNAP
       determine protocol type based on SNAP type
    else if LSAP = OSI NL
       determine protocol type based on first octet of NL packet
    else
       ???
 
It appears likely that the SNAP format will be used for all
protocols that run with Ethernet framing, not just IP and ARP.
 
Protocol identification for OSI is done at the network layer; the
first octet of the packet determines which of several protocols
(CLNP, ES-IS, X.25, etc.) is in use.  An ISO Technical Report,
"Protocol Identification at the Network Layer," (the TR # escapes
me) spells this out.

-----------[000199][next][prev][last][first]----------------------------------------------------
Date:      Wed, 20 Sep 89 10:57:03 O
From:      Hank Nussbacher <HANK%BARILVM.BITNET@CUNYVM.CUNY.EDU>
To:        tcp-ip@sri-nic.ARPA
Subject:   Interesting article: Tcp/Ip vs. OSI
Computerworld, Sept 11th, page 94 & 95: "Battle of the Titans: TCP/IP vs.
OSI", by Dave Crocker.

Hank
-----------[000200][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 14:30:00 GMT
From:      C0001@UMRVMB.UMR.EDU ("David W. Dearth, Director")
To:        comp.protocols.tcp-ip
Subject:   Re: radio and VSAT networks

I don't have any info, but I would be interested in any information that
you receive.
Acknowledge-To: <C0001@UMRVMB>

-----------[000201][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 14:32:08 GMT
From:      crucible@FERNWOOD.MPK.CA.US
To:        comp.protocols.tcp-ip
Subject:   THE INTERNET CRUCIBLE - Volume 1, Issue 2

THE CRUCIBLE                                                  INTERNET EDITION
September, 1989                                             Volume 1 : Issue 2

   In this issue:
	- Explanation of THE CRUCIBLE moderation policy
	- Corrigendum to THE CRUCIBLE Volume 1, Issue 1
	- Letters in response to THE CRUCIBLE Volume 1, Issue 1
	- The Changing Nature of Managing the Internet

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

   THE INTERNET CRUCIBLE is an eleemosynary publication of Geoff Goodfellow.

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

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

		  THE INTERNET CRUCIBLE MODERATION POLICY

	THE CRUCIBLE is a refereed periodical irregularly published on the
Internet.  All contributions and editorial comments to THE CRUCIBLE are
reviewed and published without attribution.

	Each contribution is refereed by a range of networking experts from
academia, research, and industry.  As with refereed professional journals,
the referees are responsible for ensuring that a contribution is credible.
Even though one or more of the referees may not agree with the position
taken by the authors of a contribution, the referees may still recommend
that the contribution be published.  If not, the referees make cogent
suggestions as to how the contribution might be improved. 

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

	In addition to providing a neutral forum in which to examine the
ideas, publication with refereeing but without attribution provides a means
for contributors to express ideas that may be controversial.  It is an
unfortunate but all too common situation that many organizations
(commercial or research) naturally avoid association with controversial
positions.  Even if an author prepares a contribution on personal time and
publishes it without affiliation, the author's employer, funding source,
(and parts of the community) will most likely view the contribution as
being associated with the author's organization.  Thus, many potentially
controversial contributions of merit are never submitted.

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

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

			   CRUCIBLE Corrigendum

	The contributors of THE CRUCIBLE Volume 1, Issue 1, "A Critical
Analysis of the Internet Management Situation: The Internet Lacks
Governance" incorrectly referred to Mr. Robert Braden, IAB Executive
Director as "Dr."  The contributors regret the error.

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

	   LETTERS IN RESPONSE TO THE CRUCIBLE VOLUME 1, ISSUE 1

Sir:

	Who was the author of this article?  The only name I noticed was
Goodfellow, but he is listed as moderator.  I have no objection to the
views.  Indeed they are sensible.  But I do have objections to anonymous
editorials.

Yours etc.,

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

Sir:

	Good job.  This showed up in my mailbox while I was trying to 
write something making many of the same points.  You outdid me.

Yours etc.,

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

Sir:

	Congratulations on a great article!  While I disagree with some
specific points you made, the vast majority of what you said is right on
target, and badly needed to be said.  (As a case in point, I've been unable
to reach SRI-NIC.ARPA (aka NIC.DDN.MIL) for a week now, and I can't even
get an email response from our beloved regional NSF net.)

Yours etc.,

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

Sir:

	Fascinating article.  Too bad the author did not have the guts to
sign his/her name.  My only nit-pick is to reply to this:
   > Meanwhile, the outside world goes on about developing economically viable
   > and efficient networking technology without the benefit of direct
   > participation on the part of the Internet.

	With "oh really?  What?"

Yours etc.,

[The contributors respond:

   At the beginning of the article we noted technologies such as PDNs, UUCP
   and CSNET dial-up networks.  While these lack the glamor of IP-style
   networking on the extended Internet, they nonetheless are economically
   viable.  One might argue that OSI is producing technology roughly
   comparable to the Internet suite, but there is very little technology
   transfer in this regard.  Considering that OSI is standardized in The
   Open, we find it difficult to blame the OSI proponents for this lack of
   cross-over.]

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

Sir:

	I dislike intensely receiving a controversial article by email when
I cannot tell either who wrote the article, or to whom it was distributed.

Yours etc.,

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

Sir:

	Good article.  Many valid points were raised.  I, like many others,
suffer from the problems pointed out in this article.  I see how things
could be better and am frustrated when it takes so long for things to
improve.  It will be interesting to see what kind of responses you receive.

Yours etc.,

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

Sir:

You stated:
   > While everyone in the market says they want OSI, anyone
   > planning on getting any work done today buys Internet technology.

	We're getting work done today using OSI technology, on Intel's
OpenNET network. It's got superior UNIX file-system semantics to either NFS
or RFS. We'd like to go TCP/IP, since it's got more *real* standards, but
we certainly don't plan to take a step backwards to do so.

	So, for us, the situation is the reverse...

Yours etc.,

[The contributors respond:

   In limited, pilot and laboratory settings, OSI may provide solutions today
   that Internet technology does not.  It has been our experience that this is
   the exception and not the rule.  The OSI file service is called FTAM, not
   OpenNet.  OpenNet, while based on the OSI transport service, is nonetheless
   a proprietary vendor solution as it has not been standardized in The Open.
   Presumably one could easily host OpenNet technology on top of TCP, and
   outside of the increase in performance, robustness, and throughput, you'd
   never notice the difference!  All humor aside, it is important to
   distinguish between OSI standards and things resting on top of OSI
   standards. ]

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

Sir:

	A friend forwarded Vol 1 No 1 of CRUCIBLE to me recently.  I was
feeling good about the text all through the preamble, saying to myself that
this sounded like a useful contribution to an area that could benefit from
"critical analysis" especially since you advertised that it was going to be
refereed.

	However, almost none of the body of this article has merit.  It is
a rehash of uninformed flaming. Neither the article nor any of the missing
refereed commentary shows any indication of knowledge of a great deal of
hard work that has been going on for the last three or four years to
design, promote and implement an improved national research and education
network based on the strengths of the Internet.  There is no reference to
at least a half dozen major studies of the requirements for deployment of
advanced technology in an upgraded research net.  Nor even one word about
two annual conferences on the need for a national net that were held in
Washington in 88 and 89 that have helped develop the NREN plan and the
necessary federal legislation to support it.

	I was particularly annoyed by the pernicious foolishness about
competitive alternatives to the Internet.  Is whoever is the author of this
piece seriously proposing that the nation should fund TWO advanced networks
on the theory that the costs will be lower overall after they compete with
each other?  Or do I have it wrong, and the worthy scholar of your piece
doesn't care whether we use world class networking in our allegedly world
class national research enterprise but just wants cheap reliable email?  If
so, we already have it in the form of BITNET which reaches millions of
individuals worldwide for pennies a message and is 100% supported by
member/user fees.

	I've spent almost all of my career in academia, some twenty-four
years at last count.  In that arena, if you have the courage of your
convictions, you put your name on them. I don't see any excuse for unsigned
articles in CRUCIBLE.  This isn't an AIDS hotline we are talking about.

	I'd like to see CRUCIBLE succeed and have a positive influence on
the shaping of public policy for the NREN that will be taking place over
the next couple of years.  But, candidly, you're off to a bad start.

Yours etc.,

[The contributors respond:

   It is important to appreciate that the thrust of the contribution had
   nothing whatsoever to do with the NREN.  It was neither a criticism of the
   NREN, and it was certainly not a covert appeal for funding an alternative
   to the NREN.  The contribution was about the Internet.  This is a network
   which is operational today, which many thousands of people depend on as a
   normal part of their work environment.

   While we applaud the hard work, studies, conferences, etc., that
   demonstrate the commitment to fund and implement the NREN, these are, quite
   bluntly, immaterial to the argument at hand.  There is a notable exception
   however: if the NREN is to be based on Internet technology, then we hope
   that the NREN management learns from the lessons of the existing Internet
   and is sensitive to economic issues in the technology it uses.  Recent
   history in numerous other industries demonstrates that, despite broad
   agendas and good intentions on the part of government, commercial
   forces are often vital to producing vibrant, useful services.
 
   The simple fact is that economic models work and others, such as the
   current Internet model, don't work.  For example, there have been massive
   innovations in dial-up modem technology in recent years.  This is solely
   because the users of dial-up modems, by and large, have to pay for
   the phone calls they make. If dial tone and connect time were free, 
   we'd likely still be using 1200bps today!  There is no correspondent 
   accountability in Internet technology, and half-attempts to provide this,
   such as policy-based routing, are fraught with potentially disastrous
   performance side-effects.

   Finally, was this contribution really "a rehash of uninformed flaming"?
   Can anyone ever recall seeing the Internet structure being taken to task 
   in a public forum?  We think not.  This is the first time anyone has ever
   bothered to fire a shot off the bow of the old boy's club that's been
   non-managing Internet technology for the last few years.]


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

Sir:

One minor quibble with an otherwise fine and level-headed document:

      This bug flies in the face of the Internet parable
      "be generous in what you accept and rigorous in what you send".
   
Perhaps you meant to say "rule of thumb", or "proverb"?

Yours etc.,

[The contributors respond:

   Quite right.  We stand corrected.]

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

Sir:

	All very well said and well put.  I've just come back from a week
on the West Coast trying to use the Internet for real work while I was
away, and separate problems at BARRNET and JVNC/NEARNET made things
literally unusable.  By the time I yelled long enough at different people,
things were fixed--by Friday, the end of the week.

	The balkanization of the Internet into regional nets has been like
the breakup of AT&T, only worse (because of their isolation from economic
pressures and because "service" doesn't matter.)

	Will there be a BOF on your topics here at INTEROP?

Yours etc.,

[The contributors respond:

   No BOF is planned, but it would be interesting to have an open forum for a
   face-to-face meeting between the IAB, NSF regional network directors and
   an Internet constituency.]

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

	       The Changing Nature of Managing the Internet:
			 A Paradox in Governance


				ABSTRACT

The development of Internet technology was well-served by a directed agenda
sponsored by the US Government.  However, today's development of Internet
technology is largely stagnant because the technology is providing useful
service for many of the research and development communities needs.
Although several developmental efforts are underway, seemingly not much
progress is being made.  The ill-defined distinction between Internet
research, engineering, and development has led to additional confusion.

The first issue of THE INTERNET CRUCIBLE dealt with Internet technical and
accountability failures.  This second issue is complementary in that it
examines the paradoxes and failures inherent in the current Internet
management structure.  A new structure for Internet management is proposed.


	    A Brief History of Internet Technical Management

	As a part of its charter in the 70's, DARPA (then known as ARPA)
was responsible for funding high-risk, high-potential payoff research.
DARPA's guiding rule was fairly simple: ideas were researched, proven, and
then deployed.  In order to advance DARPA's ambitious agenda in networking,
the government recruited far-sighted individuals with an interest in
networking, each with personal research agendas in networking and
communications.  The DARPA "program managers" then oversaw the technical
direction taken by the researchers which produced, among other things,
Internet technology.  Research efforts in areas of networking continue to
be funded and directed by program managers DARPA and NSF independent of the
existing Internet technology base.

	As Internet technology passed from idea, to research, to deployed
technology, there were two side-effects:

	1) Internet technology ceased to be high-risk research--it became
	   engineering; and,

	2) the networking agenda became less of a priority research 
	   item as it became developed, proven, operational technology.

	Several production internets now exist, providing useful service to
their respective communities.  Problems with Internet technology today are
largely second-order problems, ones which are easily solvable by
responsible engineering and modest evolutions in the technology.

	A cogent argument could be made that any networking "research"
being done these days must be substantively distanced from current
technology.  Using this perhaps controversial definition of "research",
topics such as OSI, Message Handling Systems and Directory Service
applications, while important to production networks in the short- and
medium-term, are "development" and not "research".

	This leads us to note that the nature of Internet technical
direction has changed: it is now one of managing engineering disciplines,
not one of managing research.  It is not clear that the management
structure used to guide the technical direction of Internet technology
reflects this change.  To be sure, there have been recent changes in the
management structure (i.e., the recent IAB reorganization and the creation
of the IRTF and IESG), but these changes appear to be superficial only--the
old thinking, the old procedures, and most importantly, the old
infrastructure, are all still in place.  The model, we argue, continues to
be based on the notion that Internet technology is still a research project.


	       The Current Internet Management Structure

	Arguably the top-level management entity is the newly re-organized
Internet Activities Board (IAB).  The IAB consists of the chairs of two
task forces (one responsible for engineering, the other for research),
liaisons to other organizations, and administrative personnel.  The IAB's
current charter consists of managing the RFC and Internet standards
process, managing the engineering and research task forces, performing
strategic planning for the Internet, and providing liaison to other
organizations.  The IAB is a "closed" organization--its meetings are not
open to the public, and neither agendas nor minutes are openly available.

	The Internet Engineering Task Force (IETF) of the IAB is chartered
to solve short-term engineering problems in Internet technology.  It is a
open, voluntary organization with over 20 working groups.  Unfortunately, the
IETF has not been particularly successful in producing short-term solutions
(e.g., it has taken the IETF well over a year to not yet produce RFCs for
either a Point-To-Point Serial Line IP or Network Management enhancements).
New to the IETF is the Internet Engineering Steering Group (IESG) which is
tasked to govern the IETF.  This too is a closed organization, serving at
the pleasure of the chair of the IETF.

	The Internet Research Task Force (IRTF) is chartered to promote
research in networking that will presumably lead to producing the
technology the IETF will need.  The IRTF also has a steering group, the
IRSG.  The IRTF consists of several "research groups" which, as of this
writing, roughly correspond to the various research task forces found on
the IAB prior to re-structuring.  The IRTF is a closed organization.

	It should be noted that although the recent IAB reorganization
changed some titles, the personnel and infrastructure are largely unchanged.
The same relatively small closed community continues to make decisions.


	   Paradoxes in the Current Internet Management Structure

Consider three possible scenarios:

Scenario 1: The IAB

	The IAB, by declaration, determines the direction of Internet
technology, primarily through the form of managing the Internet standards
process, and thus has a wide impact on uses and development of Internet
technology in government, academia and industry, along with significant
commercial impact.  However, the IAB is, as noted earlier, a closed
organization.  Further, there is no disclosure of interests among the 
IAB membership.

	For the sake of argument, suppose one or more members of the IAB
were employees of a commercial concern.  Further, suppose that these
commercial concerns were directly tied to Internet technology.  For
example, one of of these concerns might be a vendor of Internet technology,
or another might be a supplier to such vendors.  As such, the actions of
these IAB members, who are also commercial employees, must be under careful
scrutiny.

	Let us carry this hypothetical scenario a bit further: suppose the
IAB were considering elevating a new protocol to some official standing.
If parts of the vendor community (and in particular one of the commercial
concerns sponsoring an IAB member) stood to benefit competitively or
fiscally from such a decision, then this situation might well place the
interests of those IAB members at cross-purposes with the interests of the
Internet community as a whole, and the U.S. Government in particular.  At
the very least, the IAB membership and presumably the sponsors of that
membership, have access to "inside information" which has significant
commercial impact.

	To impress upon the reader that this is not a theoretical
observation, it must be emphasized that this scenario is drawn on fact--it 
is disturbingly parallel to an actual incident which recently occurred.  It 
is not, however, the purpose of this contribution to prejudge the motives of
the individuals involved.  Rather, we note that appearance of interests is 
at cross-purposes, regardless of the intent.

Scenario 2: The IESG

	The newly-formed IESG, by declaration, develops technology for use
in the Internet.  The same hypothetical argument can be used here: the
members of the IESG are each responsible for a particular area of Internet
technology, e.g., network management.  Again, if the person filling this
role is employed by a commercial concern, then interests may be at
cross-purposes.  In particular, since theoretically the IESG deals with
technology at a less mature stage, entire engineering approaches might be
unduly advanced or hindered depending on potential market advantage or threat.

	Fortunately, the IETF is an open organization, as such interests at
cross-purposes can be more readily identified.  However, since the IETF
takes its direction from the IESG, the engineering aspect of Internet
technology remains subject to being directed by IESG members who could be
at cross-purposes with the interests of the Internet community.

Scenario 3: The IRSG

	The IRSG, by declaration, advances research into Internet
technology.  For the sake of argument, suppose that the IRSG proposes that
particular areas of research be funded.  Since the IRSG is a closed by-
invitation-only organization, its membership is likely to appear to be
acting in a self-interested fashion, since they receive early information
about areas which might be funded, and are in a substantially advantaged
position to write proposals for that funding.  Although the IRSG might
appear to be acting as an advisory board, an outsider might make the
argument that the IRSG both directs the government in funding direction,
and then makes proposals to take advantage of the advice given.

	Consider the effort to produce a White Pages service for the
Internet (a service that, among other things, is used to obtain mailbox and
other information about users in the network).  In February of 1989 the
Federal Research Internet Coordinating Committee (FRICC), an informal group
of government program managers who fund portions of the Internet, tasked an
ad hoc committee to produce a plan for a White Pages service in the
Internet.  Although the meeting was held in February, RFC1107, a report
describing the outcome of the meeting was delayed until July.  The reason
was that the organization tasked with writing the report might also receive
funds as a result of the report being implemented.  A compromise of
conscience was finally reached by significantly "watering down" the report
so that it contained no concrete proposals, instead making a reference that
"strong funding and encouragement" was needed.  (Footnote: this post-meeting
editing is not as sinister as it might seem--the meeting called was
"politically" correct in the sense that it invited over 30 attendees each
with a differing agenda.  In essence, the two-day meeting rapidly devolved
into scantily-clad turf wars rather than practical technical discussion.)

	In general, all the scenarios arise from a simple premise: people
who give advice to the government should not profit from giving that advice
unless the collection of those people is operating under a "balanced
conflict of interest".

	It must be emphasized that the purpose of this contribution is NOT
to suggest that the current structure is corrupt or unduly self-interested.
Rather, our purpose is to demonstrate that the current structure is fraught
with peril--unintentional effects, smacking of impropriety, may result from
careless action or inaction.  Further, it should be noted that we live in a
world of "retroactive ethics"--actions are not judged by standards of
ethics which existed when the actions took place, rather any action is
judged by whatever standards of ethics are currently in place.  Recent
history indicates that any appearance of impropriety is effectively proof 
of that impropriety.


			    Recommendations

	The early DARPA-sponsored work in networking, by separating program
manager from researcher, was able to avoid these dilemmas.  Unfortunately,
Internet technology and the Internet are now larger than any single
organization.  What then, can be done to avoid this problem and still
further Internet technology?  This contribution suggests that Internet
technology has matured to the point where it is time to provide management
and guidance from a wide-cross section of users and providers.  That is,
while the seminal contributions of researchers made Internet technology
possible, a different paradigm is necessary to manage today's Internet
technology, which has effectively become an engineering and maintenance
problem.

	This contribution suggests the formation of an Internet Policy
Forum (IPF) appointed by the Federal Coordinating Council on Science,
Engineering and Technology (FCCSET).  The FCCSET is a formal body of the
Federal Government chartered with getting the various agencies with large
investments in information technology to coordinate with each other.  The
IPF charter, under the auspices of the FCCSET, would be to represent the
users of Internet technology from all segments of society.  

	Although the structure of the IPF would be largely similar to the
current IAB, there are three fundamental differences:

	- the IPF would meet openly, with published agendas and minutes,

	- the membership of the IPF would primarily be representatives from
the various communities which *use* Internet technology (e.g., some
representatives would be from the Internet regional networks); and,

	- funding for the IPF membership would be solely from the sponsors
of each member; as such, interests, and in particular research and
commercial interests, of each member would be fully disclosed.

It should be noted that each of these tenets circumvents weaknesses in
the current IAB structure:

	- because the IPF would meet openly, it would be open to scrutiny
from a large, vibrant community.  Under this model, the IPF would avoid
any appearance of being "an old boy's club".  

	- because the IPF membership would be drawn from the user and
vendor communities, the members would be motivated towards solving problems
in Internet technology.  Some members of the IPF might be "industry
experts" in Internet technology, others might be from the regional network
management, and so on.  A weakness in the current IAB structure is that the
majority of its members are sponsored by a small group of concerns; if
members are inclined to think about only those things they are funded to
think about, then it is important to draw from a larger collection of
concerns.  IPF members would be, by definition, accountable for and
responsible to, the users of the network.  In contrast, it can be
persuasively argued that the IAB membership is, by and large, not
responsible to, nor do they provide representation for *any* operational
community.  Unlike the IAB, the IPF membership would have a stake in the
continued success of Internet technology.

	- because the IPF membership would be required to fully disclose
their interests, it would be possible to achieve a "balanced conflict of
interest".  Since it is naive to think that interests at cross-purposes do
not exist, it is important to foster an environment in which such things
are entirely above board.  It should be noted that all professionals, be
they sponsored directly by the U.S. Government, by government-sponsored
research organizations, by academia, or by commercial concerns, all have
self-interests.  All such interests must be openly declared.

	The IPF itself would consist of two kinds of members: voting
members who would set policy, and non-voting members who would provide
liaison to other accredited organizations.  The IPF would be responsible
for managing the RFC process and the voting membership would be responsible
for advancing standards in Internet technology.

	Unlike the IAB, there would be no task forces or steering groups
under the IPF.  However, one IPF position would be that of "Internet
Technical Director".  This position would be responsible for coordinating
"development" of Internet technology.  "Research" efforts in networking
technology would be independent of the IPF.  The existing IETF would be
restructured to report to the Technical Manager under the name of "Internet
Technical Directorate".  Like the IETF, the ITD would be an open
organization, although there would be no IESG.

	It should be noted that the coupling of IPF and ITD is different
than the IAB/IETF relationship.  In particular, the membership of both the
IPF and the ITD would come from the same wide range of sponsors.  As such,
the ITD membership would be responsible for producing workable technology
for the IPF, and the IPF would be responsible for providing effective
direction to the ITD.  This is entirely unlike the current IAB/IETF
relationship in which there is little, if any, relationship between the
membership of the two bodies.  Realistically, the IETF has little
accountability to the IAB, as evidenced by the lack of IETF progress in
producing technical solutions to short-term problems over the last few
years.  Similarly, the IAB has little credibility with the IETF membership
at large given the lack of IAB direction, and the somewhat inconsistent
policy actions of the IAB (e.g., network management protocol standardization).


			      Conclusions

	In retrospect, it should be noted that Internet technology and
management have been relatively stagnant over the last three years.  In
particular, the Internet Management structure has been ineffective at
solving problems.  The first issue of THE INTERNET CRUCIBLE analyzed many
of the technical and economic failures in this regard.

	While there are many possible causes for this stasis, it does seem
likely that the continued orientation towards concentrating power in a
small, inbred, cloistered community has been a significant factor in this
regard.  The recent re-organization of the IAB is little more than
repackaging--no fundamental change in direction or motivation has occurred.
This issue of THE INTERNET CRUCIBLE has argued that the existing management
structure is the cause for many of the problems currently being seen on
the Internet today.

But, we have also seen how Internet technology has matured in the market
and is providing useful service.  It is now time to engage a broad
community to openly guide Internet technology in its stable phase.

-----------[000202][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 17:11:00 GMT
From:      mishkin@apollo.HP.COM (Nathaniel Mishkin)
To:        comp.protocols.tcp-ip
Subject:   Re: rpc protocols

In article <830@pacific.mps.ohio-state.edu> verber@pacific.mps.ohio-state.edu (Mark A. Verber) writes:
>In article <5177@merlin.usc.edu> posted to comp.sys.ibm.pc was a 
>BTW: Novell does seem to be dominant in the PC marketplace.  

No doubt this is true.  And no doubt that Novell has been pushing Netwise
RPC.  It just still isn't clear to me that this means that Netwise RPC
(as opposed the the Novell file system stuff) is being widely used as
well.  Maybe it is, and I just don't know.

>The press
>release from Sun said that Novell has more than four million PC nodes.
>I also note that Banyan (one of Novell's prime competitors in the PC
>server market seems to also support this RPC). 

Curiously, in material that accompanied the press release, a Banyan person
was quoted as saying the Banyan would continue to support and enhance
its own RPC, Net RPC.  Not exactly a ringing endorsement of the
Sun/Netwise/Novell system.  In fact, if you look at the accompanying
material, it's hard to tell whether the quoted supporters are declaiming
support for the Sun/Netwise/Novell troika, or whether they're just saying
"Yes, a standard RPC is good for all" (and under their breaths:  "So
we could do just *one* version of *our* software and so we could keep
out of this battle altogether"?)  But maybe I'm being too cynical about
the kinds of things that come out of (anyone's) marketing organization :-)
-- 
                    -- Nat Mishkin
                       Hewlett Packard Company / Apollo Systems Division
                       mishkin@apollo.com

-----------[000203][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 17:18:02 GMT
From:      dsmith@oregon.uoregon.edu (Dale Smith)
To:        comp.protocols.tcp-ip
Subject:   Remote database services ???

This is certainly not the right forum to pose these questions, but I can
think of no better one.

I have been doing a lot of thinking about Internet services that would
attract more interest of the general researcher.  Right now, the most
useful service provided by the Internet to the general researcher seems
to be electronic mail for communication amoung colleagues.  A distant
second and third would seem to be supercomputer access and ftp to obtain
software.

One service I can think of that would generate a lot of interest amoung
researchers here at the University of Oregon (and, I suppose, other
sites as well) would be access to remote database services.  I am
thinking of pay-for data base services such as BRS, DIALOG, and STN that
provide access to hundreds of diverse databases, including Chem
Abstracts, Nuclear Science Abstracts, Biosis Previews, Medline, Geobase,
Socialogical Abstracts, and Water Resources Abstracts to name a few. 

All of these services currently provide remote access via modem, often
via Telenet or a private network.  Some sites have purchased dedicated
lines to access these services.  So, here we have a research oriented
service and a number of ad-hoc networks that support access to these
services.  Since the one of the goals of NSFnet is to provide support
for researchers, it seems that access to these databases could fall
under the general thrust of what NSFnet is all about.

The key in my mind seems to be that these are commercial services (even
though some claim to be non-profit) and if they were connected in some
manner to the Internet, then we would be using the Internet to promote
selected firms.  However, in the long run it seems that it would save
everyone money and provide another carrot in the Internet basket to
recruit new sites.

What do other folks think about this subject?

-- 
Dale Smith, Assistant Director of Network Services
University of Oregon		Internet: dsmith@oregon.uoregon.edu
Computing Center		BITNET: dsmith@oregon.bitnet
Eugene, OR  97403-1212		Voice: (503)686-4394

-----------[000204][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 17:48:50 GMT
From:      sra@ULANA.MITRE.ORG
To:        comp.protocols.tcp-ip
Subject:   Re: DoD --> CMOT and SNMP

Dan

I did not think it was possible but your response together with 
the large amount of traffic has stirred me enough to respond.

I can not speak for all of DOD nor can I speak for all of the Air 
Force.  I can, however, respond in terms of my knowlege of the 
ULANA program and its requirements for SNMP and CMOT.  

The ULANA program is currently delivering LAN products to Air 
Force costomers.  These products are basically a wide variety of 
products that implement the extended suite of protocols based 
upon TCP/IP for 802.3 networks and in some cases FDDI networks.
These products range from transceiver cables to full hardware/
software attachments for mainframes.

Managing networks of this type would be difficult if all products 
were from a single supplier.  We do not have that luxury.  Ulana 
products come from a wide variety of LAN vendors.  With a single 
integration contractor we might have been able to define network 
management in the ULANA context.  Instead of one major 
integration contractor the ULANA program has two.  Still with 
only two we might have been able to define an interoperable 
network management subset between these vendors except for the 
fact that ULANA components are not the only components on the 
network.  We also expect AT&T machines from the SMSCRC contract, 
PCs from the Desk Top III contract, gateways from the Host 
concentrator contract and that vast array of user procured  
products that claim to be "ULANA compatable."

Being unable to define a government unique management protocol 
{thank goodness} we strove to develop a single suite of 
network management products form the internet community.  
Unfortunately, rather than a single solution with an evolution 
from today till the future we have two SNMP and CMOT.  Had we 
chosen either it would have cost the government many dollars 
since vendors have decided to implement one or the other (or in 
some cases both).  We chose instead to allow the vendor community 
to implement either.  The management station therefore is 
REQUIRED to implement both.

So as a longwinded answer to the variety of questions:

1) To my knowlege there is no requirement to implement CMOT 
except in the network management station.

2) The only current requirement for the users regarding SNMP or 
CMOT is a policy statement requiring them to use the ULANA 
contract.  

3) If users procure their own equipment outside ULANA, and 
wish to manage this equipment with future management stations 
then they MUST have either a CMOT agent or an SNMP agent.

Should the Army and the Navy join the ULANA program the above 
will apply to them as well.

A second set of questions asked for the availability of network 
management agents.  Although many vendors are shipping SNMP or 
are about to anounce either SNMP or in some cases CMOT, some 
vendors are doing neither.  This makes the network management 
solution even more complex.  For example, EXCELAN, a very good 
network vendor who has been active in network management events 
has declined to provide us cost or schedule information on an 
agent for their VMS attachment.  Because of this I find it hard 
to understand why anyone would buy EXCELAN VMS products.  Other 
vendors have indicated that they will need several hundred 
thousand dollars to provide agents.  Since we desire commercial 
products and do not have the desire or funds to develop a wide 
variety of agents we are not able to come to the aid of the 
community this time.

So to answer the questions as to availabilty of agents:

1) Ensure that your vendor of choice has announced or has 
available network management agents for the product you desire.

2) Be very cautious of vendors that provide dates more than three 
months in the future.

3) Vendors that do not provide management agents for their 
products (for example EXCELAN) are not providing the full suite 
of necessary protocols and should, at all costs, be avoided.

A list of with agents available through the ULANA program will be 
available in early October.

A last thought, if there are any vendors with network management 
stations that implement both SNMP and CMOT NOW! please give us a 
call.  We would like to hear about it.

Stan Ames

-----------[000205][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 18:04:25 GMT
From:      holleran@Apple.COM (Patrick Holleran)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote database services ???

In article <8079@oregon.uoregon.edu> dsmith@oregon.uoregon.edu (Dale Smith) writes:
>This is certainly not the right forum to pose these questions, but I can
>think of no better one.
>
>I have been doing a lot of thinking about Internet services that would
>attract more interest of the general researcher.  Right now, the most
>useful service provided by the Internet to the general researcher seems
>to be electronic mail for communication amoung colleagues.  A distant
>second and third would seem to be supercomputer access and ftp to obtain
>software.
>
>One service I can think of that would generate a lot of interest amoung
>researchers here at the University of Oregon (and, I suppose, other
>sites as well) would be access to remote database services.  I am
>thinking of pay-for data base services such as BRS, DIALOG, and STN that
>provide access to hundreds of diverse databases, including Chem
>Abstracts, Nuclear Science Abstracts, Biosis Previews, Medline, Geobase,
>Socialogical Abstracts, and Water Resources Abstracts to name a few. 
>
> (more stuff here)...
>
>The key in my mind seems to be that these are commercial services (even
>though some claim to be non-profit) and if they were connected in some
>manner to the Internet, then we would be using the Internet to promote
>selected firms.  However, in the long run it seems that it would save
>everyone money and provide another carrot in the Internet basket to
>recruit new sites.
>

     Dissemination of scholarly information quite often involves
commercial enterprises--for instance, subscriptions to journals are
not free.  I see no reason why access to databases which involve a
subscription fee ought to be prohibited on NSFNet of the Internet.
There definitely needs to be more useful resources to researchers
in a variety of disciplines accessible via national networks.

               Pat Holleran
               Apple Computer, Inc.
               holleran@apple.com

-----------[000206][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 19:35:59 GMT
From:      MAP@LCS.MIT.EDU (Michael A. Patton)
To:        comp.protocols.tcp-ip
Subject:   Reliable protocols on top of email


	Joshua Levy asks about considering E-Mail as an unreliable
datagram transport and using existing protocols to make it reliable.

From reading the description later, I would guess what you want has
different characteristics than "reliable stream" or "reliable single
transaction" approaches.  You may want to think out the design of the
reliability part of your protocol in a different light.  One thing to
ask is do you care about ordering?  It seems to me that the thing you
are designing is basically a standard distributed transaction protocol
over a replicated and distributed database, all the standard synchrony
and ordering considerations apply.  Since I expect you want it to be
running in more than two locations, you have to consider whether you
require serializability and if so what kind.  Then you need to think
about which of the various methods you wish to use.  Most of these are
topics of current research.  There are many designs which have various
features, different tradeoffs, or restrictions.  The problem here is
that once you realize that you are proposing a distributed database
maintained at more than two nodes you discover that the simple
peer-to-peer models are not quite adequate.

I might be able to dredge up some references from the course I took 18
months ago, but starting from more current articles on transaction
protocols might be better.

-----------[000207][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 19:57:00 GMT
From:      gamby@MDC.COM ("Randall Gamby")
To:        comp.protocols.tcp-ip
Subject:   RE: CMOT vs. SNMP

>Dan,
>	How does your response relate to the traffic I sent?  I just
>sent some traffic commenting on whether the DoD is requiring CMOT and
>SNMP in future TCP/IP implemenations delivered to the government.
>
>Robert Snyder       Disclaimer  --  nobody claims dis, but me

Hi everybody,

I just got back from NIST and answered the above for Robert (I normally
receive DDN messages and hadn't quite mastered the art of general mailings).
He at least felt that my answer might clear up some questions so I'm putting
my life on the line and sending it out.  I apologize up front for the length
of this message but I wanted to make sure the direct sections were made avail-
able and not my own personal subjective point of view.  Certain editorials
have been added to clarify status.

I have in my possession the following document from the Defense Communications
Agency:

       "The Department of Defense Open Systems
        Interconnection (OSI) Implementation Strategy"
        Dated: May 1988 (An updated one is supposed to be in work)
        Sponsor: DCA/DCEC (Code R130)
                 Interoperability and Standards
                 Derey Engineering Building
                 1860 Wiehle Ave.
                 Reston, VA  22090

On Network Mangement it says:
"Quote"
2.4.6 Network Management

   OSI Network Mangement is in the early stages of development and completely
conformant stable products are not expected until well into 1991.  The network
mangement standard still has significant issues to be resolved before the 
specific management services and protocols can be completely defined.

   There are three interim network management efforts expected to be available
before OSI Network Management products:

   o Manufacturing Automation Protocol (MAP) interim management standard
     (General Motors Manufacturing Automation Protocol, 1987)
   o Simple Network Mangement Protocol (SNMP) for the DoD in the near-term
     (IDEA011)(Case, 1988)
   o Common Management Information System/Common Management Information Protocol
     (CMIS/CMIP) for the DoD in the mid to long-term (IDEA012)(Ben-Artiz, 1988);
     (IDEA013)(LeBarre, 1988).

The Internet Design, Engineering, and Analysis Notes (IDEA) documents (note 1:
IDEAs are IETF working documents circulated for comment.  Because IDEA documents
carry no official status and are subject to change, they should NOT be refer-
enced as standards) are in the draft stage of development and have not yet been
adopted by the DoD, however, the Internet Activities Board (IAB) has recommended
that the Internet community adopt and adapt --> SNMP <-- for use as the basis
of common network management in the short term, and that a network management
system based on the ISO CMIS/CMIP be developed, deployed and tested for the
longer term. (Cerf, 1988)  All of these, as well as other existing protocols,
are being considered by the NIST(NBS) Network Management SIG (Personal Note:
the SIG is part of the Implementors Workshop that creates North American
Implementors Agreements that are talked about later and are the base documents
for such specs. as GOSIP, MAP/TOP, COS, etc.) which is working on the creation 
of a recommendation for an OSI network management standard.  It is the goal of 
this group to develop an initial set of network management Implementors Agree-
ments (IA) by December 1988. (Personal note: At last check these were in final 
rev. and ready for vote.)  Products based on these IAs can be expected approx-
imately one year after IA acceptance.  Although any of the above interim prot-
ocols can be implemented now, there is no guarantee that any of them would 
conform to the IAs when they are eventually issued.  Therefore, until the IAs 
are available, network management will probably be handled, as it generally is 
today, with proprietary protocols or other non-open system techniques.


Hopefully so much for network management, but some will argue that CMOT is
based on CMIS/CMIP with a TCP/IP transport.  The DoD document also addresses
the question of OSI upper layer applications on DoD transports.  I quote
another section (Sorry for the length but I want to make sure everyone has
the full and direct responses!):

3.1.1 DoD/OSI Protocol Profiles

   The protocol profile specified in GOSIP is a "pure" OSI stack; that is, it
is a set of protocols drawn entirely from OSI standards for each protocol layer.
The current operational DoD protocol profile is also a pure stack.  DoD has
tasked DCA to provide support for interoperability between these two pure stack
profiles only.

   Profile implementations have been built with a mixture of DoD and OSI pro-
files at each layer.  These are sometimes referred to as "mixed protocol stack"
or "mixed protocol profile" implementations.  Such implementations take advant-
age of the similarities between the services provided by some OSI protocols and
those offered by analogous protocols in the DoD architecture.  The two main
possibilites for mixed protocol profiles are DoD applications over OSI lower
layers and OSI applications and upper layers over DoD lower layers. (Personal
note: this is CMOT or, as I saw in another inquire, X.400 on TCP/IP.)  A mixed-
protocol approach, using the second possibility, may have the advantage of 
providing a seemingly quick migration to the use of OSI application services in 
the current DoD internetworking environment.  However, it has the disadvantage 
of increased complexity of interoperation and increased costs.

   Each additional protocol profile in the transition process requires methods
for it to interoperate with every other protocol profile.  The introduction
of one addition protocol stack would require the development of two additional
interoperation procedures-one between the DoD stack and the mixed stack, and one
between the OSI stack and the mixed stack.  With only two different protocol
stacks (the current DoD and the targeted OSI), only one interoperation procedure
needs to be provided.  Additionally, provision and support of a mixed stack 
environment requires considerable development effort, and vendor focus is on the
provision of pure stack protocol products.

-->Therefore, to minimize complexity and to realize the economic benefit of 
vendor supplied and supported products, only "pure" OSI protocol profiles are
considered in the DoD's implementation strategy.<-- Mixed stack implementations
may be used only as interim transitional mechanisms to facilitate a system's
migration to a pure OSI profile.


So I won't say whether to use CMOT or SNMP but if I were spec'ing out a DoD
system, I think I personally would stay with a pure DoD SNMP or use a CMIP
on OSI transport if it's an OSI product.  I know this was long but I've got
twice as much mail on the subject than what's here.

Thanks for the listen and I hope this was worth the effort to put a little
light on the subject.

Randall Gamby
McDonnell Douglas Aircraft Co., St. Louis
(314)895-5296

-----------[000208][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 21:42:30 GMT
From:      mhw@wittsend.lbp.harris.com (Michael H. Warfield (Mike))
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet 0

In article <8909151911.AA14633@uf.msc.umn.edu> fin@UF.MSC.UMN.EDU ("Craig Finseth") writes:

>	Is is "allowed" (i.e., technically legal)?
 
>Undefined.  Network number 0 means "this net."  By analogy subnet
>number 0 means "this subnet."  You won't find this mentioned anywhere
>official, that's why it is undefined.

	This was discussed some time ago in this news group and it was
generally agreed that subnet 0 was prohibitted by RFC 950.

	Subnet 0 is mentioned in RFC950 as follows:

+-------------------------RFC 950 ---------------------------------------+

         It is useful to preserve and extend the interpretation of these
         special addresses in subnetted networks.  This means the values
         of all zeros and all ones in the subnet field should not be
         assigned to actual (physical) subnets.

+-------------------------RFC 950 ---------------------------------------+

	It will work in most cases (I know, I'm running one; sigh).  However,
it is not a good ideas, it should be avoided, and it is technically proscribed.


Michael H. Warfield  (The Mad Wizard)	| gatech.edu!galbp!wittsend!mhw
  (404)  270-2123 / 270-2098		| mhw@wittsend.LBP.HARRIS.COM
An optimist believes we live in the best of all possible worlds.
A pessimist is sure of it!

-----------[000209][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 21:49:53 GMT
From:      mhw@wittsend.lbp.harris.com (Michael H. Warfield (Mike))
To:        comp.protocols.tcp-ip
Subject:   Re: UUCP --> FTP

In article <89258.213225CMH117@PSUVM.BITNET> CMH117@PSUVM.BITNET writes:
>I need to download files from a machine running strictly UUCP to a machine
>running only FTP.  I've heard that this is impossible.

	No.  This is possible but only if you have access to another machine
somewhere in the middle that can play both games.  Out here in UUCP land our
problem is generally the reverse, where we want to get something from an FTP
only site.  That requires something fancy like a LISTSERV system.

	If you mean downloading directly with no help in-between from
another system, you are out of luck.  If it's not something gigantic and
your uucp/internet neighbors don't object (CHECK!!) have the uucp site
encode it and mail it to you.  If it's an autonomous archive site, wwwweeeellll
so much for that idea.

Michael H. Warfield  (The Mad Wizard)	| gatech.edu!galbp!wittsend!mhw
  (404)  270-2123 / 270-2098		| mhw@wittsend.LBP.HARRIS.COM
An optimist believes we live in the best of all possible worlds.
A pessimist is sure of it!

-----------[000210][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 22:09:25 GMT
From:      sw0l+@ANDREW.CMU.EDU ("Steven L. Waldbusser")
To:        comp.protocols.tcp-ip
Subject:   New Release of SNMP from CMU (version 1.0)


  I have just released version 1.0 of the CMU SNMP libraries and
applications.  The source code and documentation for this package is now
available for anonymous FTP.  The following text is from the README file
in the distribution:

  The files in this directory compromise the 1.0 release of the CMU SNMP
distribution.  This includes the SNMP/ASN.1 library, many client
applications, and supporting documentation.

This code was written with efficiency and portability in mind.  The
libraries are very
independent of hardware and OS dependencies.  They have been run on
Unix, DOS,
Macintosh and other OS's on a variety of platforms.  The
applications compile and run on the following systems: IBM PC/RT running
ACIS
Release 3, Sun3/60 running SUNOS 3.5, DEC microVax running Ultrix 2.2,
and
DECStation 3100's runing Ultrix 3.0.  They are expected to run on any
system
with a Berkeley socket interface.

The agent compiles into about 10 KB of 68000 code.  The machine
independent
portions of this agent also run on CMU's IBM PC/AT based router.  The
snmp agent
for the Kinetics box is included in this distribution, but the KIP code
it links against is not
yet distributable (this is not the released KIP code).  This will
probably
be distributed at another time if there is sufficient demand.

The applications are designed to be useful in the real world. 
Snmpnetstat
is a port of the Berkeley Unix netstat that gathers it's information
using
SNMP.  (Many people will enjoy "snmpnetstat mygateway public -r"). 
Snmpstatus
collects several pieces of information and presents them in a useful
format
and is good for everyday status monitoring.  The rest of the tools are
simpler,
but still interpret input and output symbolicly (they can be used without
referencing the RFC's!).

For instance, 
snmpnetstat mygateway public -r returns:
Routing tables
Destination      Gateway            Flags   Interface
bbn-net-temp     psc-gw3.psc.edu    UG      Ethernet0
arpanet          prpnet-gw.cc.cmu.e UG      Ethernet0
xerox-net        psc-gw3.psc.edu    UG      Ethernet0
hp-internet      psc-gw3.psc.edu    UG      Ethernet0
...

snmpstatus returns:
[128.2.56.220]=>[Kinetics Fastpath2] Up: 1 day, 4:43:31
Recv/Trans packets - Interface: 262874/39867 | IP 47432/34587

The rest of the applications typically present a variable in a form
similar
to the following:
Name: interfaces.ifTable.ifEntry.ifType.1
INTEGER: ethernet-csmacd(6)

The parsing and printing of symbolic object identifiers and the printing
of
typed variables is driven by a database that describes the MIB.
The MIB database is now retrieved from a text file in the ASN.1 format
used in
the RFC1066 MIB.  This makes adding new (enterprise specific) mibs to
the database
very simple.  I will solicit description files from other SNMP vendors
and redistribute
them via anonymous FTP.  Initially, the mib.txt file contains a
discription of the
RFC 1066 MIB and portions of the CMU enterprise specific MIB.  I had
help in optimizing
the parser from Phil Lapsley of Berkeley (Thanks Phil!).

For further information, please consult the man pages.  There are man
pages for
each of the applications, as well as for the Application Programming
Interface (API).

The API has been redesigned to present a very convenient and useful
asynchronous
interface to the SNMP transport.  In addition, snmp_client.c contains a
toolkit
of routines that simplify writing client applications.  In particular,
there is
a synchronous interface built on top of the asyncronous interface that
makes
writing applications very easy.

This distribution is coprighted by CMU, but may be used and sold without
permission.  The snmpnetstat application is derived from the Berkeley
4.3 netstat,
and is therefore also copyrighted by Berkeley.  Consult the copyright
notices for
further information.

The distribution is available by anonymous FTP from the host
lancaster.andrew.cmu.edu (128.2.13.21) as the file pub/cmu-snmp1.0.tar. 
I will
maintain a repository of mib description files in the directory pub/mibs.

Please direct questions, comments, and bug reports to
sw0l+snmp@andrew.cmu.edu.
I have received very helpful feedback in the past that has been
integrated into 
the current release.  This will continue in the future.

If you pick up this package, please send me a note to the above address,
so
that I may notify you of future enhancements/changes and additions to the
set of applications (several are planned).  I will also redistribute
applications
using the CMU SNMP library that were written elsewhere and placed in the
public domain.
There are already several such applications pending such a distribution.

There is a gateway at CMU running the agent.  Feel free to query it.  You
can access as netdev-kbox.cc.cmu.edu (128.2.56.220) with community name
"public".


Steve Waldbusser
Network Development
Carnegie-Mellon University

-----------[000211][next][prev][last][first]----------------------------------------------------
Date:      20 Sep 89 23:14:50 GMT
From:      mogul@decwrl.dec.com (Jeffrey Mogul)
To:        comp.protocols.tcp-ip
Subject:   Re: Subnet 0

In article <8909151911.AA14633@uf.msc.umn.edu> fin@UF.MSC.UMN.EDU ("Craig Finseth") writes:
>
>	Is it [subnet number = 0] "allowed" (i.e., technically legal)?
>
>Undefined.  Network number 0 means "this net."  By analogy subnet
>number 0 means "this subnet."  You won't find this mentioned anywhere
>official, that's why it is undefined.

Actually, it is mentioned "somewhere official".  From RFC950:

						         [The] values
         of all zeros and all ones in the subnet field should not be
         assigned to actual (physical) subnets.

The Host Requirements (draft?) RFC more or less reiterates this rule.

As an aside: much as it pains me to admit it, in all honesty I have
to say that one probably would not run into any real problems by
assigning a subnet number = 0.  Avoiding subnet 0 is "good engineering
practice" more than a result of bitter experience.  (That is not the
case with assigning a host number = 0, since this looks to some hosts
like a broadcast).  I make this admission because otherwise people
are going to say "I tried using subnet 0, it works, so why the rule?"

-Jeff

-----------[000212][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 89 07:26:00 EDT
From:      "BURKE D.N." <burke@nusc-npt.navy.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   How does one go about . . .
hello,
	houw does one go about "connecting" to the internet directly, without
using 3rd party resources, connection, etc.  Also what is the timeframe and 
costs involved (assuming it's possible at all)?

Dave Burke

-----------[000213][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 89 11:26:00 GMT
From:      burke@NUSC-NPT.NAVY.MIL ("BURKE D.N.")
To:        comp.protocols.tcp-ip
Subject:   How does one go about . . .

hello,
	houw does one go about "connecting" to the internet directly, without
using 3rd party resources, connection, etc.  Also what is the timeframe and 
costs involved (assuming it's possible at all)?

Dave Burke

-----------[000214][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 89 15:08:29 GMT
From:      caj@itivax.iti.org (Celia A. Joseph)
To:        comp.protocols.tcp-ip
Subject:   Re: DOD ---> CMOT VERSUS SNMP

Dave-

To clarify what I think you're talking about:

1) Functional differences between CMOT and CMIP - in comparing the two
documents, the only functional differences I can find are that CMOT does
not include the current CMIP addenda, namely CancelGet and Add/Remove.

2) ASN.1 data type differences - I think what you are refering to is what
falls under Structure of Management Information (SMI) in ISO.  The ISO SMI
includes some data types that weren't used in the Internet's equivalent
document (rfc1065 - Internet Structure and Identification of Managenet
Information for TCP/IP-based internets).  However, the Internet document
also defines some types that aren't in the ISO documents.

The ISO work in this area is far from being turned into final standards,
although their basic data type definitions have been fairly stable over the
past year or so.  The intent in ISO is to give a basic set of data types
that appear to be generally useful -- not to define a cast-in-stone set
of definitions that have to be used.  

Furthermore, the data type definitions are a separate issue from CMIP.  CMIP
merely provides the means to carry the information.  It doesn't care what the
contents of the data are.  Thus, a vendor could implement CMIP with the
current Internet data type definitions and change these definitions at a
latter date without having to change their CMIP implementation.

On the subject of GOSIP - GOSIP version 1 and the draft GOSIP version 2 do
not specify network management yet.  GOSIP's stated intention is to follow
the work being done in the NIST workshops.  Since the NIST NM SIG has not
yet finalized its work, it is not yet included in GOSIP.  NIST, however,
is closely tracking the ISO standards.

Hope this clarifies things somewhat,

Celia Joseph
Industrial Technology Institute

Internet:  caj@iti.org
Phonenet: (313) 769-4153

-----------[000215][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 89 16:22:00 GMT
From:      HAGGAR@BNR.CA (Haggar  Alsaleh, H.)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Software.

Could any one tell me how/where could I get public domain
Software to Monitor/diagnose Ethernet/802.3 Traffic.
                           Thanks in advance
                             haggar@bnr.ca
                             214 997 4806

-----------[000216][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 89 18:14:13 GMT
From:      schoff@SOLBOURNE.NYSER.NET ("Martin Lee Schoffstall")
To:        comp.protocols.tcp-ip
Subject:   Re: DoD --> CMOT and SNMP


Stan,

I too am stirred to respond, to what appears to be a statesman like message
of yours.

 Being unable to define a government unique management protocol 
 {thank goodness} we strove to develop a single suite of 
 network management products form the internet community.  

You're clearly unable but you and your staff certainly seem to have tried.
Aren't their names on CMOT documents?  Hasn't MITRE participated
heavily in pushing CMOT as a major agenda item.  At interop88 I
heard what you had to say after the network management panel, you
were pushing then.

 Should the Army and the Navy join the ULANA program the above 
 will apply to them as well.

This would be unfortunate since clearly things have changed in a very
major way in the area of network management in just the last 12 months.
One doesn't want to be saddled with out of date concepts and technology
from past recommendations, and 2nd opinions can also be important to
test the validity and quality of past recommendations.

 3) Vendors that do not provide management agents for their 
 products (for example EXCELAN) are not providing the full suite 
 of necessary protocols and should, at all costs, be avoided.

Since you've left the arena of "facts" and entered into the arena
of recommendations here are a few to consider:

(1) Consultive recommendations should be considered from sources that have both
deep and current experience with Internet technology (for instance knowing
what is in an ARP table).  My personal favorite is Epilogue which has
implemented both CMOT and SNMP, they'll do anything for a buck :-)
but more importantly they do it VERY VERY well.

(2) Independant assement is very important, having a vested interested
in a recommendation needs to be stated and known.  I am of course an
co-author of SNMP.

(3) User input and reality input is very useful to make a good recommendation.
Because its on paper doesn't mean its real, because its an "International
Standard" doesn't mean it will work well.

(4) Recommending moving targets is painful for vendors and does nothing
for users.

Lastly, your message discusses the "facts" of NetworkManagement in ULANA,
whether they are good facts or not is another issue.

Martin Schoffstall

-----------[000217][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 89 19:18:49 GMT
From:      nick@toro.UUCP (Nicholas Jacobs)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote database services ???

In article <34890@apple.Apple.COM> holleran@Apple.COM (Patrick Holleran) writes:
>In article <8079@oregon.uoregon.edu> dsmith@oregon.uoregon.edu (Dale Smith) writes:
>>The key in my mind seems to be that these are commercial services (even
>>though some claim to be non-profit) and if they were connected in some

Certainly it's an interesting idea. We've recently set up our own internal
internet and one of our upcoming projects is to supply our traders with feeds
from the various financial services. One big issue is that of payment: most
of these feeds are based on payment per line. If you take that line and
distribute it internally, how is the billing handled for it?

I'm curious to see how people resolve this issue.

Nicholas Jacobs
UUCP: ...!uunet!toro!nick Internet: toro!nick@uunet.uu.net
AT&T: (212) 236-3230

-----------[000218][next][prev][last][first]----------------------------------------------------
Date:      21 Sep 89 23:11:12 GMT
From:      karn@jupiter (Phil R. Karn)
To:        comp.protocols.tcp-ip
Subject:   Re: Reliable protocols on top of email

>	Joshua Levy asks about considering E-Mail as an unreliable
>datagram transport and using existing protocols to make it reliable.

One thing to consider is the effective delay*bandwidth product of the
email network you're using, particularly if it's a multihop
store-and-forward network like UUCP. Since most of the time a message
spends in such a network is spent in disk spool files on the various
machines, the effective delay*bandwidth product is likely to be MUCH
larger than what TCP and similar transport protocols are used to.

Phil

-----------[000219][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 89 01:16:29 GMT
From:      beau@ultra.UUCP (Beau James {Manager - SW Development - Ultra Networks})
To:        comp.protocols.tcp-ip
Subject:   4.3BSD routed/gateways bug & fix

This is a followup to a message I posted two weeks ago regarding
a problem with the 4.3-tahoe BSD route daemon (and also SunOS through
4.0.3).  We've identified the bug and at least a partial fix.

Symptom recap:
	Remote network gateways identified to routed as "active"
	gateways in the /etc/gateways file are entered on the local
	machine as gateways to destination net "0.0.0.0" instead of
	the destination network named in the /etc/gateways file.
	That invalid information is then broadcast by the local
	system's route daemon.

Problem identified:
	The routine "gwkludge()" in routed/startup.c processes the
	entries from the /etc/gateways file.  For active gateways,
	it ends up adding the route by calling the subroutine
	"addrouteforif()", in the same module.  "addrouteforif()"
	is also called by "ifinit()" when the hardware interfaces
	found by the kernel are added to the route daemon's tables.

	It appears that when "ifinit()" and "addrouteforif()"
	were extended to handle subnetted networks, several
	new fields were added to the (struct interface).
	However, "gwkludge()" was not modified to correctly
	initialize those fields before calling "addrouteforif()".

Partial (?) bugfix:
	The following change to the bottom of "gwkludge()" will
	result in the proper destination network address being
	entered into the routing tables:

                /* assume no duplicate entries */
                externalinterfaces++;
                ifp = (struct interface *)malloc(sizeof (*ifp));
                bzero((char *)ifp, sizeof (*ifp));
                ifp->int_flags = IFF_REMOTE;
                /* can't identify broadcast capability */
                ifp->int_net = inet_netof(dst.sin_addr);
	ADD-->  ifp->int_subnet = ifp->int_net;
                if (strcmp(type, "host") == 0) {
                        ifp->int_flags |= IFF_POINTOPOINT;
                        ifp->int_dstaddr = *((struct sockaddr *)&dst);
                }
                ifp->int_addr = *((struct sockaddr *)&gate);
                ifp->int_metric = metric;
                ifp->int_next = ifnet;
                ifnet = ifp;
                addrouteforif(ifp);

	This change has been tested on a non-subnetted Ethernet
	environment.  There are two additional fields in the
	(struct interface) that probably should be initialized
	to non-zero values, but it is not clear to me what the
	proper initialization is, for remote gateways.  The fields
	are:

		ifp->int_netmask
		ifp->int_subnetmask

	For interfaces found by the kernel, "ifinit()" uses an
	ioctl(SIOCGIFNETMASK) and a series of tests to set these
	fields:

                if (ioctl(s, SIOCGIFNETMASK, (char *)&ifreq) < 0) {
                        syslog(LOG_ERR, "%s: ioctl (get netmask)",
                            ifr->ifr_name);
                        continue;
                }
                sin = (struct sockaddr_in *)&ifreq.ifr_addr;
                ifs.int_subnetmask = ntohl(sin->sin_addr.s_addr);
                sin = (struct sockaddr_in *)&ifs.int_addr;
                i = ntohl(sin->sin_addr.s_addr);
                if (IN_CLASSA(i))
                        ifs.int_netmask = IN_CLASSA_NET;
                else if (IN_CLASSB(i))
                        ifs.int_netmask = IN_CLASSB_NET;
                else
                        ifs.int_netmask = IN_CLASSC_NET;
                ifs.int_net = i & ifs.int_netmask;
                ifs.int_subnet = i & ifs.int_subnetmask;
                if (ifs.int_subnetmask != ifs.int_netmask)
                        ifs.int_flags |= IFF_SUBNET;

	If anyone out there has better insight as to the proper way
	to initialize these netmasks for the case of remote gateways,
	please pass it along.

Thanks,

Beau James				beau@Ultra.COM
Ultra Network Technologies		{sun,ames}!ultra.com!beau

-----------[000220][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 89 04:53:50 GMT
From:      perl@pbseps.UUCP (Richard Perlman)
To:        comp.dcom.lans,comp.protocols.tcp-ip
Subject:   XNS / TCP gateway??

This is probably a crazy question, but then that's often how new
products are born.  In any case...  Is there such a thing as a
translating gateway between TCP/IP and XNS?  I have a specific
need, as follows:  Site a runs TCP/IP and uses telnet to access
remote services on other hosts and terminal servers.  Site b is
an XNS terminal server (UB NIU-180 or X.25 gateway), it runs
whatever sort of virtual terminal protocol UB provides with XNS
(whatever protocol you connect to when you type 'connect <host>'
from an NIU-180?).

I would like to use telnet at site a to talk to the server at
site b.
    Site a                                               Site b
+-------------+    telnet   +---------+   UB xns ?    +----------+
| tcp/ip host |=============| gateway |===============| niu-180  |
+-------------+  net A      +---------+    net B      +----------+
       |        ethernet                  ethernet          |
  my terminal                                          remote service

So in other words (if I still havn't made my point clearly)  I
would like the "remote service" attached to the NIU-180 to
appear to me as thought it were running telnet.  Got it?

Well, is there such a thing.  All reasonable replies accepted!

-- 
Richard Perlman * perl@pbseps.pacbell.com || {ames,sun,att}!pacbell!pbseps!perl
180 New Montgomery St. rm 602,   San Francisco, CA  94105  |*|  1(415) 545-0233

-----------[000221][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Sep 89 09:16:47 EDT
From:      Cliff Stallings <cliff@wsu-eng.eng.wayne.edu>
To:        tcp-ip@nic.ddn.mil
Subject:   MS-DOS virus rumor
 
Is anyone aware of any significant information about the MS-DOS virus
which is suppose to attack on Columbus Day (Oct. 9).  I have heard numerous
versions of what is suppose to happen and wish to advise our MS-DOS users
on the network.
 
Thanks in advance for your help,
 
 cliff@wsu-eng.eng.wayne.edu
 (313) 577-3824
-----------[000222][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Sep 89 09:20:21 EDT
From:      BDK@UNB.CA
To:        TCP-IP@SRI-NIC.ARPA
Subject:   Re: New Release of SNMP from CMU (version 1.0)
How can those  not on the internet get a copy?
Brian Kaye
University of New Brunswick
>  I have just released version 1.0 of the CMU SNMP libraries and
> applications.  The source code and documentation for this package is
> now available for anonymous FTP.  The following text is from the
> README file in the distribution:
>
>  The files in this directory compromise the 1.0 release of the CMU
> SNMP distribution.  This includes the SNMP/ASN.1 library, many client
> applications, and supporting documentation.
>
> This code was written with efficiency and portability in mind.  The
> libraries are very
> independent of hardware and OS dependencies.  They have been run on
> Unix, DOS,
> Macintosh and other OS's on a variety of platforms.  The
> applications compile and run on the following systems: IBM PC/RT
> running ACIS
> Release 3, Sun3/60 running SUNOS 3.5, DEC microVax running Ultrix 2.2,
> and
> DECStation 3100's runing Ultrix 3.0.  They are expected to run on any
> system
> with a Berkeley socket interface.
>
> The agent compiles into about 10 KB of 68000 code.  The machine
> independent
> portions of this agent also run on CMU's IBM PC/AT based router.  The
> snmp agent
> for the Kinetics box is included in this distribution, but the KIP
> code it links against is not
> yet distributable (this is not the released KIP code).  This will
> probably
> be distributed at another time if there is sufficient demand.
>
> The applications are designed to be useful in the real world.
> Snmpnetstat
> is a port of the Berkeley Unix netstat that gathers it's information
> using
> SNMP.  (Many people will enjoy "snmpnetstat mygateway public -r").
> Snmpstatus
> collects several pieces of information and presents them in a useful
> format
> and is good for everyday status monitoring.  The rest of the tools are
> simpler,
> but still interpret input and output symbolicly (they can be used
> without referencing the RFC's!).
>
> For instance,
> snmpnetstat mygateway public -r returns:
> Routing tables
> Destination      Gateway            Flags   Interface
> bbn-net-temp     psc-gw3.psc.edu    UG      Ethernet0
> arpanet          prpnet-gw.cc.cmu.e UG      Ethernet0
> xerox-net        psc-gw3.psc.edu    UG      Ethernet0
> hp-internet      psc-gw3.psc.edu    UG      Ethernet0
> ...
>
> snmpstatus returns:
> [128.2.56.220]=>[Kinetics Fastpath2] Up: 1 day, 4:43:31
> Recv/Trans packets - Interface: 262874/39867 | IP 47432/34587
>
> The rest of the applications typically present a variable in a form
> similar
> to the following:
> Name: interfaces.ifTable.ifEntry.ifType.1
> INTEGER: ethernet-csmacd(6)
>
> The parsing and printing of symbolic object identifiers and the
> printing of
> typed variables is driven by a database that describes the MIB.
> The MIB database is now retrieved from a text file in the ASN.1 format
> used in
> the RFC1066 MIB.  This makes adding new (enterprise specific) mibs to
> the database
> very simple.  I will solicit description files from other SNMP vendors
> and redistribute
> them via anonymous FTP.  Initially, the mib.txt file contains a
> discription of the
> RFC 1066 MIB and portions of the CMU enterprise specific MIB.  I had
> help in optimizing
> the parser from Phil Lapsley of Berkeley (Thanks Phil!).
>
> For further information, please consult the man pages.  There are man
> pages for
> each of the applications, as well as for the Application Programming
> Interface (API).
>
> The API has been redesigned to present a very convenient and useful
> asynchronous
> interface to the SNMP transport.  In addition, snmp_client.c contains
> a toolkit
> of routines that simplify writing client applications.  In particular,
> there is
> a synchronous interface built on top of the asyncronous interface that
> makes
> writing applications very easy.
>
> This distribution is coprighted by CMU, but may be used and sold
> without permission.  The snmpnetstat application is derived from the
> Berkeley 4.3 netstat,
> and is therefore also copyrighted by Berkeley.  Consult the copyright
> notices for
> further information.
>
> The distribution is available by anonymous FTP from the host
> lancaster.andrew.cmu.edu (128.2.13.21) as the file pub/cmu-snmp1.0.
> tar. I will
> maintain a repository of mib description files in the directory
> pub/mibs.
> Please direct questions, comments, and bug reports to
> sw0l+snmp@andrew.cmu.edu.
> I have received very helpful feedback in the past that has been
> integrated into
> the current release.  This will continue in the future.
>
> If you pick up this package, please send me a note to the above
> address, so
> that I may notify you of future enhancements/changes and additions to
> the set of applications (several are planned).  I will also
> redistribute applications
> using the CMU SNMP library that were written elsewhere and placed in
> the public domain.
> There are already several such applications pending such a
> distribution.
> There is a gateway at CMU running the agent.  Feel free to query it.
> You can access as netdev-kbox.cc.cmu.edu (128.2.56.220) with community
> name "public".
>
>
> Steve Waldbusser
> Network Development
> Carnegie-Mellon University
-----------[000223][next][prev][last][first]----------------------------------------------------
Date:      Fri, 22 Sep 89 14:04:58 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        oliveb!amdahl!pacbell!pbseps!perl@apple.com, tcp-ip@nic.ddn.mil
Subject:   Re:  XNS / TCP gateway??
(You're not going to like this...)

What you need is something in the category, called "application gateway".  You
do not simply need translation between the transport-and-below lower layers,
but rather have a difference at every level, except perhaps media.  Hence, you
need to translate every layer.  In reality, this means that you need something
that is "dual stack" running both ENTIRE sets of protocols and a translation
device in between.  For software application gateways, this normally means a single
application, running on top of the two transport stacks, where the application
does BOTH application protocols and translates between them.

In this particular case, there is a different solution.  It is the part you might
not like:

Take one XNS-based terminal server and one TCP-based terminal server and back
them up to each other.  Connect the serial ports.  Play with it until the 
configurations are right.

You now have a terminal protocol translator.

Dave
-----------[000224][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 89 11:42:45 GMT
From:      epsilon@wet.UUCP (Eric P. Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote database services ???

Public data networks (Telenet, Tymnet, etc.) are ideally
suited for these services, "expand with demand," and tend to be
pretty much universally accessible.

What you are proposing is not only parasitic, but insulting to
those of us who crafted this unique resource.  There are
some things that can only be done on the Internet.  You don't
need Internet's capabilities.  You're looking for a common
carrier.  We need what little bandwidth we have.  Internet can't
be all things to all people.

					-=EPS=-

(No vested interest in any PDN or commercial database service)

-----------[000225][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 89 14:02:22 GMT
From:      kannan@cerc.wvu.wvnet.edu (R. Kannan)
To:        comp.unix.questions,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   How to handle connection time outs + host address compatibility ...

Hai 

	We would like to seek the advise on two issues:

Problem 1:

	What is the bext way to handle errno 61 => ETIMEDOUT,

	error => connection timed out.

	At the present we are closing the socket and reopening if errno == 61.

	This also led to errno 48 and 54 which are 

#define EADDRINUSE      48              /* Address already in use */
#define ECONNRESET      54              /* Connection reset by peer */


	What are the several options available if one desires to send the 
message anyway!


	Simple sample code would help.
Problem 2:

        "gethostid" returns a "long", the id of the processor.

        "gethostbyname" returns a pointer to "struct hostent", with two fields
        of relevance => "h_addr" and "h_length"

	After an "accept" call, the address of the peer is placed in the
        sockaddr_in.sin_addr.s_addr field.

	1. Are the results returned by gethostid, gethostbyname and accept 
        calls compatible. 
	2. What are the necessary htonl, ntohs conversion 
	required. 
	3. Atleast in the AF_INET domain, can one assume that the
	host length will be == sizeof(long or u_long)?

	Simple sample code would help.

Thank you very much for your time.

--kannan

-----------[000226][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 89 16:55:08 GMT
From:      stev@VAX.FTP.COM
To:        comp.protocols.tcp-ip
Subject:   Re: DoD --> CMOT and SNMP

*We chose instead to allow the vendor community 
*to implement either.  The management station therefore is 
*REQUIRED to implement both.


*Stan Ames


as someone looking into developing management stations, where can i
get two independantly constructed CMOTs to test my code against?
there are several SNMP "stacks" around (CASE's, Proteon's,
NYSERNet's, cisco's, MIT's, CMU's).  is anyone ready to give me the IP
address of an agent to test against?  is anyone working on a public
domain "stack" like the MIT and CMU SNMP code?

good luck getting a management station to understand both at this
point in time.


i dont necessarily think SNMP is god's gift to network management.
but, it is out there, it does work, it seems to be widely supported.
why go over to something like CMOT unless it offers much greater
functionality, which it does not seem to. it's big draw seems to be 
a connection to ISO (or is it OSI?) standards. i wouldnt be suprised to
find the SNMP people porting SNMP to run on TP4/CLNP.


stev knowles
stev@ftp.com
ftp software
617-246-0900

-----------[000227][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 89 17:49:39 GMT
From:      kwe@bu-cs.BU.EDU (kwe@bu-it.bu.edu (Kent W. England))
To:        comp.protocols.tcp-ip
Subject:   Re: Remote database services ???

In article <575@wet.UUCP> eps@CS.SFSU.EDU (Eric P. Scott) writes:
>Public data networks (Telenet, Tymnet, etc.) are ideally
>suited for these services, "expand with demand," and tend to be
>pretty much universally accessible.

	No, internetworks are universally accessible.  An aggregate of
networks that is not internetworked is not universally accessible.
>
>What you are proposing is not only parasitic, but insulting to
>those of us who crafted this unique resource.

	I imagine the questioner was thinking of the NSF sponsored
Internet.  He could be thinking of the wider FRICC sponsored Internet.
You are thinking of some other internetwork, possibly some predecessor
of the current Internet.

>  There are
>some things that can only be done on the Internet.  You don't
>need Internet's capabilities.  You're looking for a common
>carrier.  We need what little bandwidth we have.  Internet can't
>be all things to all people.
>

	You miss a more critical point of building an internetwork
than the advanced functionality of some protocol.  More critical than
the specific functionality of one of many protocols that may run on
one internetwork and not on another is the fact that an internetwork
is universal.

	The NSF Internet, or the wider FRICC Internet, or the future
National Research and Education Network will be judged as successful
chiefly by how universal and ubiquitous it/they become.

	It is more important to be ubiquitous than to be
state-of-the-art on an operational research and educational
internetwork, compared to a *network* research internet.  Services
such as access to Dialog or whatever are important goals of the
operational internetworks and are not insulting to those who are
building these internets.

	The research and education "Internet" must become all things
to all people to become what the builders, and those who pay for it,
envision.  And if we could buy it commercially, or even envision a day
when we could buy it commercially, then we would.  We are certainly
paying commercial rates (at least in some parts of the Internet) to
get Internet service, and it is well worth it.

	The network research community needs and is getting a new
research internet.  Those who use internets to conduct the business of
research and education accidentally co-opted it from the network
researchers.  Sorry about that, fellas.  But let us not confuse what
the Internet today really is with what it once was.

	The old network-research internet was a grand and glorious
thing.  Perhaps grander and more glorious to those who built her than
the Internet today seems.  But the old-boys should be glad their
little child grew up, moved to the big city and became famous.  Still,
it is hard to see children grow up and harder still to let them become
independent and other than what we envisioned they would be.

	Kent England, Boston University and NEARnet

	[Disclaimer: I do not represent an official position of either
Boston University or NEARnet in this matter.]

-----------[000228][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 89 19:50:41 GMT
From:      warb@faatcrl.UUCP (Dan Warburton)
To:        comp.protocols.tcp-ip
Subject:   Gould tcp/ip


I'm considering pulling my terminals off Goulds RS-232 8-line async
and plugging them into a cisco terminal server. Giving us access to
the Gould via Telnet. 

Question: Does anyone know how well Goulds Telnet implementaion holds
	  up under heavy (8 to 10 users) use. We have a sun and a pc
	  on the net now but cannot tell how well multiple uses will
	  fair.

Let me hear from all you lucky ones working on Gould MPX based
computer systems. Try E-mail to: warb@faatcrl.uucp or voice to
609-645-4480.

-----------[000229][next][prev][last][first]----------------------------------------------------
Date:      22 Sep 89 21:04:58 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  XNS / TCP gateway??

(You're not going to like this...)

What you need is something in the category, called "application gateway".  You
do not simply need translation between the transport-and-below lower layers,
but rather have a difference at every level, except perhaps media.  Hence, you
need to translate every layer.  In reality, this means that you need something
that is "dual stack" running both ENTIRE sets of protocols and a translation
device in between.  For software application gateways, this normally means a single
application, running on top of the two transport stacks, where the application
does BOTH application protocols and translates between them.

In this particular case, there is a different solution.  It is the part you might
not like:

Take one XNS-based terminal server and one TCP-based terminal server and back
them up to each other.  Connect the serial ports.  Play with it until the 
configurations are right.

You now have a terminal protocol translator.

Dave

-----------[000230][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 89 19:01:24 GMT
From:      qureshi@WSU-ENG.ENG.WAYNE.EDU (Imran U. Qureshi 7-0108)
To:        comp.protocols.tcp-ip
Subject:   refernces for recently published papers on tcp/ip.

Does any one know of any recently published papers on tcp/ip.
I need some references (1988 -1989).

Thanx in advance.
qureshi@wsu-eng.eng.wayne.edu

-----------[000231][next][prev][last][first]----------------------------------------------------
Date:      23 Sep 89 19:18:37 GMT
From:      mar@bridge2.ESD.3Com.COM (George Marshall)
To:        comp.protocols.tcp-ip
Subject:   Re: Bridge Communications

In article <16330@netsys.netsys.COM> len@netsys.COM (Len Rose) writes:
>
> Hi.. I need a current telephone number for Bridge Communications,
> they used to be in Cupertino,Ca.. I tried directory assistance of
> course, but there was no listing.. 

Bridge Communications merged with 3Com a while back, and the new company
is called 3Com, so that's why you couldn't find them in the phone book.
The line pf networking products, such as the communications servers you
mentioned, are still offered by 3Com.  Call 800-NET-3COM (800-638-3266) to
get in touch with them.

George Marshall

-----------[000232][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 89 02:03:33 GMT
From:      len@netsys.netsys.COM (Len Rose)
To:        comp.protocols.tcp-ip
Subject:   Bridge/3com CS 1 and CS100 servers

I'm wondering if anyone out there is still using this equipment.
If so, I'd like to hear from you.. Not getting alot of help from
local 3com reps..Need to compare some configuration information.

Thanks.

-----------[000233][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 1989 12:22-EDT
From:      CERF@A.ISI.EDU
To:        ccicpg!taurus!capone!jk@UUNET.UU.NET
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: TCP/IP and OSI over FDDI
John,

I am extremely interested in multiprotocol methods -
please let me know what you turn up on FDDI.

Vint Cerf
-----------[000234][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 1989 12:26-EDT
From:      CERF@A.ISI.EDU
To:        mlaufer@CCT.BBN.COM
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: PC X.25 boards?
Michael,

There is a Canadian outfit called EIKON, Inc. which is based
in Ottawa, I think (or perhaps Toronto), which makes such a board.
I am sorry I don't have the address/phone - it was about 4-5 years
ago that I looked into this. They may be out of business, for all I
know today.

Vint
-----------[000235][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 1989 13:22-EDT
From:      CERF@A.ISI.EDU
To:        holleran@APPLE.COM
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Remote database services ???
Pat,

In principle, your view ought to be an easy one to support, but
access, usage and interconnection policy is complicated by the
fact that the Internet is, in many parts, subsidized by the U.S.
Government.  As a consequence, agencies who provide
infrastructure support have a fiscal responsibility to be sure
that the infrastructure resources are not abused for personal or
corporate gain.

The informal Federal Research Internet Coordinating Committee
(FRICC) members are working on policy statements to help guide us
(users and servers) in this matter.  As an example, it has been
permitted to put up links to commercial email carriers (such as
MCI Mail and CompuServe) as long as the carrier does not charge
the government for emitting traffic from the Internet into the
carrier's network.  The carrier is free to charge its users for
sending mail into the Internet.

The National Research and Education Network (NREN) is intended to
succeed the current Internet on a larger scale in size and in
capacity (eventually reaching 3 gigabits/sec on its trunk links
and capable of supporting as much as a gigabit between pairs of
hosts that need this kind of bandwidth).  It is the hope of the
NREN sponsors that the system will eventually be feasible as a
commercial offering and that direct government involvement in its
operation can be minimized and perhaps completely eliminated.

Finding suitable conditions under which commercial services can
be made accessible to the Internet community is of real interest.

Vint Cerf
-----------[000236][next][prev][last][first]----------------------------------------------------
Date:      Sun, 24 Sep 89  15:58:40 EDT
From:      "Roger Fajman" <RAF%NIHCU.BITNET@CORNELLC.cit.cornell.edu>
To:        netsys!len@decuac.dec.com
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re:  Bridge/3com CS 1 and CS100 servers
> I'm wondering if anyone out there is still using this equipment.
> If so, I'd like to hear from you.. Not getting alot of help from
> local 3com reps..Need to compare some configuration information.

There's a mailing list for 3Com/Bridge equipment.  It's called
bridge-talk@nisca.ircc.ohio-state.edu.
-----------[000237][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 89 16:22:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: TCP/IP and OSI over FDDI

John,

I am extremely interested in multiprotocol methods -
please let me know what you turn up on FDDI.

Vint Cerf

-----------[000238][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 89 16:26:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: PC X.25 boards?

Michael,

There is a Canadian outfit called EIKON, Inc. which is based
in Ottawa, I think (or perhaps Toronto), which makes such a board.
I am sorry I don't have the address/phone - it was about 4-5 years
ago that I looked into this. They may be out of business, for all I
know today.

Vint

-----------[000239][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 89 17:22:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Remote database services ???

Pat,

In principle, your view ought to be an easy one to support, but
access, usage and interconnection policy is complicated by the
fact that the Internet is, in many parts, subsidized by the U.S.
Government.  As a consequence, agencies who provide
infrastructure support have a fiscal responsibility to be sure
that the infrastructure resources are not abused for personal or
corporate gain.

The informal Federal Research Internet Coordinating Committee
(FRICC) members are working on policy statements to help guide us
(users and servers) in this matter.  As an example, it has been
permitted to put up links to commercial email carriers (such as
MCI Mail and CompuServe) as long as the carrier does not charge
the government for emitting traffic from the Internet into the
carrier's network.  The carrier is free to charge its users for
sending mail into the Internet.

The National Research and Education Network (NREN) is intended to
succeed the current Internet on a larger scale in size and in
capacity (eventually reaching 3 gigabits/sec on its trunk links
and capable of supporting as much as a gigabit between pairs of
hosts that need this kind of bandwidth).  It is the hope of the
NREN sponsors that the system will eventually be feasible as a
commercial offering and that direct government involvement in its
operation can be minimized and perhaps completely eliminated.

Finding suitable conditions under which commercial services can
be made accessible to the Internet community is of real interest.

Vint Cerf

-----------[000240][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 89 18:59:50 GMT
From:      jqj@RT-JQJ.STANFORD.EDU (JQ Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re:  XNS / TCP gateway??

As Dave Crocker points out, the safest way to get the remote terminal
applications gateway you want is to put 2 terminal servers back to
back.  However, if you can get documentation on the XNS terminal
protocol, you could also consider using a 4.3BSD system as the
applications gateway.

The problem here is that XNS is well defined up through transport, but
above that each vendor has added its own suite of protocols.  Xerox,
for example, has an RPC system called Courier built on SPP (the
reliable transport protocol that is the top of the traditional XNS
stack).  On Courier, Xerox has built many applications including a
remote terminal protocol.  Several years ago at Cornell, I built a
remote terminal applications gateway running on a BSD system that used
the XNS support in 4.3BSD, and hooked together a TCP telnet client
(server) to an xnschat server (client) to provide exactly the kind of
gateway you envisage.  Unfortunately, that's for only *one* flavor of
XNS-based remote terminal protocol, not yours!

Although TCP/IP has not been very successful at being chosen as the
native protocol for LAN operating systems, it has been far more
successful than XNS in achieving multi-vendor interoperability.


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

-----------[000241][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 89 19:58:40 GMT
From:      RAF@NIHCU.BITNET ("Roger Fajman")
To:        comp.protocols.tcp-ip
Subject:   Re:  Bridge/3com CS 1 and CS100 servers

> I'm wondering if anyone out there is still using this equipment.
> If so, I'd like to hear from you.. Not getting alot of help from
> local 3com reps..Need to compare some configuration information.

There's a mailing list for 3Com/Bridge equipment.  It's called
bridge-talk@nisca.ircc.ohio-state.edu.

-----------[000242][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 89 21:04:39 GMT
From:      umbaugh@uvax (David Umbaugh)
To:        comp.protocols.tcp-ip
Subject:   Bridge/3com CS 1 and CS100 servers

in message <16420@netsys.netsys.COM> you say,
   Date: 24 Sep 89 02:03:33 GMT
   From: netsys!len@decuac.dec.com  (Len Rose)
   Organization: Netsys,Inc.
   Sender: tcp-ip-relay@NIC.DDN.MIL

   I'm wondering if anyone out there is still using this equipment.
   If so, I'd like to hear from you.. Not getting alot of help from
   local 3com reps..Need to compare some configuration information.

   Thanks.



We are using some of that here at UTexas at Arlington.  Bill Riess is
our resident expert.  You should be able to reach him at 
<riess@evax.arl.utexas.edu>  129.107.2.1
	Dave Umbaugh

-----------[000243][next][prev][last][first]----------------------------------------------------
Date:      24 Sep 89 23:04:58 GMT
From:      mshiels@tmsoft.uucp (Michael A. Shiels)
To:        comp.protocols.tcp-ip
Subject:   Re: PC X.25 boards?

The company in Ottawa Canada is Eicon and they have an EXCELLENT implementation
of an X.25 card.  The API is based upon Netbios which means that your software
doesn't have to poll the card for input waiting etc.  It will tell you!

-----------[000244][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 89 01:29:19 GMT
From:      hwajin@wrs.wrs.com (Hwajin Bae)
To:        comp.unix.questions,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: How to handle connection time outs + host address compatibility ...

If your network is extremely congested and packets are not getting through
there is really no way to prevent ETIMEOUT errors from happening after a lot of
failed retransmissions.  Using KEEP_ALIVE will probably make this worse in you 
case since it will generate more packet transmissions and the KEEP_ALIVE timer
can also generate ETIMEOUT error when it expires.  However, EADDRINUSE
error is mainly due to the fact that your side of the connection has been
just dropped and the kernel socket data structure has not yet been freed up.
In order to get around this you can use REUSEADDR option on the socket
so that the bind call will not return EADDRINUSE error.  Pretty much the only
thing you can do when the connection is reset by the peer is to try to
re-establish the connection.

The gethostid() returns unique ID that is not necessarily related to the
Internet address of your machine (in fact, some implementations return magic
machine ID encoded in PROM's).  Internet addresses in their usual unsigned
long representations need not be converted using htonl() in general since
they are assumed to be always represented in big endian format.  The port
numbers to need to be converted using htonl() when connecting to the remote
machine.

-- 
Hwajin Bae
Wind River Systems, Emeryville, CA

-----------[000245][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 89 01:32:04 GMT
From:      hwajin@wrs.wrs.com (Hwajin Bae)
To:        comp.unix.questions,comp.protocols.tcp-ip,comp.unix.wizards
Subject:   Re: How to handle connection time outs + host address compatibility ...

In article <764@wrs.wrs.com> hwajin@wrs.wrs.com (Hwajin Bae) writes:
>numbers to need to be converted using htonl() when connecting to the remote

I meant to say htons() instead of htonl() here.
-- 
Hwajin Bae
Wind River Systems, Emeryville, CA

-----------[000246][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 89 01:44:40 GMT
From:      philf@xymox.metaphor.com (Phil Fernandez)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote database services ???

In article <34890@Apple.COM> holleran@Apple.COM (Patrick Holleran) writes:
>In article <8079@oregon.uoregon.edu> dsmith@oregon.uoregon.edu (Dale Smith) writes:
>>...
>>One service I can think of that would generate a lot of interest amoung
>>researchers here at the University of Oregon (and, I suppose, other
>>sites as well) would be access to remote database services.  I am
>>thinking of pay-for data base services such as BRS, DIALOG, and STN that
>>provide access to hundreds of diverse databases, including Chem
>>Abstracts, Nuclear Science Abstracts, Biosis Previews, Medline, Geobase,
>>Socialogical Abstracts, and Water Resources Abstracts to name a few. 
>...

At my previous job, I built just such a facility at Stanford
University.  Specifically, I built a gateway between the Stanford
University Network (SUNet) and BRS.  Since SUNet is a well-connected
part of the Internet, this service is in-theory available to the full
Internet community (e.g., for demo purposes), although Stanford
definitely does not see itself providing this service on a production
basis beyond Stanford.

From a technical point of view, we used a Develcon TCP/IP to X.25/X.29
device to gateway between SUNet and BRS.  The Develcon box accepts
Telnet connections and cross-connects them to its X.25 PAD function.
Stanford then connects directly to BRS via a 3002 leased line using
19.2kbps modems.

From a management point of view, the Stanford Lane Medical Library
purchased a block of 1000 logon id's from BRS, and "resold" these id's
at nominal cost to faculty and researchers at Stanford.

This service has been in operation at Stanford for almost two years,
and has been fairly successful.  When I left Stanford, we were
considering a similar arrangement with Dialog.

Clearly it is 100% feasible to provide such a capability on the
Internet, although I'd question whether it should be an
internet-general function vs. a locally-provided and managed service.

I'd be glad to provide more information if anyone want to contact me.

phil




+-----------------------------+----------------------------------------------+
| Phil Fernandez              |             philf@metaphor.com               |
|                             |     ...!{apple|decwrl}!metaphor!philf        |
| Metaphor Computer Systems   |"Does the body rule the mind, or does the mind|
| Mountain View, CA           | rule the body?  I dunno..." - Morrissey      |
+-----------------------------+----------------------------------------------+

-----------[000247][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 89 04:41:43 GMT
From:      robert@peregrine.peregrine.com (Robert Young)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Re: TCP/IP over SNA

In article <1079@ks.UUCP> drake@ibmarc.UUCP (Sam Drake) writes:
>This isn't a commercial, but ...
>
>IBM's VM and MVS TCP/IP products can transport TCP/IP over SNA networks,
>and there's a PRPQ available from IBM to allow the RT to do the same.
>
>Sam Drake / IBM Almaden Research Center 

I have a Sequent system (S81) connected to our 4381 mainframe through
SNA. We have already purchased the TCP/IP tapes from IBM but are waiting
for a hardware solution to connect the two systems. Initially, someone in
technical marketing (IBM) suggested we use an RT and a token-ring to
ethernet router but the idea never cooked. Now they are suggesting some
type of channel attached device (Ethernet) to connect the two systems.
Any ideas, suggestions and/or comments?

So far it looks like the IBM people we deal with are not completely sure
about any clear solutions.

Any clues would really be appreciated.

Robert Young
Peregrine Systems

-----------[000248][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 89 07:16:52 GMT
From:      sl@van-bc.UUCP (Stuart Lynne)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote database services ???

In article <[A.ISI.EDU]24-Sep-89.13:22:03.CERF> CERF@A.ISI.EDU writes:
>Pat,
>hosts that need this kind of bandwidth).  It is the hope of the
>NREN sponsors that the system will eventually be feasible as a
>commercial offering and that direct government involvement in its
>operation can be minimized and perhaps completely eliminated.

Wonder how long until the Internet turns into a commercial common carrier? I
can only hope as a international user that when (and if) it happens that
it's trans-national in scope. I'd hate to have to deal with bureaucrats in
Ontario (Canadian bureaucrats have to be seen to be believed!).

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

-----------[000249][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Sep 89 15:31:21 PDT
From:      cire|eric <cire@cisco.com>
To:        tcp-ip@nic.ddn.mil
Subject:   Token Ring BOF at Interop

There has been some interest in discussing the problems associated
with interconnecting Token Rings and Ethernets.  This problem arises
because of the differing bit transmission orders that exist for
these media.  Note that this also a problem for FDDI/Ethernet.

This has ramifications on both routable protocols and bridging.

I will be hosting a BOF to discuss this problem and possible
solutions at the upcoming Interop.  I'd like to get some idea
of how much interest there is in people attending.  If you are
planning on coming could you please email me your name, email
address, and a brief description of your interest.  Or just
send me you name/email address if you are too busy.

Here is a brief description of the BOF:


BOF Title:

	    Token Ring/Ethernet bit ordering Addressing Issues


Description:

Token Ring and FDDI transmit high order bit first while Ethernet/802.3
hardware transmit low order bit first.  This coupled with the common
addressing space causes significant problems when these diverse mediums
are interconnected.  This is especially true for bridging.  The purpose
of this BOF is to discuss this problem, present several potential
solutions, and to explore additional solutions.

Time and Place:  Interop '89, Thursday Oct 5, 6-8pm,  C-4
	* This time and place are tentative and subject to change.
	  Be sure to check the current schedule when it is published.



thanks,

-c
cire|eric

Eric B. Decker
Token Ring Development
cisco Systems - engineering
Menlo Park, California

email:	cire@cisco.com
uSnail: 1360 Willow Rd.,  Menlo Park, CA  94025
Phone : (415) 326-1941
-----------[000250][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 1989 12:46:34 EDT
From:      COINS@A.ISI.EDU
To:        TCP-IP@NIC.DDN.MIL
Cc:        COINS@A.ISI.EDU
Subject:   TN3270
HELP
      LOOKING FOR TN3270 SOURCE CODE WHICH WILL RUN ON A VAX
OR A PDP1170, HOW ABOUT ANYTHING IN "C".

THANK YOU
LYNN
-------
-----------[000251][next][prev][last][first]----------------------------------------------------
Date:      Mon, 25 Sep 89 16:13:01 EDT
From:      Michael Laufer <mlaufer@cct.bbn.com>
To:        tcp-ip@nic.ddn.mil
Cc:        mlaufer@cct.bbn.com
Subject:   PC X.25 boards Summary
I would like to thank all the people who answered my inquiry about X.25 boards
for PC/AT machines.  I should have added that I need a board that works with
MS-DOS (not Unix) with the TCP protocol suite.  The following is a summary of
the information I received:

-----------------------------------------------------------------------------
-myl-
Frontier Technology Milwaukee Wisc. (414) 964-8689.  Dr. Prakash president.

MS-DOS  X.25 board.  TCP module with FTP, TELNET, and SMTP.
Access to raw X.25 and raw TCP.
Board is DDN Certified.  TCP is DDN certified.  Blacker certified.
Did not inquire about Unix.
-----------------------------------------------------------------------------
-myl-
Scope Inc. Reston VA. (703) 471-5600  George Semancik
MS-DOS DDN certified PC/AT board.  Software by FTP Software Inc.
Scope has discontinued its DDN certified MicroGateway product line.  They are
looking to sell it if someone is interested.
-----------------------------------------------------------------------------
From: cmills.bbn.com

Adax Inc. (415) 548-7047  630 Bankroft Way Berkeley CA. 94710

-myl-
Unix only.  TCP suite DDN certified.  Can support 2 simultaneous connection of
56 Kbs..
-----------------------------------------------------------------------------
From: cmills.bbn.com

Gateway Communication  2941 Alton Ave. Irvine CA. 92714 (714) 553-1555

-myl-
Raw X.25 only.
-----------------------------------------------------------------------------
From: cmills.bbn.com

ACC (805) 963-9431

-myl-
Vaxes only.  VMS
-----------------------------------------------------------------------------
From: cmills.bbn.com

Retix (213) 399-2200

-myl-
Raw X.25 and OSI protocols (levels 1/2/3) only.
-----------------------------------------------------------------------------
From: eric@terminus.UMD.EDU

About a year ago I wrote a driver for the Western Digital x.25 PC board
WD4025a.  They run about $300, the software that is distributed with it
is not real useful -- that's why I had to write my own.

-myl-
Novell Network X.25 only.
-----------------------------------------------------------------------------
From: ken@gatech.edu (Ken Seefried III)

Check out The Software Group in Canada.  Don't have the address or phone
number right here, but they have ads in Unix Review, etc. most months.

They have a good product and they are a pleasure to deal with...

From: dialogic!drich@uunet.UU.NET (Dan Rich)

The Software Group Ltd.			X.25, TCP/IP, NETCOM II
2 Director Court, Suite 201		Products for:
Woodbridge, Ontario, Canada L4L3Z5	XENIX 386, UNIX 386
     (416) 856-0238
Fax: (416) 856-0242
Usenet: uunet!tsgfred!netcom2

-myl-
Unix only.
-----------------------------------------------------------------------------
From: thinman@cup.portal.com: 415-659-1450

Streamlined Networks has a 386/unix
TCP/IP implementation for UNIX and XENIX on 386's.
We've got a driver for an X.25 card from The Software Group in Toronto, Canada.
Their stuff works on the U.S., Canada, Japanese, and German public networks.
Supposedly this means it should be easy to certify for the DDN.

Lance Norskog

-myl-
Unix only.
-----------------------------------------------------------------------------
From: dialogic!drich@uunet.UU.NET (Dan Rich)

Rabbit Software				Rabbit hardware X.25/NETCOM II
7 Great Valley Parkway East
Malvern, PA 19355
     (215) 647-0440
Fax: (215) 640-1379

-myl-
No MS-DOS or Unix.  QLLC interface ????
-----------------------------------------------------------------------------
From: dialogic!drich@uunet.UU.NET (Dan Rich)

Systems Strategies Inc.			Mostly IBM comm.
225 West 34th Street
New York, NY 10001
     (212) 279-8400
Fax: (212) 967-8368

From: thinman@cup.portal.com: 415-659-1450

System Strategies (NY NY) supposedly has a DDN-certified X.25 card, too.
Marv Friedman is their president, Nynex owns the whole damn company.
SS mostly does IBM SNA synchronous cards.

Lance Norskog

-myl-
Unix only.
-----------------------------------------------------------------------------
From: "Shawn R. Campbell" <srcampb%anagld.uucp@BBN.COM>

You might want to check Communication Machinary Corporation (CMC)
out of Santa Barbara, California.  They make a variety of TCP/IP boards
for VME, Multi, and AT bus platforms.  At my prior company, I worked
quite extensively with their ENP-30 which is a Multibus, 802.3 and
X.25 intelligent network card that included TCP/IP.  Their applications
had to be ported to a Xenix operating system, but they do provide all
TCP protocol suite applications including SMTP with the board.
I had a lot of problems with their X.25 software, but I believe
it works fine now.

-myl-
No board level product (MS-DOS or Unix)
-----------------------------------------------------------------------------
From: douglas%twg-ap.uucp@BBN.COM

Eicon Technology of Montreal, Canada makes X.25 cards for
PC's.   Wollongong's WIN/TCP for 386 STREAMS Release 3.1
(for 386 AT sysems running UNIX System V/386 Release 3.2)
supports their EiconCards.  Eicon can be reached at 
514-631-2592.

From: "Michael A. Shiels" <mailrus!jarvis.csri.toronto.edu!torsqnt!tmsoft!mshiels@tut.cis.ohio-state.edu>

The company in Ottawa Canada is Eicon and they have an EXCELLENT implementation
of an X.25 card.  The API is based upon Netbios which means that your software
doesn't have to poll the card for input waiting etc.  It will tell you!

From: CERF@A.ISI.EDU

There is a Canadian outfit called EIKON, Inc. which is based
in Ottawa, I think (or perhaps Toronto), which makes such a board.
I am sorry I don't have the address/phone - it was about 4-5 years
ago that I looked into this. They may be out of business, for all I
know today.

-myl-
Raw X.25 only for MS-DOS.  IP router with streams interface for Unix.
-----------------------------------------------------------------------------
From:???

DCA. IRMA board  (800) 241-IRMA (4762)

-myl-
Raw X.25 only.  No sales in the US.  Europe only.
-----------------------------------------------------------------------------

Michael Laufer      BBN Communications Corporation
internet:   mlaufer@bbn.com
phone:      (301) 290-5000
USMAIL:     9810 Patuxent Woods Drive, Columbia, MD 21046
-----------[000252][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 89 12:38:26 GMT
From:      "Juan_Navarro.XOSMAR"@XEROX.COM
To:        comp.protocols.tcp-ip
Subject:   Re: XNS / TCP gateway??


Xerox has a TCP/XNS gateway available that supports telnet, smtp and ftp.
The gateway also supports name servers, host table addressing, mx domains
and ip routers.  This may not be exactly what you need though, since the
gateway must be on the same e-net as both the TCP and XNS hosts.  Your
diagram appears to require some type of router in between these the
different nets.

If you need more information, drop me a line or call.


-------------------------------------------------------------------------
Juan Navarro - Xerox Federal Goverment Operations (703) 247-6429

-----------[000253][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 89 15:36:40 GMT
From:      meissner@tiktok.dg.com (Michael Meissner)
To:        comp.protocols.tcp-ip
Subject:   Re: UUCP --> FTP

In article <8723@galbp.LBP.HARRIS.COM> mhw@wittsend.UUCP (Michael H. Warfield (Mike)) writes:
| In article <89258.213225CMH117@PSUVM.BITNET> CMH117@PSUVM.BITNET writes:
| >I need to download files from a machine running strictly UUCP to a machine
| >running only FTP.  I've heard that this is impossible.
| 
| 	No.  This is possible but only if you have access to another machine
| somewhere in the middle that can play both games.  Out here in UUCP land our
| problem is generally the reverse, where we want to get something from an FTP
| only site.  That requires something fancy like a LISTSERV system.
| 
| 	If you mean downloading directly with no help in-between from
| another system, you are out of luck.  If it's not something gigantic and
| your uucp/internet neighbors don't object (CHECK!!) have the uucp site
| encode it and mail it to you.  If it's an autonomous archive site, wwwweeeellll
| so much for that idea.

If you are a customer of uunet, they offer a service where they will
FTP files upon request and uucp them to you.  I've used it several
times recently with good results.  If the files you want to get are
freely redistributable, it's also possible that it already exists on
uunet's and/or Ohio State's archives.
--
Michael Meissner, Data General.
Uucp:		...!mcnc!rti!xyzzy!meissner		If compiles were much
Internet:	meissner@dg-rtp.DG.COM			faster, when would we
Old Internet:	meissner%dg-rtp.DG.COM@relay.cs.net	have time for netnews?

-----------[000254][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 89 16:21:31 GMT
From:      sharon@asylum.SF.CA.US (Sharon Fisher)
To:        comp.protocols.tcp-ip
Subject:   Re: PC X.25 boards?

In article <[A.ISI.EDU]24-Sep-89.12:26:22.CERF> CERF@A.ISI.EDU writes:
>Michael,
>
>There is a Canadian outfit called EIKON, Inc. which is based
>in Ottawa, I think (or perhaps Toronto), which makes such a board.
>I am sorry I don't have the address/phone - it was about 4-5 years
>ago that I looked into this. They may be out of business, for all I
>know today.

I think you're talking about Eicot Technologies.  I thought they were
in Montreal, but I could be wrong.  I have their cards at home and
will look up the number.



-- 
"Girl?! Don't you call *me* 'Girl'! I got a foot of cunt, a number two 
washtub full of tit, and enough hair on my pussy to weave an Indian 
blanket, and you call me 'Girl'???             
                     paraphrased from "Texas Crude:  
                     The How-to on Talkin' Texan," by Ken Weaver.

-----------[000255][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 89 16:46:34 GMT
From:      COINS@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   TN3270

HELP
      LOOKING FOR TN3270 SOURCE CODE WHICH WILL RUN ON A VAX
OR A PDP1170, HOW ABOUT ANYTHING IN "C".

THANK YOU
LYNN
-------

-----------[000256][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 89 17:19:54 GMT
From:      jehics@ultb.UUCP (J.E. Eliotis)
To:        comp.sys.att,comp.protocols.tcp-ip
Subject:   Looking for info on SL/IP

I have bought the Lachman Streams TCP/IP package for my AT&T 6386 box.  It
contains a device /dev/slip.  I would like to believe that this stands for
Serial Line Internet Protocol, i.e., IP over an RS232 line.  Does anyone
know anything about it?  If it works, how do I make it work?

				Jim Heliotis
				{allegra,seismo}!rochester!ritcv!jeh
				ritcv!jeh@CS.Rochester.EDU
				jeh@CS.RIT.EDU

-----------[000257][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 89 17:22:49 GMT
From:      steve@NOTE.NSF.GOV (Stephen Wolff)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote database services ???


>>hosts that need this kind of bandwidth).  It is the hope of the
>>NREN sponsors that the system will eventually be feasible as a
>>commercial offering and that direct government involvement in its
>>operation can be minimized and perhaps completely eliminated.
>
>Wonder how long until the Internet turns into a commercial common carrier?

Large chunks of the Internet are already commercial.  Mid-level (e.g.,
regional) networks in the NSFNET family are independent business entities
which however receive Federal subsidy in two forms: annual awards (ranging in
amount from almost none to "some") from the Networking Division at NSF, and
no-direct-charge use of the NSFNET backbone network for long-haul transit.

The NSFNET Backbone is in turn operated by a commercial organization which is
fully subsidized - in part by NSF but mostly by private industry.

Beyond their subsidy, the mid-level nets get income by charging their client
campus networks for services rendered.  (Just as in the case of Plain Old
Telephone Service, the campus is ordinarily the smallest billable unit.)

The technical problem for the Federal government is how to move the subsidies
which are now given to the SUPPLIERS of networking services, instead to the
USERS of networking through the standard mechanisms of research grants and
contracts and increments on the indirect cost rate - all without damaging,
diminishing or interrupting the service to the research and scholarly
communities.

Over the course of the coming year, NSF - in its role as lead agency for
implementing the Phase 1+2 NREN - will collaborate with the nascent NREN
management and advisory groups in holding public discussions of this
important topic.  Stay tuned.

-s

-----------[000258][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 89 19:54:35 GMT
From:      evan@BRAZOS.RICE.EDU (Evan Wetstone)
To:        comp.protocols.tcp-ip
Subject:   Traceroute under SunOS 4.0.3?

Has anyone out there installed traceroute on a Sun3 running SunOS 4.0.3?
We don't currently have a source license, so I am wondering if there is an
easy way to perform the kernel mods that the README states are necessary.

Any and all information will be greatly appreciated.

Thanks,

Evan Wetstone				    Internet:  evan@rice.edu
Network & Systems Support		      Bitnet:  evan@ricevm1
Rice University, Houston TX			uucp:  rice!evan

-----------[000259][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 89 20:13:01 GMT
From:      mlaufer@CCT.BBN.COM (Michael Laufer)
To:        comp.protocols.tcp-ip
Subject:   PC X.25 boards Summary

I would like to thank all the people who answered my inquiry about X.25 boards
for PC/AT machines.  I should have added that I need a board that works with
MS-DOS (not Unix) with the TCP protocol suite.  The following is a summary of
the information I received:

-----------------------------------------------------------------------------
-myl-
Frontier Technology Milwaukee Wisc. (414) 964-8689.  Dr. Prakash president.

MS-DOS  X.25 board.  TCP module with FTP, TELNET, and SMTP.
Access to raw X.25 and raw TCP.
Board is DDN Certified.  TCP is DDN certified.  Blacker certified.
Did not inquire about Unix.
-----------------------------------------------------------------------------
-myl-
Scope Inc. Reston VA. (703) 471-5600  George Semancik
MS-DOS DDN certified PC/AT board.  Software by FTP Software Inc.
Scope has discontinued its DDN certified MicroGateway product line.  They are
looking to sell it if someone is interested.
-----------------------------------------------------------------------------
From: cmills.bbn.com

Adax Inc. (415) 548-7047  630 Bankroft Way Berkeley CA. 94710

-myl-
Unix only.  TCP suite DDN certified.  Can support 2 simultaneous connection of
56 Kbs..
-----------------------------------------------------------------------------
From: cmills.bbn.com

Gateway Communication  2941 Alton Ave. Irvine CA. 92714 (714) 553-1555

-myl-
Raw X.25 only.
-----------------------------------------------------------------------------
From: cmills.bbn.com

ACC (805) 963-9431

-myl-
Vaxes only.  VMS
-----------------------------------------------------------------------------
From: cmills.bbn.com

Retix (213) 399-2200

-myl-
Raw X.25 and OSI protocols (levels 1/2/3) only.
-----------------------------------------------------------------------------
From: eric@terminus.UMD.EDU

About a year ago I wrote a driver for the Western Digital x.25 PC board
WD4025a.  They run about $300, the software that is distributed with it
is not real useful -- that's why I had to write my own.

-myl-
Novell Network X.25 only.
-----------------------------------------------------------------------------
From: ken@gatech.edu (Ken Seefried III)

Check out The Software Group in Canada.  Don't have the address or phone
number right here, but they have ads in Unix Review, etc. most months.

They have a good product and they are a pleasure to deal with...

From: dialogic!drich@uunet.UU.NET (Dan Rich)

The Software Group Ltd.			X.25, TCP/IP, NETCOM II
2 Director Court, Suite 201		Products for:
Woodbridge, Ontario, Canada L4L3Z5	XENIX 386, UNIX 386
     (416) 856-0238
Fax: (416) 856-0242
Usenet: uunet!tsgfred!netcom2

-myl-
Unix only.
-----------------------------------------------------------------------------
From: thinman@cup.portal.com: 415-659-1450

Streamlined Networks has a 386/unix
TCP/IP implementation for UNIX and XENIX on 386's.
We've got a driver for an X.25 card from The Software Group in Toronto, Canada.
Their stuff works on the U.S., Canada, Japanese, and German public networks.
Supposedly this means it should be easy to certify for the DDN.

Lance Norskog

-myl-
Unix only.
-----------------------------------------------------------------------------
From: dialogic!drich@uunet.UU.NET (Dan Rich)

Rabbit Software				Rabbit hardware X.25/NETCOM II
7 Great Valley Parkway East
Malvern, PA 19355
     (215) 647-0440
Fax: (215) 640-1379

-myl-
No MS-DOS or Unix.  QLLC interface ????
-----------------------------------------------------------------------------
From: dialogic!drich@uunet.UU.NET (Dan Rich)

Systems Strategies Inc.			Mostly IBM comm.
225 West 34th Street
New York, NY 10001
     (212) 279-8400
Fax: (212) 967-8368

From: thinman@cup.portal.com: 415-659-1450

System Strategies (NY NY) supposedly has a DDN-certified X.25 card, too.
Marv Friedman is their president, Nynex owns the whole damn company.
SS mostly does IBM SNA synchronous cards.

Lance Norskog

-myl-
Unix only.
-----------------------------------------------------------------------------
From: "Shawn R. Campbell" <srcampb%anagld.uucp@BBN.COM>

You might want to check Communication Machinary Corporation (CMC)
out of Santa Barbara, California.  They make a variety of TCP/IP boards
for VME, Multi, and AT bus platforms.  At my prior company, I worked
quite extensively with their ENP-30 which is a Multibus, 802.3 and
X.25 intelligent network card that included TCP/IP.  Their applications
had to be ported to a Xenix operating system, but they do provide all
TCP protocol suite applications including SMTP with the board.
I had a lot of problems with their X.25 software, but I believe
it works fine now.

-myl-
No board level product (MS-DOS or Unix)
-----------------------------------------------------------------------------
From: douglas%twg-ap.uucp@BBN.COM

Eicon Technology of Montreal, Canada makes X.25 cards for
PC's.   Wollongong's WIN/TCP for 386 STREAMS Release 3.1
(for 386 AT sysems running UNIX System V/386 Release 3.2)
supports their EiconCards.  Eicon can be reached at 
514-631-2592.

From: "Michael A. Shiels" <mailrus!jarvis.csri.toronto.edu!torsqnt!tmsoft!mshiels@tut.cis.ohio-state.edu>

The company in Ottawa Canada is Eicon and they have an EXCELLENT implementation
of an X.25 card.  The API is based upon Netbios which means that your software
doesn't have to poll the card for input waiting etc.  It will tell you!

From: CERF@A.ISI.EDU

There is a Canadian outfit called EIKON, Inc. which is based
in Ottawa, I think (or perhaps Toronto), which makes such a board.
I am sorry I don't have the address/phone - it was about 4-5 years
ago that I looked into this. They may be out of business, for all I
know today.

-myl-
Raw X.25 only for MS-DOS.  IP router with streams interface for Unix.
-----------------------------------------------------------------------------
From:???

DCA. IRMA board  (800) 241-IRMA (4762)

-myl-
Raw X.25 only.  No sales in the US.  Europe only.
-----------------------------------------------------------------------------

Michael Laufer      BBN Communications Corporation
internet:   mlaufer@bbn.com
phone:      (301) 290-5000
USMAIL:     9810 Patuxent Woods Drive, Columbia, MD 21046

-----------[000260][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 89 21:15:10 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip,comp.binaries.ibm.pc.d,comp.sys.ibm.pc,comp.graphics
Subject:   grape abandons FTP continuation lines

I run an FTP archive site, grape.ecs.clarkson.edu.  I would like to
keep people appraised of timely information, much as /etc/motd serves
on Unix machines.  The FTP RFC allows for multiple sign-on banner
lines, which would be a great place to announce this information.
Unfortunately, Sun's FTP client gets very, very confused when
confronted with continuation lines.

Moral: Don't use FTP continuation lines in your FTP server unless you
want to make Sun users confused and unhappy.  And when they get
confused they send you mail.  And when you get tired of answering that
mail, you rip the continuation lines out of your code.  And when you
get depressed that the network isn't perfect yet, you post to this
list, looking for a sympathetic ear.  :-(
-- 
--russ (nelson@clutx [.bitnet | .clarkson.edu])
Live up to the light thou hast, and more will be granted thee.

-----------[000261][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 89 22:31:21 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Token Ring BOF at Interop


There has been some interest in discussing the problems associated
with interconnecting Token Rings and Ethernets.  This problem arises
because of the differing bit transmission orders that exist for
these media.  Note that this also a problem for FDDI/Ethernet.

This has ramifications on both routable protocols and bridging.

I will be hosting a BOF to discuss this problem and possible
solutions at the upcoming Interop.  I'd like to get some idea
of how much interest there is in people attending.  If you are
planning on coming could you please email me your name, email
address, and a brief description of your interest.  Or just
send me you name/email address if you are too busy.

Here is a brief description of the BOF:


BOF Title:

	    Token Ring/Ethernet bit ordering Addressing Issues


Description:

Token Ring and FDDI transmit high order bit first while Ethernet/802.3
hardware transmit low order bit first.  This coupled with the common
addressing space causes significant problems when these diverse mediums
are interconnected.  This is especially true for bridging.  The purpose
of this BOF is to discuss this problem, present several potential
solutions, and to explore additional solutions.

Time and Place:  Interop '89, Thursday Oct 5, 6-8pm,  C-4
	* This time and place are tentative and subject to change.
	  Be sure to check the current schedule when it is published.



thanks,

-c
cire|eric

Eric B. Decker
Token Ring Development
cisco Systems - engineering
Menlo Park, California

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

-----------[000262][next][prev][last][first]----------------------------------------------------
Date:      25 Sep 89 23:44:37 GMT
From:      bownesrm@beowulf.UUCP (Mr Mojo Risen')
To:        comp.sources.wanted,comp.protocols.tcp-ip
Subject:   Looking for unix KA9Q


	The archives at beowulf have an older copy of KA9Q that runs
	standalone under Xenix. I'd like the rumored more recent copy
	that connects incoming telnets to logins. If someone could
	arrange to get me a copy, I'd be mighty pleased and would make
	it available via the archives to the rest of the world. Presently,
	I do not have ftp access, so anonymous uucp would be best.

	Thank you,
		Bob Bownes

-- 
"Reading legal mush can turn your brain to guacamole." - Commodore/Amiga Manual
Bob Bownes, aka iii, aka keptin comrade doktor bobwrench
874 Kari Dr, Eau Claire (Oh Claire!) Wisc, 54701 (715)-835-1934 voice
bownesrm@beowulf.uucp {uunet!crdgw1,uunet!ssi}!beowulf!bownesrm

-----------[000263][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 89 00:01:36 GMT
From:      tkevans@fallst.UUCP (Tim Evans)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP in Mixed BSD-Sys V Environment

I'm looking for information about TCP/IP implementations that might
run in a mixed network of VAXen running BSD 4.2, '386 Intels running
SCO Xenix (some version 2.2, some versio 2.3), and '286 AT's running
VentureCom Venix (version 2.2).  (All prior trade names are copyright
by the respective owners.)  The latter is likely to be the big problem,
as this version of Venix has no large-model compiler option and does
shortnames only.

We are currently networked via Ethernet and running an XNS product.
We'd like to join the rest of the world.

Please e-mail, using the path shown below.  Thank you.
-- 
UUCP:		{rutgers|ames|uunet}!mimsy!aplcen!fallst!tkevans
INTERNET:	tkevans%fallst@aplcen.apl.jhu.edu
OTHER: 		...!attmail!fallst!tkevans
Tim Evans  2201 Brookhaven Court, Fallston, MD  21047   (301) 965-3286

-----------[000264][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 89 03:22:27 GMT
From:      glen@aecom.yu.edu (Glen M. Marianko)
To:        comp.protocols.tcp-ip
Subject:   Looking for best TCP/IP for VAX VMS 5

We have VMS 5.1-1 systems that we use in-house for various business/
inventory/billing functions that we would like to add TCP/IP support.
Our systems are a VAX 11/780 w/ UNIBUS and a VAX 6310 w/ BI bus.
Now, for the UNIBUS there are the Interlan and Excelan solutions
(both are software w/ UNIBUS card), and Wollongong which works with
the DELUA card from DEC.  For the 6300 there is probably
only Wollongong, from what I can find (because the BI bus is
proprietary, I guess).

Is there anything I'm missing that's worth considering?

Any comments or testimonials on the aforementioned vendors would be
greatly appreciated.

Many thanks!


-- 

-- Glen M. Marianko, Manager of LAN Support, Glasgal Communications, Inc.
   glen@aecom.yu.edu - {uunet}!aecom!glen (Courtesy of AECOM & unaffiliated)

-----------[000265][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 89 05:19:56 GMT
From:      brian@ucsd.Edu (Brian Kantor)
To:        comp.protocols.tcp-ip,news.software.nntp
Subject:   NNTP BOF at InterOp?

InterOp is about a week away, and it suddenly (duh!) occured to me that
there might be interest in having some sort of NNTP BOF, perhaps to
discuss current problems and future enhancements.

I haven't the foggiest idea of how to go about setting up a BOF, though.

If there's sufficient interest, maybe we can arrange something.  Or all
just meet in the bar.
	- Brian

-----------[000266][next][prev][last][first]----------------------------------------------------
Date:      Tue, 26 Sep 89 15:33:03 PDT
From:      cire|eric <cire@cisco.com>
To:        rlfink@lbl.gov
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Token Ring BOF at Interop

I am now aware of two other BOFs that are at the same time.  With such a
wealth of things to talk about that is bound to happen.  There have been
quite a few people that have already said they would come to the Token 
Ring Addressing BOF and Thursday at 6 is really the best time for my
participation.  So Thursday at 6 it is.

Here are the other ones that I know about:

Token Ring-FDDI/Ethernet Interoperability Addressing Issues (mine)

FDDI MIB

IP over FDDI.  Discussion of RFC 1103.  Is there really things to
discuss here?  I thought that there would be an 802.2 header and
there you go.  (SNAP, etc.)

-c
cisco engineering
-----------[000267][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 89 13:03:24 GMT
From:      goldstei@NSIPO.ARC.NASA.GOV ("Steve Goldstein Ph 202-357-9717")
To:        comp.protocols.tcp-ip
Subject:   Re: New Release of SNMP from CMU (version 1.0)

>>The files in this directory compromise the 1.0 release of the CMU SNMP
distribution.<<

Do they really compromise it?

--SG

-----------[000268][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 89 13:05:53 GMT
From:      marv@NISC.NYSER.NET
To:        comp.protocols.tcp-ip
Subject:   UNINTERRUPTED POWER SUPPLY (UPS) SYSTEMS

HELP.

	LOOKING FOR SOURCES/MANUFACTURERS OF UNINTERRUPTED
POWER SUPPLY (UPS) SYSTEMS FOR NETWORK EQUIPMENT.
Interested in rack mounted UPS in the 500 to 5000 watt
range.

Thanks in advance,

MARV SCHOFFSTALL
NYSERNET, INC
518-283-8860
marv@nisc.nyser.net

-----------[000269][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 89 14:17:07 GMT
From:      rlfink@lbl.gov (Robert L. Fink)
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring BOF at Interop

Eric,

A possible conflict with your proposed BOF is the IP over FDDI BOF to 
discuss RFC1103 that will happen Thursday night from 5-8pm.

Contact is Monica Hart (mhart@nri.reston.va.us).

Bob Fink

-----------[000270][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 89 14:38:13 GMT
From:      chris@SALT.ACC.COM (Chris VandenBerg)
To:        comp.protocols.tcp-ip
Subject:   TEK graphics

Morning all,
		I've heard about Peter DiCamillo's graphics stuff for the MAC
II(which is running with ACCES/MVS) but I was wondering if anyone has done
any work with TEK workstations to get graphics support through TN3270
extended data streaThanks in advance for any info you could pass on(:*))	
				Chris VandenBerg
				chris@salt.acc.com
				805-963-9431

-----------[000271][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 89 15:08:03 GMT
From:      merlin@smu.uucp (David Hayes)
To:        comp.protocols.tcp-ip
Subject:   Re: grape abandons FTP continuation lines

In article <1989Sep25.211510.2383@sun.soe.clarkson.edu> nelson@clutx.clarkson.edu writes:
>Moral: Don't use FTP continuation lines in your FTP server unless you
>want to make Sun users confused and unhappy.  And when they get
>confused they send you mail.  And when you get tired of answering that
>mail, you rip the continuation lines out of your code.  

Or you can use the FTP in accrodance with its protocol specification.
And when the Sun users get confused, and angry, they send you mail.
Bounce the mail to Sun.  Maybe Sun will eventually fix their machines.
I'm not holding my breath, though.

David Hayes	School of Engineering	Southern Methodist University
merlin@smu.edu	uunet!smu!merlin
"Argue for your limitation, and, sure enough, they're yours." - Richard Bach

-----------[000272][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 89 17:28:13 GMT
From:      John_Robert_Breeden@cup.portal.com
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   Re: TCP/IP over SNA

>>This isn't a commercial, but ...
>>
>>IBM's VM and MVS TCP/IP products can transport TCP/IP over SNA networks,
>>and there's a PRPQ available from IBM to allow the RT to do the same.
>>
>>Sam Drake / IBM Almaden Research Center 
>
>I have a Sequent system (S81) connected to our 4381 mainframe through
>SNA. We have already purchased the TCP/IP tapes from IBM but are waiting
>for a hardware solution to connect the two systems. Initially, someone in
>technical marketing (IBM) suggested we use an RT and a token-ring to
>ethernet router but the idea never cooked. Now they are suggesting some
>type of channel attached device (Ethernet) to connect the two systems.
>Any ideas, suggestions and/or comments?
>
>So far it looks like the IBM people we deal with are not completely sure
>about any clear solutions.
>
>Any clues would really be appreciated.
>
>Robert Young
>Peregrine Systems

Anybody had experience with this box? Might it work in this case?

What MITEK provides, is a box which can be either remote or channel attached
to the host, and connected to our TCP network via the usual drop cable and
transceiver.  This box supports up to 64 concurrent login sessions, both
inbound to the mainframe from the 3B2, or OUTBOUND from the mainframe
to the 3b2.  An SNA user looks like a vt100 to the 3b2, and 3b users
look just like an IBM 32xx terminal to VTAM.  File transfer is supported
through FTP, and the MITEK box has complete terminal mapping and pro-
grammable keyboard mapping tables.
 
We are just completing the installation here, and our customer is
very pleased both with the solution (it requires no changes to their
existing network) and with the MITEK support.
 
I am told by MITEK that they will soon (2Q89) be announcing another
MITEK box which will provide the same file transfer and full-screen
terminal session capability for IBM S36/38 systems and TCP/IP.  If
the present is any indicator, this future product should be slick.
MITEK does have regional people scattered around the country, but
your best bet would be to give them a call in Carrollton, and find
out more about it.  I hope this info helps somebody.
 
 
john _robert_breeden@cup.portal.com

-----------[000273][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 89 18:00:42 GMT
From:      PADLIPSKY@A.ISI.EDU (Michael Padlipsky)
To:        comp.protocols.tcp-ip
Subject:   Re: grape abandons FTP continuation lines

I suppose it's completely out of the question to persuade Sun to
conform to the protocol...?  { ~|^ } [*]
   sympathetic [ch]ears, map
__________
[*] New ick-on, signifying raised eyebrow.
-------

-----------[000274][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 89 20:48:07 GMT
From:      karl@asylum.SF.CA.US (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Comment on RFC1124 (?)

RFC1124 came out with a discussion of policy issues of interconnected
networks.  Interesting and important stuff.

Now, it seems, according to RFC1111, that postscript is OK for RFC's,
(including postscript that was obviously generated by a word or text
processor.)

So: can anyone make reasonable comment on stuff that looks like what
follows?  Can anyone do a reasonable machine-based content search?
Can I send it though my automated indexing tools?  Can I make a
nice e-mail reply with appropriate selections for context?

No.

I thought we were working on communications, not obfuscation.

I propose that we ban postscript RFCs.

			--karl--

Selection from RFC1124:

727 789(Computer)U
1039(networking)S
1391(has)S
1511(become)S
1759(pervasive)S
2059(and)S
2187(basic)S
2359(to)S
2439(the)S
2551(conduct)S
2803(of)S
2887(scienti\256c)S
3119 873(,)U
577 957(e)U
577 873(and)U
705(academic)S
1001(activities.)S
1327(To)S
1431(provide)S
1675(the)S
1787(needed)S
2015(networking)S
2367(support)S
2607(to)S
2687(these)S
2859(activities)S
609 957(ach)U
733(of)S
817(the)S
929(agencies)S
1201(funding)S
1449(research)S
1713(has)S
1833(proceeded)S
2153(to)S
2233(establish)S
2509(one)S
2637(or)S
2721(more)S
2893(agency)S
577 1041(funded)U
801(computer)S
1097(networks.)S
727 1149(Recognizing)U
1115(the)S
1227(importance)S
1575(of)S
1659(such)S
1815(networking)S
2167(support,)S
2425(the)S
2537(Of\256ce)S
2741(of)S
2825(Science)S
577 1317(r)U
577 1233(and)U
705(Technology)S
1073(Policy)S
1281(\(OSTP\))S
1529(working)S
1793(with)S
1945(the)S
2057(appropriate)S
2409(personnel)S
2713(from)S
2877(the)S
601 1317(esearch-funding)U
1089(agencies)S
1361(on)S
1457(the)S
1569(Federal)S
1809(Coordinating)S
2213(Council)S
2465(on)S
2561(Science)S
2809(Engineering)S
577 1485(r)U
577 1401(and)U
705(Technology)S
1073(\(FCCSET\))S
1409(Committee)S
1753(on)S
1849(High-Speed)S
2217(Networks)S
2521(developed)S
2841(a)S
2897(set)S
3001(of)S
601 1485(ecommendations)U
1113(for)S
1221(the)S
1333(evolution)S
1629(and)S
1757(enhancements)S
2189(of)S
2273(scienti\256c)S
2557(and)S
2685(academic)S
2961 1569(e)U
577 1653(a)U
577 1569(networks.)U
907(These)S
1103(recommendations)S
1639(are)S
1751(described)S
2051(in)S
2131(three)S
2299(phases.)S
2557(The)S
2693(\256rst)S
2829(phas)S

-----------[000275][next][prev][last][first]----------------------------------------------------
Date:      26 Sep 89 22:33:03 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring BOF at Interop


I am now aware of two other BOFs that are at the same time.  With such a
wealth of things to talk about that is bound to happen.  There have been
quite a few people that have already said they would come to the Token 
Ring Addressing BOF and Thursday at 6 is really the best time for my
participation.  So Thursday at 6 it is.

Here are the other ones that I know about:

Token Ring-FDDI/Ethernet Interoperability Addressing Issues (mine)

FDDI MIB

IP over FDDI.  Discussion of RFC 1103.  Is there really things to
discuss here?  I thought that there would be an 802.2 header and
there you go.  (SNAP, etc.)

-c
cisco engineering

-----------[000276][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Sep 89 09:08:50 PDT
From:      cire|eric <cire@cisco.com>
To:        Dave_Katz@um.cc.umich.edu, ddp+@andrew.cmu.edu
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re: Token Ring BOF at Interop

Well this is getting weird.  I just checked with the Interop BOF
coordinator and there isn't a IP over FDDI BOF scheduled at all let
alone at Thursday 6-8.  There is one on FDDI management with is the
FDDI MIB one.  I checked for the entire week and there isn't anything
at all close to describing it.

Now there are several options here and I think we should organize them
to maximize our coverage.  There has been significant interest (yes I
know actual attendence remains to be seen) in the TR-FDDI/Ethernet
addressing BOF.  There is also significant interest in the IP over FDDI
and other issues BOF.

I'd like to see us arrange things so that these sessions don't overlap
too badly.  One option is back to back but perhaps that is too brutal
especially for the east coast types.  We could also say have one
on Tuesday from 6-8 and the other one on Thursday.

Right now I still have Thursday 6-8 but I'm certainly willing to work
with the community on this.  Either way we need to do this soon.  Today
would be ideal.

Thoughts,

-c
-----------[000277][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 03:56:46 GMT
From:      Dave_Katz@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring BOF at Interop

There is significant overlap between the FDDI and the TR stuff, 
especially with regard to transparent bridging.  FDDI is in
much better shape because it doesn't have an installed customer
base.
 
I will have to be at the FDDI BOF, given that I wrote 1103.
 

-----------[000278][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 04:45:23 GMT
From:      peter@hadrian.uwo.ca (Peter Marshall)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote database services ???

In article <801@metaphor.Metaphor.COM> philf@xymox.metaphor.com (Phil Fernandez) writes:

[Stuff about Stanford's Internet to BRS connection deleted]

   Clearly it is 100% feasible to provide such a capability on the
   Internet, although I'd question whether it should be an
   internet-general function vs. a locally-provided and managed service.

The problem with making it a locally-provided service is that you are
not taking advantage of the high-speed shared cross-country links like
those provided by NSFnet.  This doesn't matter too much when the
database is fairly local, but if your database is on the west coast
and you are on the east it would be a shame to have to do the
long-haul traffic on a special, dedicated (single point of failure,
self managed...) link from your site to the west coast database when
there is a functioning (and professionally managed) internet already
in place.

I think that it would make sense to cooperatively fund high-speed
connections from the Internet to database resources like BRS and
Dialog.  Perhaps the database suppliers would even be willing to
attach a sur-charge to such connections and return this money to the
agency that is making the connection.  The databases could probably
recover their own connection charges through their normal recovery
mechanisms from individual account holders.

Once on the Internet they could explore other, perhaps more productive
means of accessing their databases that are not based on the
time-sharing terminal paradigm: TCP packets may be much more suitable
for a SQL type query than a terminal type connection.  Of course this
course precludes using the type of virtual terminal only connection
that seems to be implemented at Stanford.

--
--
Peter Marshall, Data Comm. Manager
CCS, U. of Western Ontario, London, Canada N6A 5B7
(519)661-2111x6032 or 661-2151 to leave a message 
peter.marshall@uwo.ca pm@uwovax (BITNET); peter@julian.uucp

-----------[000279][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 10:28:00 EST
From:      <afrlinkv@wpafb-info5.af.mil>
To:        "tcp-ip" <tcp-ip@nic.ddn.mil>
Subject:   RFC Compliant NetBIOS & ULANA
Maybe someone out there in the Internet can provide some insight...    
 
1)  Is there any reason whatsoever (one word?) to use an RFC 1001,1002 
compliant NetBIOS?  Sure, it means you're in tune with the DoD guidance
to use TCP/IP, but you still can't talk on the Internet - that is all 
current implementations of RFC compliant NetBIOS implement the Broadcast 
Nodes method and are delimited by their IP routers (Gateways).  This 
means you're buying more expensive hardware or using lots of host (PC) 
memory and receiving poorer performance because of the protocol overhead.     
 
2)  Why hasn't the ULANA program recognized the above problem?  Back in '85
and '86 I was (in my ignorance) a proponent of NetBIOS over TCP/IP and 
insisted it be part of the ULANA specification.  Much to my chagrin, I 
subsequently realized the error of my ways and have been trying ever since 
to have that requirement dropped.  Unfortunately, Mitre was off in their 
own world (always has been - always will be?) and refused to listen to 
sanity.  Now, we've got two vendors' products on the APL (or about to be) 
that are real dogs in performance (it's my understanding that neither 
the EDS/3COM nor the TRW PC host attachments meet the performance 
requirements) and yet don't even meet the RFCs or the IBM/Sytek NetBIOS 
specifications (contact me directly for specifcs).  All at a higher cost!
 
3)  One of the ULANA CLINs is to provide specification compliance testing
for third party products.  Has this ever been exercised?  How does one get
a compliant product on the APL?  How can we help the government save money
(ours!) on this program?   Am I just ------- in the wind?
 
If anyone can help me out, I'd sure appreciate it!
 
 
Link Verstegen                      afrlinkv@WPAFB-INFO5.AF.MIL
Integration Manager                 (405) 942-8884
Network Solutions, Inc.
4350 Will Rogers Pkwy.               ** These are MY opinions -  **
Suite 100                            ** I don't need to pass the **
Oklahoma City, OK  73108             ** buck on this one...      **
 
 
By the way, I heard a rumor that 10NET had won the Gunter LAN Software
Contract.  Any comments from the Peanut Gallery?
 

-----------[000280][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Sep 89 14:06:20 PDT
From:      cire|eric <cire@cisco.com>
To:        Dave_Katz@um.cc.umich.edu
Cc:        ddp+@andrew.cmu.edu, cire@cisco.com, tcp-ip@nic.ddn.mil
Subject:   Re: Token Ring BOF at Interop

How about if we do this...

IP over FDDI BOF...   5-7+

TR-FDDI/Ethernet Issues 7-9+

Those that want to go to both (I do) bug out at 7 after two hours.
Obviously it is important to stay focused.  I know I'd like to sit
in on the IP over FDDI too.

What is Phil's address?  Could you also pass this on to him Dave?

-c
-----------[000281][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 09:12:03 GMT
From:      adnan@sgtech.UUCP (Adnan Yaqub)
To:        comp.protocols.tcp-ip
Subject:   Checksum Byte Order...What is it?

I have a question about the byte order of TCP/IP checksums.  I was
looking through the Berkeley code, and it seems to me that the byte
order of the checksum is not adjusted for depending on the "endianish"
of the host.  For example, I see the following code:

		ip->ip_len = htons((u_short)ip->ip_len);
		ip->ip_off = htons((u_short)ip->ip_off);
		ip->ip_sum = 0;
		ip->ip_sum = in_cksum(m, hlen);
		error = (*ifp->if_output)(ifp, m, (struct sockaddr *)dst);

Since the checksum is a 16-bit quantity, it would see to me that one
would get a different value depending on whether the host is big or
little endian.  I looked at in_cksum_c (I don't have a copy of
in_cksum), and it doesn't seem to be endian sensitive.  (I may be
wrong, because the code is quite tricky.)

On the experimental side, I wrote some code to send out UDP datagram
with the checksum passed through htons.  The result was that the
receiving host (an Excelan network analyzer) said the checksum was
wrong.  I sent XXYY and it wanted YYXX.  So, how should the checksum
be sent?
--
Adnan Yaqub
Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860
...cwjcc!ncoast!sgtech!adnan ...uunet!abvax!sgtech!adnan

-----------[000282][next][prev][last][first]----------------------------------------------------
Date:      Wed, 27 Sep 89 17:38:27 PDT
From:      Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
To:        afrlinkv@wpafb-info5.af.mil, tcp-ip@nic.ddn.mil
Subject:   Re:  RFC Compliant NetBIOS & ULANA
There is no particular reason that netbios over tcp should have
poor performance.  The one possible exception might be during 
certain kinds of name resolutions, but these are relatively rare
events and I'm not convinced they would be slow.

My comment is based on direct experience, not just theory, tho it was
pre-RFC1001/2.  The work that the committee did to create 1001/2
did not appear to do anything that would limit the applicability
of my experience, since I was on that committee.

Dave
-----------[000283][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 13:10:10 GMT
From:      galvin@TIS.COM (James M Galvin)
To:        comp.protocols.tcp-ip
Subject:   TCP/IP Suite for XENIX/286 wanted

I would like any and all information about the availability of TCP/IP
protocol suites---that means I would like as many of telnet, ftp, smtp,
etc., as I can get---for XENIX/286.  I probably know all the obvious
sources, but tell me about them anyway.

I am interested in both freeware and commercial products, both hardware
and software implementations.

Please reply directly to me---"commercial" replies are acceptable---and
I will summarize to the list if there is sufficient interest---reply to
tell me if you are interested, also.

Thanks in advance,
Jim

-----------[000284][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 13:35:47 GMT
From:      mm06@GTE.COM (Michael Murphy)
To:        comp.protocols.tcp-ip,comp.unix.questions
Subject:   two IP networks on same ethernet


We will soon have to change the IP address of every device on our local area
network.   Yes, I know this is stupid.  We anticipate that not everyone will
be able to do the conversion at the same time, and that the machines that
are not switched over won't be able to communicate with those that have been.  I
would be grateful to learn if there were a way to avoid this problem.

I do know that with BSD unix it is possible to set up a zero-length route
to the "different" network on the same interface, which takes care of this
type of host.  There are other kinds of machines, e.g. terminal servers,
which don't know about this trick.  I suppose what we need to have in this
situation is a "gateway" to forward packets from one network on the same
interface to the different network.  Alternatively, we need to know if it
is possible for a BSD unix host to have two different IP addresses associated
with the same network interface.  Thanks.


-- 
mike murphy  mm06@gte.com {harvard,vaxine}!bunny!mm06
gte labs, waltham, ma

-----------[000285][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 13:54:33 GMT
From:      pete@NCSC.NAVY.MIL (Fernandez)
To:        comp.protocols.tcp-ip
Subject:   Bridge CS equipment


 Have seen lots of inquiries posted regarding usage of Bridge CS equipment.
 We here at NCSC use lots of CS/1s, CS/50s, and CS/200s. For more info,
 write direct, pete@ncsc.navy.mil.

 vr, Pete Fernandez
     Naval Coastal Systems Center

-----------[000286][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 15:28:00 GMT
From:      afrlinkv@WPAFB-INFO5.AF.MIL
To:        comp.protocols.tcp-ip
Subject:   RFC Compliant NetBIOS & ULANA

Maybe someone out there in the Internet can provide some insight...    
 
1)  Is there any reason whatsoever (one word?) to use an RFC 1001,1002 
compliant NetBIOS?  Sure, it means you're in tune with the DoD guidance
to use TCP/IP, but you still can't talk on the Internet - that is all 
current implementations of RFC compliant NetBIOS implement the Broadcast 
Nodes method and are delimited by their IP routers (Gateways).  This 
means you're buying more expensive hardware or using lots of host (PC) 
memory and receiving poorer performance because of the protocol overhead.     
 
2)  Why hasn't the ULANA program recognized the above problem?  Back in '85
and '86 I was (in my ignorance) a proponent of NetBIOS over TCP/IP and 
insisted it be part of the ULANA specification.  Much to my chagrin, I 
subsequently realized the error of my ways and have been trying ever since 
to have that requirement dropped.  Unfortunately, Mitre was off in their 
own world (always has been - always will be?) and refused to listen to 
sanity.  Now, we've got two vendors' products on the APL (or about to be) 
that are real dogs in performance (it's my understanding that neither 
the EDS/3COM nor the TRW PC host attachments meet the performance 
requirements) and yet don't even meet the RFCs or the IBM/Sytek NetBIOS 
specifications (contact me directly for specifcs).  All at a higher cost!
 
3)  One of the ULANA CLINs is to provide specification compliance testing
for third party products.  Has this ever been exercised?  How does one get
a compliant product on the APL?  How can we help the government save money
(ours!) on this program?   Am I just ------- in the wind?
 
If anyone can help me out, I'd sure appreciate it!
 
 
Link Verstegen                      afrlinkv@WPAFB-INFO5.AF.MIL
Integration Manager                 (405) 942-8884
Network Solutions, Inc.
4350 Will Rogers Pkwy.               ** These are MY opinions -  **
Suite 100                            ** I don't need to pass the **
Oklahoma City, OK  73108             ** buck on this one...      **
 
 
By the way, I heard a rumor that 10NET had won the Gunter LAN Software
Contract.  Any comments from the Peanut Gallery?
 

-----------[000287][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 16:08:50 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring BOF at Interop


Well this is getting weird.  I just checked with the Interop BOF
coordinator and there isn't a IP over FDDI BOF scheduled at all let
alone at Thursday 6-8.  There is one on FDDI management with is the
FDDI MIB one.  I checked for the entire week and there isn't anything
at all close to describing it.

Now there are several options here and I think we should organize them
to maximize our coverage.  There has been significant interest (yes I
know actual attendence remains to be seen) in the TR-FDDI/Ethernet
addressing BOF.  There is also significant interest in the IP over FDDI
and other issues BOF.

I'd like to see us arrange things so that these sessions don't overlap
too badly.  One option is back to back but perhaps that is too brutal
especially for the east coast types.  We could also say have one
on Tuesday from 6-8 and the other one on Thursday.

Right now I still have Thursday 6-8 but I'm certainly willing to work
with the community on this.  Either way we need to do this soon.  Today
would be ideal.

Thoughts,

-c

-----------[000288][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 16:22:01 GMT
From:      rjh@inteloa.intel.com (Bob Hathaway)
To:        comp.protocols.tcp-ip
Subject:   TCP Urgent Data Handling



I'm implementing TCP urgent data handling for our product line and have
discovered some ambiguous semantics.  This implementation will support
multiple transport layer interfaces including a Unix socket layer and must
be able to communicate with other TCP/IP implementations, however it appears
BSD Unix doesn't implement the TCP specifications as I would expect.
I'd appreciate hearing from any internet experts or be referred to any 
existing specifications which can clarify urgent data handling.


TCP RFC 793 and the MIL STD do not offer precise semantics for urgent
data handling.  Single byte messages are simple but larger messages seem
to be poorly defined.  For example, Ultrix assumes the first byte of a
multi-character message is urgent and 4.3 BSD assumes the last byte.  Also,
4.3 breaks large urgent messages into several segments with the URG bit
set and the urgent pointer pointing to just past the data *in each segment*.
The receiver will believe each segment is an urgent message and each segment
will override the last saved urgent byte unless inlining is specified.  This
implementation seems erroneous.

A more correct interpretation of the TCP specifications for multi-segment
urgent messages seems to be setting the URG bit on the first segment only 
and setting the urgent pointer to one byte past the last byte in the entire 
multi-segment urgent message.  The transport service will consider an entire
urgent message as urgent data allowing the socket layer to extract a single
byte from the urgent message if necessary.  Future socket implementations
will hopefully conform more closely to the TCP specification.  With this
interpretation, a receiver sets TCB variable RCV.UP = SEG.UP when an URG bit
is detected and arriving data up to *RCV.UP* is assumed to be urgent.

For example, this interpretation of the TCP specification will result in:

             URGENT MESSAGE		  SEGMENTS
	     ==============               ========
	      					URG=1, UP=3000 -+
           m	|-------|	          m     |-------|	|
		|	|	     		|	|	|
		|	|	     m + 1023	|-------|	|
		|	|			 	 	|
		|	|		        URG=UP=0	|
 ~	~	     m + 1024   |-------|	|
		|	|			|	|	|
		|	|	     m + 2047   |-------|	|
		|	|					|
		|	|		        URG=UP=0	|
		|	|	     m + 2048   |-------|	|
     m + 2999	|-------|	     		|	|	|
				     m + 2999   |-------|	|
							<-------+

PSH will also be set on all outgoing segments. 

For reliability, SEG.UP would have to be constraint checked and segments
with the URG bit set and a new UP which arrive past the first segment but
within the original urgent message would have to be handled, for example
when the second or third segments above arrived with URG=1, UP=new value.
These updates could be considered errors by sending a RST with logging or 
could be considered correct by updating RCV.UP.  We opt for considering UP
updates within messages an error condition and disconnect with a RST because
this indicates the peer is out of sync.

This scheme raises some important questions such as compatibility with
existing systems and correctness.  Are there any existing specifications
or internet experts which can clarify this?

Thanks,
Bob Hathaway
rjh@inteloa.intel.com
!tektronix!biin!rjh

-----------[000289][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 16:48:12 GMT
From:      oliveb!mipos3!omepd!intelob!rjh@apple.com  (Bob Hathaway)
To:        tcp-ip@NIC.DDN.MIL
Subject:   TCP Urgent Data Handling


I'm implementing TCP urgent data handling for our product line and have
discovered some ambiguous semantics.  This implementation will support
multiple transport layer interfaces including a Unix socket layer and must
be able to communicate with other TCP/IP implementations, however it appears
BSD Unix doesn't implement the TCP specifications as I would expect.
I'd appreciate hearing from any internet experts or be referred to any 
existing specifications which can clarify urgent data handling.


TCP RFC 793 and the MIL STD do not offer precise semantics for urgent
data handling.  Single byte messages are simple but larger messages seem
to be poorly defined.  For example, Ultrix assumes the first byte of a
multi-character message is urgent and 4.3 BSD assumes the last byte.  Also,
4.3 breaks large urgent messages into several segments with the URG bit
set and the urgent pointer pointing to just past the data *in each segment*.
The receiver will believe each segment is an urgent message and each segment
will override the last saved urgent byte unless inlining is specified.  This
implementation seems erroneous.

A more correct interpretation of the TCP specifications for multi-segment
urgent messages seems to be setting the URG bit on the first segment only 
and setting the urgent pointer to one byte past the last byte in the entire 
multi-segment urgent message.  The transport service will consider an entire
urgent message as urgent data allowing the socket layer to extract a single
byte from the urgent message if necessary.  Future socket implementations
will hopefully conform more closely to the TCP specification.  With this
interpretation, a receiver sets TCB variable RCV.UP = SEG.UP when an URG bit
is detected and arriving data up to *RCV.UP* is assumed to be urgent.

For example, this interpretation of the TCP specification will result in:

             URGENT MESSAGE		  SEGMENTS
	     ==============               ========
	      					URG=1, UP=3000 -+
           m	|-------|	          m     |-------|	|
		|	|	     		|	|	|
		|	|	     m + 1023	|-------|	|
		|	|			 	 	|
		|	|		        URG=UP=0	|
		~	~	     m + 1024   |-------|	|
		|	|			|	|	|
		|	|	     m + 2047   |-------|	|
		|	|					|
		|	|		        URG=UP=0	|
		|	|	     m + 2048   |-------|	|
     m + 2999	|-------|	     		|	|	|
				     m + 2999   |-------|	|
							<-------+

PSH will also be set on all outgoing segments. 

For reliability, SEG.UP would have to be constraint checked and segments
with the URG bit set and a new UP which arrive past the first segment but
within the original urgent message would have to be handled, for example
when the second or third segments above arrived with URG=1, UP=new value.
These updates could be considered errors by sending a RST with logging or 
could be considered correct by updating RCV.UP.  We opt for considering UP
updates within messages an error condition and disconnect with a RST because
this indicates the peer is out of sync.

This scheme raises some important questions such as compatibility with
existing systems and correctness.  Are there any existing specifications
or internet experts which can clarify this?

Thanks,
Bob Hathaway
rjh@inteloa.intel.com
!tektronix!biin!rjh
-----------[000290][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 17:06:56 GMT
From:      koreth@panarthea.ebay.sun.com (Steven Grimm)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

In article <5446@asylum.SF.CA.US> karl@asylum.SF.CA.US (Karl Auerbach) writes:
>Now, it seems, according to RFC1111, that postscript is OK for RFC's,
>(including postscript that was obviously generated by a word or text
>processor.)
>
>I propose that we ban postscript RFCs.

Agreed.  Apart from really complex diagrams, I don't really see why it's
necessary.  If your RFC needs diagrams, make the necessary PostScript (or
"pic" commands or whatever) a separate entity (rfcxxxx.5?) so your text
will be readable by a wider audience.

For those who like pretty-printed RFCs, though, there should be some way
to get at them in their original uncooked nroff (or TeX, etc.) forms.  I
wouldn't mind having a nice copy of rfcxxxx from my LaserWriter, but I don't
want it at the expense of people who can't view PostScript files.

---
This message is a figment of your imagination.  Any opinions are yours.
Steven Grimm		Moderator, comp.{sources,binaries}.atari.st
sgrimm@sun.com		...!sun!sgrimm

-----------[000291][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 17:22:26 GMT
From:      n2dsy@cbnewsh.ATT.COM (j.gordon.beattie)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Crucible

Can someone send me an electronic copy of the Crucible Vol. 1 Issue 1?
I got issue 2 and would like to see the text from the first issue.
Thanks,
Gordon Beattie
n2dsy@hou2d.att.com
201-615-4168

-----------[000292][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 18:03:40 GMT
From:      jrb@amadeus.WR.TEK.COM (Jim Binkley)
To:        comp.protocols.tcp-ip
Subject:   questions about Unix TCP


A couple of questions about TCP implementations.

I noticed that running two rsh commands in a row: rsh NONSUN date; rsh NONSUN date;
from a Sun to a NONSUN BSD system (say Ultrix, or 4.3 BSD or you name it)
was taking somewhere between 5-8 seconds between rsh the first and rsh the
second. This seemed overly long. Then I discovered "etherfind" and captured the following 
dialogue: 

(etherfind -t -v -proto tcp -between bambi godzilla; this gives
us a verbose tcp conversation with a timestamp. I edited out everything
between the initial SYN/ACK and final FINs messages.)

RSH #1.
 0.00 TCP from bambi.1020 to godzilla.shell seq BA18A00, SYN,  window 4096, 
 0.02 TCP from godzilla.shell to bambi.1020 seq 706141, ack BA18A01, SYN,  window 4096, 
 0.02 TCP from bambi.1020 to godzilla.shell seq BA18A01, ack 706142,  window 4096, 
 0.02 TCP from bambi.1020 to godzilla.shell seq BA18A01, ack 706142,  window 4096, 5 bytes data
 0.20 TCP from godzilla.shell to bambi.1020 seq 706142, ack BA18A06,  window 4091, 
 0.22 TCP from godzilla.1020 to bambi.1019 seq 706181, SYN,  window 4096, 
 0.22 TCP from bambi.1019 to godzilla.1020 seq BA37E00, ack 706182, SYN,  window 4096, 
 0.22 TCP from godzilla.1020 to bambi.1019 seq 706182, ack BA37E01,  window 4096, 
 0.64 TCP from godzilla.shell to bambi.1020 seq 706156, ack BA18A13, FIN,  window 4096, 
 0.64 TCP from bambi.1020 to godzilla.shell seq BA18A13, ack 706157,  window 4078, 
 0.64 TCP from godzilla.1020 to bambi.1019 seq 706182, ack BA37E01, FIN,  window 4096, 
 0.64 TCP from bambi.1019 to godzilla.1020 seq BA37E01, ack 706183,  window 4096, 
 0.70 TCP from bambi.1019 to godzilla.1020 seq BA37E01, ack 706183, FIN,  window 4096, 
 0.70 TCP from bambi.1020 to godzilla.shell seq BA18A13, ack 706157, FIN,  window 4096, 
 0.72 TCP from godzilla.1020 to bambi.1019 seq 706183, ack BA37E02,  window 4096, 
 0.72 TCP from godzilla.shell to bambi.1020 seq 706157, ack BA18A14,  window 4096, 


RSH #2
 1.44 TCP from bambi.1020 to godzilla.shell seq BA66C00, SYN,  window 4096, 
 1.46 TCP from godzilla.shell to bambi.1020 seq 706157, ack BA18A14,  window 4096, 
 1.46 TCP from bambi.1020 to godzilla.shell seq BA18A14, RESET,  window 4096, 

 7.08 TCP from bambi.1020 to godzilla.shell seq BA66C00, SYN,  window 4096, 
 7.08 TCP from godzilla.shell to bambi.1020 seq 706541, ack BA66C01, SYN,  window 4096, 
 7.08 TCP from bambi.1020 to godzilla.shell seq BA66C01, ack 706542,  window 4096, 
 7.08 TCP from bambi.1020 to godzilla.shell seq BA66C01, ack 706542,  window 4096, 5 bytes data
 7.20 TCP from godzilla.shell to bambi.1020 seq 706542, ack BA66C06,  window 4091, 
 7.28 TCP from godzilla.1021 to bambi.1019 seq 706581, SYN,  window 4096, 
 7.28 TCP from bambi.1019 to godzilla.1021 seq BB31E00, ack 706582, SYN,  window 4096, 
 7.28 TCP from godzilla.1021 to bambi.1019 seq 706582, ack BB31E01,  window 4096, 
 7.56 TCP from godzilla.shell to bambi.1020 seq 706556, ack BA66C13, FIN,  window 4096, 
 7.56 TCP from bambi.1020 to godzilla.shell seq BA66C13, ack 706557,  window 4078, 
 7.58 TCP from godzilla.1021 to bambi.1019 seq 706582, ack BB31E01, FIN,  window 4096, 
 7.58 TCP from bambi.1019 to godzilla.1021 seq BB31E01, ack 706583,  window 4096, 
 7.60 TCP from bambi.1019 to godzilla.1021 seq BB31E01, ack 706583, FIN,  window 4096, 
 7.60 TCP from bambi.1020 to godzilla.shell seq BA66C13, ack 706557, FIN,  window 4096, 
 7.60 TCP from godzilla.1021 to bambi.1019 seq 706583, ack BB31E02,  window 4096, 
 7.60 TCP from godzilla.shell to bambi.1020 seq 706557, ack BA66C14,  window 4096, 

 Bambi was the sun machine. Godzilla was the non-sun machine.

 What is curious to me is that on the second TCP invocation, the non-sun
 "Godzilla" sends back an ack on the previous window with a non-advanced
 sequence number. Should it not send back a reset? What is the proper
 behaviour here?

 The other question is what mechanism in the Unix src code is governing
 the 5+ second wait after the Sun sends the RESET. Why does it wait so long?
 I turned the conversation around and found that the results were similar
 but the RESET wait from the non-sun machine was less than 1 second.

					Jim Binkley
					Tektronix, Portland, Oregon
					jrb@amadeus.wr.tek.com




					James Binkley
					jrb@amadeus.wr.tek.com

-----------[000293][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 18:11:30 GMT
From:      arao@cbnewsh.ATT.COM (aswath.k.rao)
To:        comp.protocols.iso,comp.protocols.tcp-ip
Subject:   Re: Crucible

From article <4254@cbnewsh.ATT.COM>, by n2dsy@cbnewsh.ATT.COM (j.gordon.beattie):
> Can someone send me an electronic copy of the Crucible Vol. 1 Issue 1?
> I got issue 2 and would like to see the text from the first issue.
> Thanks,
> Gordon Beattie
> n2dsy@hou2d.att.com
> 201-615-4168
> 
I would like a copy as well.
Thanks,
Aswath Rao
arao@houtz.att.com
201-949-0093

-----------[000294][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 18:28:40 GMT
From:      nelson@sun.soe.clarkson.edu (Russ Nelson)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

In article <5446@asylum.SF.CA.US> karl@asylum.SF.CA.US (Karl Auerbach) writes:

   I thought we were working on communications, not obfuscation.

   I propose that we ban postscript RFCs [because the on-line text is typically
   unreadable]

Karl has a good point.  We must bear in mind that PostScript has the
potential for better communication.  I offer three solutions less
drastic than his total ban:

  o Keep RFCs in a text-only format, and provide hints to a PostScriptizer
    that knows what parts of the text should be filled, what parts of the
    text are actually character graphics (like | and - ), and what parts
    are tables.

  o Restrict the types of PostScript that are acceptable to those that can
    be textized by running them through a filter.  That way, a user can
    reconstruct a reasonable text version of the RFC.

  o Create a PostScript interpreter that renders its output using a
    unidirectional stream of ASCII characters.

Of course, a reasonable follow-up to this message is:

Russ!  Good idea!  Send me a copy when you get it written!  :-)

--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
Live up to the light thou hast, and more will be granted thee.

-----------[000295][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 19:17:39 GMT
From:      CMH117@PSUVM.BITNET
To:        comp.protocols.tcp-ip
Subject:   Re: MS-DOS virus rumor


  This is just another one of those articles meant to increase public fear of
viruses and/or increase anti-virus program sales!  Please keep this kind of
garbage in comp.viruses, or whatever it is!
8

-----------[000296][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 19:41:40 GMT
From:      barmar@kulla (Barry Margolin)
To:        comp.protocols.tcp-ip
Subject:   Re: Checksum Byte Order...What is it?

In article <ADNAN.89Sep27101203@sgtech.UUCP> adnan@sgtech.UUCP (Adnan Yaqub) writes:
>		ip->ip_sum = in_cksum(m, hlen);
>Since the checksum is a 16-bit quantity, it would see to me that one
>would get a different value depending on whether the host is big or
>little endian.  I looked at in_cksum_c (I don't have a copy of
>in_cksum), and it doesn't seem to be endian sensitive.  (I may be
>wrong, because the code is quite tricky.)

This is due to an interesting feature of 16-bit one's-complement
checksums with end-around carry: it automatically does the right
thing!  It's because the checksum routine is reading the packet in
16-bit chunks in host byte order.  Since it isn't converting from
network order to host order before summing, it doesn't have to convert
back to network order when storing the sum.  There's a rigorous proof
(which I don't know) that this always produces the right result.  I
think the end-around carry is the part of the checksum algorithm that
does it; it means that carries out of the high-order byte act just
like carries out of the low-order byte, being added into the other
byte, so the byte order is not significant (an implementation has to
be consistent, though).
Barry Margolin, Thinking Machines Corp.

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

-----------[000297][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 20:57:36 GMT
From:      Dave_Katz@UM.CC.UMICH.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring BOF at Interop

Phill Gross has tentatively scheduled an IP over FDDI BOF for
Thursday from 5 to 8.  I have my doubts about being able to
do much on Tuesday myself, because I'll likely be setting up
for demos that start Wednesday.
 
By Thursday us EDTers should be fully acclimated...

-----------[000298][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 21:06:20 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring BOF at Interop


How about if we do this...

IP over FDDI BOF...   5-7+

TR-FDDI/Ethernet Issues 7-9+

Those that want to go to both (I do) bug out at 7 after two hours.
Obviously it is important to stay focused.  I know I'd like to sit
in on the IP over FDDI too.

What is Phil's address?  Could you also pass this on to him Dave?

-c

-----------[000299][next][prev][last][first]----------------------------------------------------
Date:      27 Sep 89 21:09:15 GMT
From:      teb@sequoia.UUCP (Thomas E. Bernhard)
To:        comp.protocols.tcp-ip
Subject:   TELNET RFC?

Can someone please send me a copy of the TELNET RFC? If not
could you please tell me where I could get a copy of it?

Many thanks in advance...

-----------[000300][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 00:26:07 GMT
From:      dunigan@MSR.EPM.ORNL.GOV (Tom Dunigan 576-2522)
To:        comp.protocols.tcp-ip
Subject:   seeking token-ether IP router that does proxy ARP to the ether

We would like to find an IP router between token ring and ethernet,
where the router will do proxy ARP's for the token IP engines
(so we don't have to subnet.  the Kinetics boxes do this sort of
proxy arp between Appletalk and Ether.)
thanks
tom
  dunigan@msr.epm.ornl.gov

-----------[000301][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 00:38:27 GMT
From:      dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker)
To:        comp.protocols.tcp-ip
Subject:   Re:  RFC Compliant NetBIOS & ULANA

There is no particular reason that netbios over tcp should have
poor performance.  The one possible exception might be during 
certain kinds of name resolutions, but these are relatively rare
events and I'm not convinced they would be slow.

My comment is based on direct experience, not just theory, tho it was
pre-RFC1001/2.  The work that the committee did to create 1001/2
did not appear to do anything that would limit the applicability
of my experience, since I was on that committee.

Dave

-----------[000302][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Sep 89 08:15:14 -0400
From:      Craig Partridge <craig@NNSC.NSF.NET>
To:        joshua@athertn.atherton.com
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   re: RDP questions

Joshua:

    I will pass the question of whether it makes sense to implement RDP
over e-mail and focus simply on your questions about the spec.

    Yes there are known bugs in the RDP protocol as described in
    RFC 908.  The list is appended.  Given the recent interest in
    RDP, it may be time to actually sit down and generate the spec
    for RDP version 2.

    My recollection is there is no distinction between a CLOSED connection
    and one without a connection record.

    256 ports is much too low -- RDP version 2 would allow 16-bit
    ports.  It also uses the TCP checksum because the RDP checksum
    proved very sensitive to byte order (as a result, RDP would run
    4 or 5 times slower on machines with the wrong byte order).

    Another problem is that RDP doesn't have a windowing scheme that
    ensures the the receiver and sender stay in sync.  In particular,
    there's now way for the receiver to tell the sender that while
    yes it has received the data, it doesn't want any more quite
    yet.  The best suggestion I've heard so far is from Van Jacobson,
    which is for the receiver to delay the ack until it has actually
    processed the data received.

Craig

RDP Error List

Minor Errors and Ambiguities

   Some ambiguities and minor errors have been found in RFC-908.
   They are corrected in this section.

   The value of the state variable, SND.UNA is treated inconsistently
   in the pseudo-code on pages 21-29.  On page 12, SND.UNA is defined
   as "the sequence number of the oldest unacknowledged segment",
   and on page 21 it is appropriately set to the initial sequence
   number when the connection is opened.  But on page 28, when an
   acknowledgement is received, SND.UNA is set to SEG.ACK, the
   sequence number being acknowledged, instead of SEG.ACK+1.  A
   similar inconsistency occurs on page 26.  The proper fix is to
   always set SND.UNA to SEG.ACK+1.

   The pseudo-code on page 25 for the SYN-SENT state is incorrect.
   The first few lines cause all packets with the ACK bit set to be
   discarded, but later lines test the ACK bit.  The test for the ACK
   bit should be placed after all the other tests.  Also note that if
   the ACK bit is set, a RST segment is sent to reset the remote peer,
   but the local peer is left half-open.  There is a similar problem in
   the SYN-RCVD state.  The local peer should deallocate the connection
   record and close.

   On page 24, the pseudo-code indicates that if non-data packets are
   received in the CLOSED state, a RST segment with SEG.ACK set to
   RCV.CUR should be sent.  RCV.CUR is not defined in the CLOSED
   state.  SEG.ACK should be set to SEG.SEG.

   There is some inconsistency about how to handle a RST packet in
   the CLOSE-WAIT state.  On page 24, the pseudo-code shows that a
   RST should cause the connection state to become CLOSED.  Text on
   page 13 and the state diagram on page 10 suggest the connection
   state should stay in CLOSE-WAIT.  The implementation should stay
   in CLOSE-WAIT.

   On page 29, the pseudo-code for the OPEN state suggests that if a
   data packet is received in sequence, the acknowledgement packet
   should not contain EACKs.  This is misleading.  Implementations
   may include EACKs in the acknowledgement.
-----------[000303][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 02:10:19 GMT
From:      budden@manta.NOSC.MIL (Rex A. Buddenberg)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

At the risk of sounding too rational, why don't you employ
the CALS standards for what they were settled on for?
(SGML for text, IGES for CAD, CCITT Group 4 for images).
Is there an RFC/IEEE/ANSI/ISO standard for PostScript?

Rex Buddenberg

-----------[000304][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Sep 89 09:23:13 PDT
From:      cire|eric <cire@cisco.com>
To:        tcp-ip@nic.ddn.mil
Subject:   FDDI and TR BOFs

A final note with the resolution between the conflicting meeting times...

IP in Bridged environments - Wednesday Oct 4 5-8pm

FDDI MIB - Thursday Oct 5 6-8pm

TR-FDDI/Ethernet Addressing Issues - Thursday Oct 5 6-8pm


Further announcements if any for the TR-FDDI/Ethernet Addressing Issues
will be done via direct mail.  Send me mail if you wish to be included.

See you there.

-c
-----------[000305][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 03:06:58 GMT
From:      zweig@brutus.cs.uiuc.edu (Johnny Zweig)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)


It seems the best thing to do is to put PostScript stuff _somewhere else_. I
like being able to do "lpr RFCxxx" and have the right thing happen -- and I
imagine people who don't have PostScript printers around would be even more
adamant on the point.

It seems that complicated drawings ought to go into some kind of companion
document that would be referenced (with good old [1]...[n] in plain ASCII)
in the RFC-proper.

I think that one can go a long way with  - + | _ / \ < and >. Certainly
anything that can't be described without a comlicated drawing ought to be
rephrased. A picture may be worth a thousand words, but a standard should be
clear enough not to need thousands of words.

-Johnny Keep-it-simple

-----------[000306][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Sep 89 09:22:59 CST
From:      strickland <SNSTR%TTUVM1.BITNET@ricevm1.rice.edu>
To:        TCP-IP <TCP-IP@SRI-NIC.ARPA>
Subject:   Re: TELNET RFC?
>Can someone please send me a copy of the TELNET RFC? If not
>could you please tell me where I could get a copy of it?
>
>Many thanks in advance...

You can send mail to LISTSERV@TCSVM.bitnet with a single line in the body...

GET RFC854 LISTING
-----------[000307][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 1989 07:35-EDT
From:      CERF@A.ISI.EDU
To:        avsd!vixie!asylum!karl@UCBVAX.BERKELEY.EDU
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: Comment on RFC1124 (?)
Karl,

The PostScript question is well taken. We seriously need some
way to capitalize on "desktop publishing" (compound documents)
without being forced back to paper only. At the same time, all
of us recognize and have experienced the problem you describe.
The one thing which is still a major conundrum for me is the
problem of illustrations. ASCII only illustrations are painful
to produce and most tools produce other than ASCII (bitmap or
PostScript is more typical graphic tool output).

What's your general thought about finding a path towards
benefitting from the tools now emerging while at the same
time not losing the obvious benefits of the ASCII output form?

Vint
-----------[000308][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 05:17:17 GMT
From:      joshua@athertn.Atherton.COM (Flame Bait)
To:        comp.protocols.tcp-ip
Subject:   RDP questions

Madness takes it toll....  

I'm looking at the RDP description (RFC908) with an eye towards implementing
it on top of email, instead of IP packets.  I chose it over VMTP (RFC1045)
because it seems simpler.  The RDP description is about half as long
as the VMTP description, and the RDP description contains very simple and
short descriptions of the data structures and algorithms used.  VMTP did
not seem to have these.  

Do have some questions about the protocol:

    Are there any known bugs in RDP as described in RFC 908?

    What is the difference between a closed connection, and a connection 
    which does not have a connection record at all?  It seems to me that 
    these are the same.

    Why can a packet not contain data and a RST (end of connection) flag?

    On a more general note, RDP only allows 256 ports and 4 versions.  These 
    limits seem a little low to me.  (They won't apply to my protocol though,
    since it will have port names, and any number of versions.  I'm mapping 
    fields in the RDP header into lines in an email header:
    X-REP-Source: source-port-name
    X-REP-Destination: destination-port-name
    X-REP-Version: 0
    and so on...)

BTW, the name for this project is REP, Reliable Email based Protocol, 
which is also short for REPTILE, which should describe its speed. :-)

Joshua Levy
--------                Quote: "Remember:  No matter how obnoxious it gets,
Addresses:                      you CANNOT execute a device!" -- Peter Franks
joshua@atherton.com          
{decwrl|sun|hpda}!athertn!joshua    work:(408)734-9822    home:(415)968-3718

-----------[000309][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Sep 89 9:36:51 EDT
From:      Charles Lynn <clynn@BBN.COM>
To:        CERF@a.isi.edu
Cc:        avsd!vixie!asylum!karl@ucbvax.berkeley.edu, tcp-ip@nic.ddn.mil
Subject:   Re:  Comment on RFC1124 (?)
I'm not a Postscript expert, but from the earlier message it seems
that things would be a lot better if the .ps document didn't try
to justify the words within a line.  Is it "easy" to disable text
justification (leaving fill enabled)?  Are font changes within a
phrase, e.g., titles, a significant problem?

Charlie
-----------[000310][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 06:31:19 GMT
From:      romkey@asylum.sf.ca.us (John Romkey)
To:        comp.protocols.tcp-ip
Subject:   Comment on RFC1124 (?)

I'd suggest that rather than ban them, ensure that all RFC's are
available in plain text, and allow postscript versions as a secondary
format for them. But certainly never release an RFC in postscript-only
format.
			- john romkey
USENET/UUCP: romkey@asylum.sf.ca.us	Internet: romkey@ftp.com
"Live the life you love, Use a god you trust,
 and don't take it all too seriously." - Love & Rockets

-----------[000311][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Sep 89 11:00:47 EDT
From:      Brad Clements <bkc@omnigate.clarkson.edu>
To:        Karl Auerbach <avsd!vixie!asylum!karl@ucbvax.berkeley.edu>
Cc:        tcp-ip@nic.ddn.mil
Subject:   Re:  Comment on RFC1124 (?)
Karl Auerbach has proposed that postscript RFC's be banned, presumably because
trying to index keywords in a postscript file is a pain, and not because 
he feels that postscript printers are too obscure. (is that right?)

I don't mind postscript format, but I think the question of keyword indexing
should be addressed. 

It would be useful if authors of any document that is shipped in postscript
were to add a postscript prologue to the file with the proper keyword indexes.

A standard postscript prologue goes something like;

%%Begin Keywords
%%topic: interfaces checksum rfc1001 netbios smb
%%relatedto: udp ip rfc1002 
%%End Keywords

By standard, I mean the double % and the begin and end blocks. I probably
don't have the version 2.0 ESPF format quite right, but the idea is the same
anyway.

It'd be easy to strip out sets of keywords (do we need an RFC to describe the
standard for key words?) and items prefaced by % won't upset the postscript
printer either.


comments?


| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clutx.bitnet 
| Network Engineer       Clarkson University              (315)268-2292
------------------- Meet me at Interop '89 ---------------------------------
-----------[000312][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 07:34:55 GMT
From:      ilham@ATHENA.MIT.EDU (Ilhamuddin Ahmed)
To:        comp.protocols.tcp-ip
Subject:   Re: Remote Printer Protocol?



=== Forwarded message =====================

   ----- Transcript of session follows -----
421 mitre.mitre.org.tcp... Deferred: Connection timed out during user open with mitre.mitre.org

   ----- Unsent message follows -----
Received: by GARFIELD.MIT.EDU (5.61/4.7) id AA11319; Sat, 23 Sep 89 17:22:16 -0400
Date: Sat, 23 Sep 89 17:22:16 -0400
Message-Id: <8909232122.AA11319@GARFIELD.MIT.EDU>
From: Ilhamuddin Ahmed <ilham@athena.mit.edu>
Sender: ilham@ATHENA.MIT.EDU
To: mckee@mwunix.mitre.org
In-Reply-To: H. Craig McKee's message of Tue, 19 Sep 89 14:40:42 EDT <8909191840.AA20076@mitre.arpa>
Subject: Remote Printer Access protocol? 


>	Organization: The MITRE Corp., Washington, D.C.
>	Date: Tue, 19 Sep 89 14:40:42 EDT
>	From: H. Craig McKee <mckee@mwunix.mitre.org>
 
>	Ilham - One of the conclusions of the overview paper on The Athena
>	Palladium Print System is that, "The incorporation of centralized
>	management into the system will allow for easier and more effective
>	management of the print services ...."
 
>	"Centralized" things are worrisome, particularly in a distributed
>	environment.  Do the centralized management procedures run in a single
>	machine; are they essential to the AP Print System; what recovery
>	actions do you have planned when a failure occurs?  Regards - Craig

The management functions are executed on a Palladium print server from
an authenticated person anywhere on the network. In the Berkeley
spooler, to do any maintanence, you would have to login to the host
running lpd and then run lpc. In case of Palladium, you can pause,
disable, shutdown and again restart the printer/server/supervisor by not
physically logging into the server but issuing a command which will send
an authenticated RPC request to the server/supervisor. So as you can
see, management procedures do not run on a particular machine but by
authorized personnel using client programs on any machine.

The case of accounting is slightly different. Currently all it does is
to save the accounting information on the local disk of each print
server. I am now working on the Quota server where each print server
will "ask" if the person attempting to print should be allowed on not
depending on their quota. If allowed, once the job is completed, the
print server will send a message back to the quota server with the
accounting information.  In this case, the quota server is running on a
single machine but I will put in sufficient fallback in that if the
printserver cannot contact the quota server, it will save the accounting
info to local disk and once the quota server is back up, it will queue
all info back. This addition of the quota server is not in the ECMA
standard but is required here at Athena.

							- Ilham

=== Forwarded message =====================

-----------[000313][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 08:14:21 GMT
From:      bart@videovax.tv.Tek.com (Bart Massey)
To:        comp.protocols.tcp-ip
Subject:   Leave Those RFCs in ASCII! (Re: Comment on RFC1124 (?))

In article <5446@asylum.SF.CA.US> karl@asylum.SF.CA.US (Karl Auerbach) writes:
> I propose that we ban postscript RFCs.

Seconded.  It's not like we don't have postscript printers and previewers
everyplace -- as Karl said, it's just really nice to be able to read/search
for/index/etc an RFC without having to invoke all of that machinery.  And
it's not at all clear to me why PostScript is necessary.  I have never been
confused by the lack of font support or the ASCII graphics in the older
RFCs.  Seems like a solution to a non-problem, IMHO!

					Bart Massey
					
					Tektronix, Inc.
					TV Systems Engineering
					M.S. 58-639
					P.O. Box 500
					Beaverton, OR 97077
					(503) 627-5320

					..tektronix!videovax.tv.tek.com!bart

-----------[000314][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 08:49:41 GMT
From:      skl@van-bc.UUCP (Samuel Lam)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

It would be great if those of us without easy access to PostScript
capable laser printers would not be kept out of future RFC's, as
with the recent RFC which only has a PostScript version.

Requiring that each PostScript RFC submitted be accompanied with
a plain text version should do it.  (The reverse wouldn't be necessary).

There are still many people who cannot easily have a PostScript
file printed.  (Or is the argument that those people should be kept
out in the cold because if one can't afford a PostScript capable
printer he/she shouldn't be reading RFC's? :-( )

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

-----------[000315][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 08:56:35 GMT
From:      zephyr.ens.tek.com!tekcrl!tekfdi!videovax!bart@uunet.uu.net  (Bart Massey)
To:        tcp-ip@NIC.DDN.MIL
Subject:   Leave Those RFCs in ASCII! (Re: Comment on RFC1124 (?))
In article <5446@asylum.SF.CA.US> karl@asylum.SF.CA.US (Karl Auerbach) writes:
> I propose that we ban postscript RFCs.

Seconded.  It's not like we don't have postscript printers and previewers
everyplace -- as Karl said, it's just really nice to be able to read/search
for/index/etc an RFC without having to invoke all of that machinery.  And
it's not at all clear to me why PostScript is necessary.  I have never been
confused by the lack of font support or the ASCII graphics in the older
RFCs.  Seems like a solution to a non-problem, IMHO!

					Bart Massey
					
					Tektronix, Inc.
					TV Systems Engineering
					M.S. 58-639
					P.O. Box 500
					Beaverton, OR 97077
					(503) 627-5320

					..tektronix!videovax.tv.tek.com!bart
-----------[000316][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 11:35:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

Karl,

The PostScript question is well taken. We seriously need some
way to capitalize on "desktop publishing" (compound documents)
without being forced back to paper only. At the same time, all
of us recognize and have experienced the problem you describe.
The one thing which is still a major conundrum for me is the
problem of illustrations. ASCII only illustrations are painful
to produce and most tools produce other than ASCII (bitmap or
PostScript is more typical graphic tool output).

What's your general thought about finding a path towards
benefitting from the tools now emerging while at the same
time not losing the obvious benefits of the ASCII output form?

Vint

-----------[000317][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 12:15:14 GMT
From:      craig@NNSC.NSF.NET (Craig Partridge)
To:        comp.protocols.tcp-ip
Subject:   re: RDP questions


Joshua:

    I will pass the question of whether it makes sense to implement RDP
over e-mail and focus simply on your questions about the spec.

    Yes there are known bugs in the RDP protocol as described in
    RFC 908.  The list is appended.  Given the recent interest in
    RDP, it may be time to actually sit down and generate the spec
    for RDP version 2.

    My recollection is there is no distinction between a CLOSED connection
    and one without a connection record.

    256 ports is much too low -- RDP version 2 would allow 16-bit
    ports.  It also uses the TCP checksum because the RDP checksum
    proved very sensitive to byte order (as a result, RDP would run
    4 or 5 times slower on machines with the wrong byte order).

    Another problem is that RDP doesn't have a windowing scheme that
    ensures the the receiver and sender stay in sync.  In particular,
    there's now way for the receiver to tell the sender that while
    yes it has received the data, it doesn't want any more quite
    yet.  The best suggestion I've heard so far is from Van Jacobson,
    which is for the receiver to delay the ack until it has actually
    processed the data received.

Craig

RDP Error List

Minor Errors and Ambiguities

   Some ambiguities and minor errors have been found in RFC-908.
   They are corrected in this section.

   The value of the state variable, SND.UNA is treated inconsistently
   in the pseudo-code on pages 21-29.  On page 12, SND.UNA is defined
   as "the sequence number of the oldest unacknowledged segment",
   and on page 21 it is appropriately set to the initial sequence
   number when the connection is opened.  But on page 28, when an
   acknowledgement is received, SND.UNA is set to SEG.ACK, the
   sequence number being acknowledged, instead of SEG.ACK+1.  A
   similar inconsistency occurs on page 26.  The proper fix is to
   always set SND.UNA to SEG.ACK+1.

   The pseudo-code on page 25 for the SYN-SENT state is incorrect.
   The first few lines cause all packets with the ACK bit set to be
   discarded, but later lines test the ACK bit.  The test for the ACK
   bit should be placed after all the other tests.  Also note that if
   the ACK bit is set, a RST segment is sent to reset the remote peer,
   but the local peer is left half-open.  There is a similar problem in
   the SYN-RCVD state.  The local peer should deallocate the connection
   record and close.

   On page 24, the pseudo-code indicates that if non-data packets are
   received in the CLOSED state, a RST segment with SEG.ACK set to
   RCV.CUR should be sent.  RCV.CUR is not defined in the CLOSED
   state.  SEG.ACK should be set to SEG.SEG.

   There is some inconsistency about how to handle a RST packet in
   the CLOSE-WAIT state.  On page 24, the pseudo-code shows that a
   RST should cause the connection state to become CLOSED.  Text on
   page 13 and the state diagram on page 10 suggest the connection
   state should stay in CLOSE-WAIT.  The implementation should stay
   in CLOSE-WAIT.

   On page 29, the pseudo-code for the OPEN state suggests that if a
   data packet is received in sequence, the acknowledgement packet
   should not contain EACKs.  This is misleading.  Implementations
   may include EACKs in the acknowledgement.

-----------[000318][next][prev][last][first]----------------------------------------------------
Date:      Thu, 28 Sep 89 16:42:31 EDT
From:      rdroms@NRI.Reston.VA.US
To:        tcp-ip@nic.ddn.mil
Subject:   Re: Comment on RFC1124 (?)

Comments on suggested solutions:

  o Keep RFCs in a text-only format, and provide hints to a PostScriptizer
    that knows what parts of the text should be filled, what parts of the
    text are actually character graphics (like | and - ), and what parts
    are tables.

PostScriptizing an ASCII RFC doesn't sound like much of a win - you've
already lost all the graphics info ... there's nothing to reconstruct.

  o Restrict the types of PostScript that are acceptable to those that can
    be textized by running them through a filter.  That way, a user can
    reconstruct a reasonable text version of the RFC.

Reverse engineering ASCII from PostScript sounds like an interesting,
but hard, problem.  You'll need to guess what parts are straight
ASCII, and can be re-paragraphed, what parts are tables and must be
left verbatim, and what parts are graphics and must be approximated
with ASCII text.

It is clearly advantageous to have the ability to view and search
through RFCs on-line.  For the time being, we might want to try a
fourth solution:

  o Require the author to submit an ASCII version of the RFC - and
    allow an optional PostScript version.

nroff/troff solves the problem by using two translators - nroff
generates ASCII and troff generates PostScript from the same course.
Is there a version of nroff that behave rationally when confronted by
grpahics (e.g., pic output) input?  Is there an equivalent to nroff
for TeX?

- Ralph Droms                             (On leave from Bucknell University)
  NRI                                     rdroms@nri.reston.va.us
  1895 Preston White Drive, Suite 100     (703) 620-8990
  Reston, VA 22091                        (703) 620-0913 (fax)
-----------[000319][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 12:58:29 GMT
From:      mckee@MITRE.MITRE.ORG (H. Craig McKee)
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring BOF at Interop

I just called Phil at (703)620-8990.  He won't be in till later today;
I left a message to read the tcp-ip list.  Regards - Craig

-----------[000320][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 13:36:51 GMT
From:      clynn@BBN.COM (Charles Lynn)
To:        comp.protocols.tcp-ip
Subject:   Re:  Comment on RFC1124 (?)

I'm not a Postscript expert, but from the earlier message it seems
that things would be a lot better if the .ps document didn't try
to justify the words within a line.  Is it "easy" to disable text
justification (leaving fill enabled)?  Are font changes within a
phrase, e.g., titles, a significant problem?

Charlie

-----------[000321][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 13:41:50 GMT
From:      narten@LOVELACE.ALBANY.EDU (Thomas Narten)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

One problem with postscript format documents that I have run into is
that not all printers are 100% postscript compatable.  This is perhaps
an unavoidable situation, because my impression is that 100%
compatable postscript printers are somewhat (though perhaps not much)
more expensive than others because of licensing fees.  Persons paying
for printers may not be aware that 100% compatability is an issue.

I'm very much in favor of postscript documents, but worry that 100%
postscript printers aren't as prevalent is they should be.  Can anyone
suggest a solution to this problem?  Is it realistic to put together a
subset of common postscript commands with an eye on avoiding less
common constructs?  Is there software that massages postcript input to
remove uncommon constructs?

Thomas Narten

-----------[000322][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 13:48:31 GMT
From:      jqj@RT-JQJ.STANFORD.EDU (JQ Johnson)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

A printer language such as Postscript isn't really ideal for the "canonical"
versions of RFCs, though it does allow arbitrary graphics.  It suffers from
not allowing other forms of access, particularly online display on character
only terminals and use with typical character-only text processing tools
like grep.  It doesn't generalize well to hypertext either.

If standards were a bit further advanced, the ideal choice for RFCs would
be a standard markup language (GML? RTF? InterScript? WordPerfect internal
format? troff input?).  Then we could generate whatever display format we 
wanted for it.  They aren't to that point yet, I'm afraid.

What are the NSF Expres project's solutions?  If NSF is willing to accept
something as a grant proposal format, then I'd be willing to accept it for
an RFC.

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

-----------[000323][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 14:39:31 GMT
From:      solensky@interlan.interlan.COM (Frank Solensky)
To:        comp.protocols.tcp-ip
Subject:   Re:  MS-DOS virus rumor


	The following is the text of an article in the September 11 issue of
PC Week, reproduced without edification or explicit permission -- I couldn't
find any sort of copyright message anywhere in that issue, so I assume that
it is legal to distribute this..
						-- Frank Solensky
						   Racal InterLan
=============================================================================

Experts Warn of Datacrime Virus, Plan Prevention
by Evan O. Grossman
-------------
	As the so-called Columbus Day virus nears it critical date, computer-
security experts are recommending a number of preventive measures to stop its
spread.
	To guard against the virus, which is expected to be unleashed in
infected computers on or around Oct. 12, experts are encouraging PC users to
manually check their new and existing .COM files for corruption and to
implement special security software that protects files against the strain.
	The virus replicates through the execution of infected .COM files
found in system utilities.

Imported from Europe
	The Columbus Day virus, also known as the Datacrime virus, is one of
the first to target MS-DOS computers.  It was reportedly unleashed a few months
ago in Europe and has recently begun to attack some PC sites in the United
States.
	The damage occurs when a contaminated program causes the virus to
destroy data on a hard disk's track 0, requiring that the disk be reformatted
with a low-level formatting program, experts said.
	"It's nasty and it's well-written.  You need to take extraordinary
measures right now in order to stop it," warned Tom Patterson, senior analyst
for security operations at Centel Federal Systems Corp., a systems integrator
in Reston, Va.
	To ensure that none of his company's computers are infected, Patterson
has manually checked the length and content of every .COM file to make sure
that they're free of the virus strain.
	The virus adds either 1,168 or 1,280 byt5es to the files it infects,
so users can guard against the contamination by checking a file's true length
against their original DOS master disks, computer-security experts said.  The
virus does not attack COMMAND.COM or any other .COM file whose seventh
character is a "D".
	Patterson and other security experts suggest that once a particular
computer has been found to be uncontaminated, any software that is installed
thereafter should first be examined on a secure system.
	Centel is also developing software that searches disks for the
Datacrime virus' code, but Patterson warned that users should not limit their
preventive measures to this software, since it is not designed to detect other
strains.
	Users who want to take the highest security precautions can use special
software, such as Comsec-II from American Computer Security Industries Inc.
(ACSI), which can make all .COM files execute-only, thereby eliminating the
danger of the infection.
	Such security software can also run special "checksum" tests on files
to make sure that they haven't been modified, according to Winn Schwartau, of
ACSI in Nashville, Tenn.


Accompanying the article is a diagram with the main points in the article:

Diagnosis and Prevention of the Datacrime "Columbus Day" Virus
Symptoms:
  .COM files (other than COMMAND.COM) increase in size by 1,168 or 1,280 bytes.
Prognosis:
  When an infected program is run on or after October 12, the virus will make
  data stored on the hard disk inaccessible.
Rx:
  . Regularly check that all .COM files are the appropriate length.
  . Test all .COM programs on a secure computer before allowing their use on
    other systems.
  . Run security software that restricts .COM files to execute-only.
  . Backup data files regularly, just in case.

-----------[000324][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 14:47:20 GMT
From:      mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

Vint:

As it would capitalize on the advantages of "desktop publishing", may I
suggest that the IAB acquire for each Internet site a software and hard-
ware suite so that we can have the RFCs in one standard format.

While we maintain a directory of the RFCs on one of our systems, very few
copies are ever printed which seems to me to be what PostScript is all
about.  Most people reference the documents online with whatever VT100 or
compatible terminal that is sitting on their desk.

I can order, almost, any software and hardware that I want for delivery to
a customer; however, a "desktop publishing" system to read RFCs out of the
capital budget would get me nominated for "Comic of the Year" by the bean
counters.

Merton

-----------[000325][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 15:00:47 GMT
From:      bkc@OMNIGATE.CLARKSON.EDU (Brad Clements)
To:        comp.protocols.tcp-ip
Subject:   Re:  Comment on RFC1124 (?)

Karl Auerbach has proposed that postscript RFC's be banned, presumably because
trying to index keywords in a postscript file is a pain, and not because 
he feels that postscript printers are too obscure. (is that right?)

I don't mind postscript format, but I think the question of keyword indexing
should be addressed. 

It would be useful if authors of any document that is shipped in postscript
were to add a postscript prologue to the file with the proper keyword indexes.

A standard postscript prologue goes something like;

%%Begin Keywords
%%topic: interfaces checksum rfc1001 netbios smb
%%relatedto: udp ip rfc1002 
%%End Keywords

By standard, I mean the double % and the begin and end blocks. I probably
don't have the version 2.0 ESPF format quite right, but the idea is the same
anyway.

It'd be easy to strip out sets of keywords (do we need an RFC to describe the
standard for key words?) and items prefaced by % won't upset the postscript
printer either.


comments?


| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clutx.bitnet 
| Network Engineer       Clarkson University              (315)268-2292
 ------------------- Meet me at Interop '89 ---------------------------------

-----------[000326][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 15:22:59 GMT
From:      SNSTR@TTUVM1.BITNET (strickland)
To:        comp.protocols.tcp-ip
Subject:   Re: TELNET RFC?

>Can someone please send me a copy of the TELNET RFC? If not
>could you please tell me where I could get a copy of it?
>
>Many thanks in advance...

You can send mail to LISTSERV@TCSVM.bitnet with a single line in the body...

GET RFC854 LISTING

-----------[000327][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 15:53:14 GMT
From:      jarmond@ingr.com (Don Jarmon)
To:        comp.protocols.tcp-ip
Subject:   SLIP

I am looking for a source for SLIP public domain software.

-- 
          Don Jarmon         ...uunet!ingr!b8!dj4104!don      (UUCP)
       ( 205 ) 772-4104         b8!dj4104!don@ingr.com      (INTERNET)
  * Intergraph Corp., One Madison Ind. Park, Huntsville, Ala, 35807-4201 *

-----------[000328][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 16:03:26 GMT
From:      emv@math.lsa.umich.edu (Edward Vielmetti)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

It is clear from the postscript output that the source for RFC1124
was a troff document, with some simple tbl tables in it.

I can understand the need to use postscript to cope with complex
documents, but in this particular case it should be easy to produce
an ascii RFC1124.

--Ed

ps.  Or at least let loose the troff file.

-----------[000329][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 16:07:39 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Checksum Byte Order...What is it?

Adnan Yaqub:

Please see RFC-1071 on "Computing the Internet Checksum".

--jon.

-----------[000330][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 16:12:54 GMT
From:      postel@VENERA.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   TELNET RFC?

Thomas E. Bernhard:

Send a message to "SERVICE@NIC.DDN.MIL"  with subject "RFC 854".

--jon.

-----------[000331][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 16:15:51 GMT
From:      martillo@cpoint.UUCP (Joachim Carlo Santos Martillo)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

In article <5446@asylum.SF.CA.US> karl@asylum.SF.CA.US (Karl Auerbach) writes:
>RFC1124 came out with a discussion of policy issues of interconnected
>networks.  Interesting and important stuff.
 
>Now, it seems, according to RFC1111, that postscript is OK for RFC's,
>(including postscript that was obviously generated by a word or text
>processor.)
 
>So: can anyone make reasonable comment on stuff that looks like what
>follows?  Can anyone do a reasonable machine-based content search?
>Can I send it though my automated indexing tools?  Can I make a
>nice e-mail reply with appropriate selections for context?
 
>No.
 
>I thought we were working on communications, not obfuscation.
 
>I propose that we ban postscript RFCs.
 
>			--karl--

The logic of Auerbach's proposal is compelling.  As Prime Computer
Corporation began self-destructing, part of this self-destructing
evinced itself in the lack of communication between different groups
within the company.  This lack of communication was aided by the
increasing non-uniform use of PC word processors on MAC's and IBM
clones to produce important documents, memos and PET's instead of the
uniform use of scribe+plain text on the 50 Series machines.

I should also point out that not all of us have postscript printers or
postscript software+supported non-postscript printers RFC's should be
available at the archive machines in a plain-text format.

Now I know that writing an RFC with a PC word processor is a lot nicer
than using an editor on most Unix-based machines or minis.

Fortunately, PC word processors like MS-Word and WordPerfect have a
plain-text output mode.  Utilities like The Software Bridge permit
conversion of other word processor files to MS-Word or WordPerfect
readable format.  It should also be possible (if it has not already
been done) to hack up a postscript interpreter to output plaintext to
a file.

Hence, even for someone using a PC word processor, there is no
necessity to submit RFC's in postscript format.

There might be some value to maintain a postscript format RFC archive
somewhere but we should remember a great RFC will be great in
plaintext while a piece of garbage will still be a piece of garbage no
matter how beautifully a postscript printer can output it.

Joachim Carlo Santos Martillo

-----------[000332][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 16:23:13 GMT
From:      cire@CISCO.COM (cire|eric)
To:        comp.protocols.tcp-ip
Subject:   FDDI and TR BOFs


A final note with the resolution between the conflicting meeting times...

IP in Bridged environments - Wednesday Oct 4 5-8pm

FDDI MIB - Thursday Oct 5 6-8pm

TR-FDDI/Ethernet Addressing Issues - Thursday Oct 5 6-8pm


Further announcements if any for the TR-FDDI/Ethernet Addressing Issues
will be done via direct mail.  Send me mail if you wish to be included.

See you there.

-c

-----------[000333][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 18:33:29 GMT
From:      fin@UF.MSC.UMN.EDU ("Craig Finseth")
To:        comp.protocols.tcp-ip
Subject:   Comment on RFC1124 (?)

It is probably worth pointing out that Postscript is a representation
targeted to the task of rendering a document as an image.  In itself,
it does not contain enough information to enable a program to
mechanically produce a "reasonable ASCII" form of the document.

Note that is is possible to extend Postcript so as to include this
additional information using comments and/or special operators, but
such a solution is not currently supported.

I would also like to mention that, as the ASCII form will no doubt be
wanted by more than one person, it only makes sense for the original
author to perform such conversion once.  (As an added plus, the author
can then excercise quality control over the ASCII form.)

As the Postscript advantages are more for diagrams than running text,
why not offer a separate .PS file with just the diagrams?  I have seen
this done on several documents around the net, and it works pretty
well.  The following files would then be offered:

	RFCnnnn.TXT	ASCII form as usual, with crude drawings
	RFCnnnnILL.PS	Nice, Postscript versions of the drawings
	RFCnnnn.PS	Postscript form of the whole thing

(Yes, I realize that the ASCII form of the drawings is somewhat
difficult to do and not going to work as well, but in general such
drawings should be only a small fraction of the work involved with
producing the RFC.)

As a test case, could we ask the authors of RFCs 1119 and 1124 to come
up with the ASCII versions?

Craig A. Finseth			fin@msc.umn.edu [CAF13]
Minnesota Supercomputer Center, Inc.	(612) 624-3375

-----------[000334][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 19:01:57 GMT
From:      karl@asylum.SF.CA.US (Karl Auerbach)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

There are really two distinct issues on the postscript RFC issue.

One is the mere readibility of the document -- I would guess that many
(but I am sure not all) have access to postscript printers of one sort
or another.  (Although it must be noticed that some things which fit
legally into the postscript form are really bit-mapped files from
tools like Tex, etc, and tend to be printable only on printers with
lots of memory.)

The second, and to me much more important issue, is that postscript
hides the content in lots of directives.  One simply can't apply any
sort of text based tools to digest, correlate, index, or even grep the
contents.

I do believe that we need a means to have better documents, including
good images.  And I can see mixed documents which have text mixed with
postscript pictures.  I can even see postscript wrapped text, BUT it
must be without the mass of directives which are injected by typical
word processors.

My suggestion is, hang onto your hats, to use the ASN.1 body part
definition from X.400.  Using that you can cleanly separate text from
postscript from digitized voice from fax from ...  And the ASN.1 isn't
painful when used in this limited sense (and with some sensible
limitations on the use of constructors, etc).  [The reason I like
ASN.1 is that it was designed for precisely this purpose -- mixed
media representation.]

				--karl--

-----------[000335][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 19:12:39 GMT
From:      shepperd@dms.UUCP (Dave Shepperd)
To:        comp.protocols.tcp-ip,comp.unix.xenix
Subject:   TCP/IP network "crash"


Is it just my network, or are all TCP/IP Ethernet networks so "fragile"?

It seems anybody can write a program to open a socket connecting to a 
remote node then do something to lockup the network on both systems.
Sometimes I've noticed that this can even bring down the network on
nodes not involved in the connection.

We're doing X window development using the X11R3 distribution on several
Xenix/386 systems using NCD X window servers all running TCP/IP over Ethernet.
It happens all too often to accidentally do something with X which will
knock the 386's off the network. Whatever happens (I don't know what it
is), isn't always fixed by just restarting the network on the first system
to die. Sometimes I've had to stop and restart the network on the 386's
and ALL the servers. This is icky.

Unfortunately, I don't have a network analysier or any promiscious mode
software to see what might be happening on the wire, but I do have
transceivers with leds indicating send/receive traffic. They don't
indicate anything different than they normally do during one of these
crashes. I.e., they don't go into steady send or receive and there are
no more collisions than normal (collisions are pretty rare in any event).

There is also DECnet, LAT and LAVC traffic on the same wire which has
apparently never been affected by any of the IP traffic even during one of
these crashes. There are some non-Unix boxes on the net that speek TCP
as well as one of the VMS Vaxen. Their network doesn't crash or get
stuck when one of the Xenix systems network dies, but the TCP on VMS
can be crashed by opening a socket and doing something incorrectly.

I should point out that there has never been any messages produced by
the TCP software on the console during one of these crashes, so how
does one go about figuring out what the hell is happening?

Thanks for any help anyone can provide.


-- 
Dave Shepperd.	    shepperd@dms.UUCP or motcsd!dms!shepperd
Atari Games Corporation, 675 Sycamore Drive, Milpitas CA 95035.
(Arcade Video Game Manufacturer, NOT Atari Corp. ST manufacturer).

-----------[000336][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 20:09:30 GMT
From:      ihm@NRC.COM (Ian H. Merritt)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

karl@asylum.SF.CA.US (Karl Auerbach) says:
>RFC1124 came out with a discussion of policy issues of interconnected
>networks.  Interesting and important stuff.
>
>Now, it seems, according to RFC1111, that postscript is OK for RFC's,
>(including postscript that was obviously generated by a word or text
>processor.)
>
>So: can anyone make reasonable comment on stuff that looks like what
>follows?  Can anyone do a reasonable machine-based content search?
>Can I send it though my automated indexing tools?  Can I make a
>nice e-mail reply with appropriate selections for context?
>
>No.
>
>I thought we were working on communications, not obfuscation.
>
>I propose that we ban postscript RFCs.
>
>			--karl--
>
>Selection from RFC1124:
>
>727 789(Computer)U
>1039(networking)S
>1391(has)S
>1511(become)S
	.
	. (Most of this is omitted here)
	.

>2131(three)S
>2299(phases.)S
>2557(The)S
>2693(\256rst)S
>2829(phas)S


I just sent a note to the NIC about that one, suggesting that at least
if PostScript RFC's are to come out, that a plaintext grep'able
version accompany it.  Here is their response:

<From NIC@NIC.DDN.MIL Mon Sep 25 12:03:02 1989
<Return-Path: <NIC@NIC.DDN.MIL>
<Received: from NIC.DDN.MIL by nrc.com (4.0/NRC-DDN1.1)
<	id AA00386; Mon, 25 Sep 89 12:02:56 PDT
<Date: Mon, 25 Sep 89 12:03:02 PDT
<From: DDN Reference <NIC@NIC.DDN.MIL>
<Subject: Re: rfc1119
<To: ihm@nrc.com
<Cc: NIC@NIC.DDN.MIL
<In-Reply-To: <8909181603.AA06258@nrc.com>
<Message-Id: <12529118419.30.NIC@NIC.DDN.MIL>
<Status: RO
<
<Ian,
<
<I'll let Postel answer this one. We have been working with Postel to encourage
<him to provide text RFCs whenever possible.
<
<Regards,
<Sol for the NIC
<-------

Jon?  Care to comment on this?

Until utilities exist to allow meaningful grep'ing (or equivalent)
through PostScript or TeX documents; until EVERYBODY concerned has
workstations with PostScript AND TeX browsers (i.e. don't need to
waste paper to read or time to visually search), I believe we don't
want documents in this forum, one of the best features of which was
online retrieval, to come out in cryptic form without at least an
accompanying plaintext version.  Ok, so mathematical equations and
cute little graphic figures won't be as pretty; we've done OK until
now. At least we'll be able to read them without trying to dig up a
PostScript printer, and we'll be able to have the COMPUTER do the
searching for things in our RFC libraries, as we have always done.

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

-----------[000337][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 20:24:59 GMT
From:      ihm@NRC.COM (Ian H. Merritt)
To:        comp.protocols.tcp-ip
Subject:   Re: Checksum Byte Order...What is it?

adnan@sgtech.UUCP (Adnan Yaqub) says:
>I have a question about the byte order of TCP/IP checksums.  I was
>looking through the Berkeley code, and it seems to me that the byte
>order of the checksum is not adjusted for depending on the "endianish"
>of the host.  For example, I see the following code:
>
>		ip->ip_len = htons((u_short)ip->ip_len);
>		ip->ip_off = htons((u_short)ip->ip_off);
>		ip->ip_sum = 0;
>		ip->ip_sum = in_cksum(m, hlen);
>		error = (*ifp->if_output)(ifp, m, (struct sockaddr *)dst);
>
>Since the checksum is a 16-bit quantity, it would see to me that one
>would get a different value depending on whether the host is big or
>little endian.  I looked at in_cksum_c (I don't have a copy of
>in_cksum), and it doesn't seem to be endian sensitive.  (I may be
>wrong, because the code is quite tricky.)
>
>On the experimental side, I wrote some code to send out UDP datagram
>with the checksum passed through htons.  The result was that the
>receiving host (an Excelan network analyzer) said the checksum was
>wrong.  I sent XXYY and it wanted YYXX.  So, how should the checksum
>be sent?
>--
>Adnan Yaqub
>Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860
>...cwjcc!ncoast!sgtech!adnan ...uunet!abvax!sgtech!adnan


The definitive document on this is RFC1071.  In case you don't have it,
excerpts follow:

   In outline, the Internet checksum algorithm is very simple:

   (1)  Adjacent octets to be checksummed are paired to form 16-bit
        integers, and the 1's complement sum of these 16-bit integers is
        formed.

   (2)  To generate a checksum, the checksum field itself is cleared,
        the 16-bit 1's complement sum is computed over the octets
        concerned, and the 1's complement of this sum is placed in the
        checksum field.

   (3)  To check a checksum, the 1's complement sum is computed over the
        same set of octets, including the checksum field.  If the result
        is all 1 bits (-0 in 1's complement arithmetic), the check
        succeeds.

        Suppose a checksum is to be computed over the sequence of octets
        A, B, C, D, ... , Y, Z.  Using the notation [a,b] for the 16-bit
        integer a*256+b, where a and b are bytes, then the 16-bit 1's
        complement sum of these bytes is given by one of the following:

            [A,B] +' [C,D] +' ... +' [Y,Z]              [1]

            [A,B] +' [C,D] +' ... +' [Z,0]              [2]

        where +' indicates 1's complement addition. These cases
        correspond to an even or odd count of bytes, respectively.

        On a 2's complement machine, the 1's complement sum must be
        computed by means of an "end around carry", i.e., any overflows
        from the most significant bits are added into the least
        significant bits. See the examples below.


		.
		.
		.


     2.  Calculating the Checksum

        This simple checksum has a number of wonderful mathematical
        properties that may be exploited to speed its calculation, as we
        will now discuss.


   (A)  Commutative and Associative

        As long as the even/odd assignment of bytes is respected, the
        sum can be done in any order, and it can be arbitrarily split
        into groups.

        For example, the sum [1] could be split into:

           ( [A,B] +' [C,D] +' ... +' [J,0] )

                  +' ( [0,K] +' ... +' [Y,Z] )               [3]

   (B)  Byte Order Independence

        The sum of 16-bit integers can be computed in either byte order.
        Thus, if we calculate the swapped sum:

           [B,A] +' [D,C] +' ... +' [Z,Y]                   [4]

        the result is the same as [1], except the bytes are swapped in
        the sum! To see why this is so, observe that in both orders the
        carries are the same: from bit 15 to bit 0 and from bit 7 to bit
        8.  In other words, consistently swapping bytes simply rotates
        the bits within the sum, but does not affect their internal
        ordering.

        Therefore, the sum may be calculated in exactly the same way
        regardless of the byte order ("big-endian" or "little-endian")
        of the underlaying hardware.  For example, assume a "little-
        endian" machine summing data that is stored in memory in network
        ("big-endian") order.  Fetching each 16-bit word will swap
        bytes, resulting in the sum [4]; however, storing the result
        back into memory will swap the sum back into network byte order.

        Byte swapping may also be used explicitly to handle boundary
        alignment problems.  For example, the second group in [3] can be
        calculated without concern to its odd/even origin, as:

              [K,L] +' ... +' [Z,0]

        if this sum is byte-swapped before it is added to the first
        group.

Better still would be to obtain a copy of the whole document.
Good luck.
	-i
-- 
US Snail:	2380 Rose Avenue; Oxnard, CA  93030  U.S.A. tel. 805-485-2700
InterNet:	ihm@NRC.COM

-----------[000338][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Sep 89 08:13:28 -0700
From:      Marshall Rose <mrose@cheetah.nyser.net>
To:        tcp-ip@NIC.DDN.MIL
Cc:        minor.lists:;
Subject:   STATUS REPORT: NYSERNet White Pages Pilot Project
Hi.  You might recall having seen a message three months ago when
NYSERNet started a pilot project in providing White Pages service.
Using White Pages, you can get e-mail, postal, or telecommunications
information about someone you wanted to contact.

The idea was to use the TCP/IP and the Internet to provide the transit
backbone, the OSI X.500 Directory to provide the underlying technology,
and then to build a White Pages "abstraction" on top of this.  Although
the pilot was focused on sites in the NYSERNet regional network, other
Internet sites, if interested, were allowed to join.

Anyway, as of this morning, we counted 98,417 entries in the White
Pages from 25 sites, primarily from University sites, although some
corporate sites are also participating.  To my knowledge this makes this
pilot the largest nameservice in the Internet, easily the largest OSI
pilot in Directory, and easily the largest use of OSI services in the
Internet.

As you might imagine, over the last 90 days a lot of code has been
broken and fixed, and a lot of things have been (re-)learned.  The pilot
will run until June of next year, when I hope to have an order of
magnitude more data available.  Of course, there's a lot of hard work
between now and then (sigh).

If you are interested in poking around, telnet to

	wp.nyser.net

and login as

	fred

this will provide you with a White Pages shell.  Keep in mind when using
this service that it is highly distributed but not fully replicated yet
(something to be addressed in the next couple of months).  As such,
network and host outages may cause variable delays in service.  If you
have any problems with the service, IMMEDIATELY drop a line to 

	wpp-manager@nisc.nyser.net

noting the date/time of the problem, the command(s) you issued, etc.

/mtr

ps: the 98K figure is short, there are some sites, which do not allow
full counting of the number of entries they have in the Directory.

pps: if you'll be at the Industry-event INTEROP 89 next week, there will
be a birds-of-a-feather on White Pages on Wednesday at 6:00pm.
-----------[000339][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 20:41:00 GMT
From:      ljm@TWG.COM (Leo J McLaughlin)
To:        comp.protocols.tcp-ip
Subject:   Re: RFC Compliant NetBIOS & ULANA


>Maybe someone out there in the Internet can provide some insight...    
 
>1)  Is there any reason whatsoever (one word?) to use an RFC 1001,1002 
>compliant NetBIOS?

Heterogenous networks (sorry, two words).

More seriously, NetBIOS was (is?) the only networking interface for DOS
supported by many different vendors -- as a result, most PC networking
applications which use networking use NetBIOS.  It would be nice if all
those applications could be used on machines other than PCs.  If a readily
available TCP/UDP/IP based protocol stack for DOS with an interrupt
accessable API had existed in 1982 and had been used as the basis for PC
networking products (instead of XNS and later the NetBIOS-NetBEUI standard),
none of the this would be necessary.  But it didn't happen that way.

>This means you're buying more expensive hardware or using lots of host (PC) 
>memory and receiving poorer performance because of the protocol overhead.     

Our session NetBIOS over TCP/IP over a dumb board uses 50K and our SMB
client over it moves data at 250K/second.  Admittedly neither number is
optimal, but it isn't that bad for a TCP without header prediction.
 
>2)  Why hasn't the ULANA program recognized the above problem?...
>3)  One of the ULANA CLINs is to provide specification compliance testing
>for third party products.  Has this ever been exercised?  How does one get
>a compliant product on the APL?  How can we help the government save money
>(ours!) on this program?   Am I just ------- in the wind?

Don't know.
 
enjoy,
leo j mclaughlin iii
The Wollongong Group
ljm@twg.com
 

-----------[000340][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 20:42:31 GMT
From:      rdroms@NRI.RESTON.VA.US
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)


Comments on suggested solutions:

  o Keep RFCs in a text-only format, and provide hints to a PostScriptizer
    that knows what parts of the text should be filled, what parts of the
    text are actually character graphics (like | and - ), and what parts
    are tables.

PostScriptizing an ASCII RFC doesn't sound like much of a win - you've
already lost all the graphics info ... there's nothing to reconstruct.

  o Restrict the types of PostScript that are acceptable to those that can
    be textized by running them through a filter.  That way, a user can
    reconstruct a reasonable text version of the RFC.

Reverse engineering ASCII from PostScript sounds like an interesting,
but hard, problem.  You'll need to guess what parts are straight
ASCII, and can be re-paragraphed, what parts are tables and must be
left verbatim, and what parts are graphics and must be approximated
with ASCII text.

It is clearly advantageous to have the ability to view and search
through RFCs on-line.  For the time being, we might want to try a
fourth solution:

  o Require the author to submit an ASCII version of the RFC - and
    allow an optional PostScript version.

nroff/troff solves the problem by using two translators - nroff
generates ASCII and troff generates PostScript from the same course.
Is there a version of nroff that behave rationally when confronted by
grpahics (e.g., pic output) input?  Is there an equivalent to nroff
for TeX?

- Ralph Droms                             (On leave from Bucknell University)
  NRI                                     rdroms@nri.reston.va.us
  1895 Preston White Drive, Suite 100     (703) 620-8990
  Reston, VA 22091                        (703) 620-0913 (fax)

-----------[000341][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 22:19:23 GMT
From:      lehners@uniol.UUCP (Joerg Lehners)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

zweig@brutus.cs.uiuc.edu (Johnny Zweig) writes:
>It seems the best thing to do is to put PostScript stuff _somewhere else_. I
>like being able to do "lpr RFCxxx" and have the right thing happen -- and I
>imagine people who don't have PostScript printers around would be even more
>adamant on the point.
Same with me, except I don't print the RFC often.
I almost all time just do an 'more Rfc/Rfc<some-number>' to look up
some details.
Printouts get lost too often. And what about looking up words.
I would like to be able to do for example: 'grep TTL Rfc/rfc*'.

>It seems that complicated drawings ought to go into some kind of companion
>document that would be referenced (with good old [1]...[n] in plain ASCII)
>in the RFC-proper.
 
>I think that one can go a long way with  - + | _ / \ < and >. Certainly
>anything that can't be described without a comlicated drawing ought to be
>rephrased. A picture may be worth a thousand words, but a standard should be
>clear enough not to need thousands of words.
Yes. I really like the drawings in rfc793. It's good enough and visisble on
every character only terminal. For details see the Text !

What about that:
Let all RFCxxxx and the new in the old style, build some
RFCxxxx.ps files for the Postscript-Version. But they should NOT differ
in contents !

  Joerg
--
/ Joerg Lehners                       | Fachbereich 10 Informatik ARBI   \
|                                     | Universitaet Oldenburg           |
| BITNET/EARN: 066065@DOLUNI1.BITNET  | Ammerlaender Heerstrasse 114-118 |
\ UUCP/Eunet:  lehners@uniol.uucp     | D-2900 Oldenburg                 /

-----------[000342][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 22:25:05 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

I agree too.  We have plenty of Postscript printers, but I often want
to look at RFC's from inside Emacs, like when I'm working on software,
or answering a question that requires me to refer to an RFC.  If we
get to the point where we can assume that everybody is using a
workstation or X terminal, I'd be willing to consider a document
format that could only be displayed on such a beast.  I'm afraid
that's a few years in the future.  I do not want to be told that I
have to read these documents in hardcopy.

-----------[000343][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 23:02:17 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent Data Handling

The urgent bit is sort of odd.  Your questions suggest that you want
to be able to tell exactly what data is urgent and what isn't.  That's
not really what the original intent was, I don't think.  There are no
"messages" in TCP, nor is there any intent in the spec to define where
urgent data begins, only where it ends.  Urgency is intended to
indicate a condition that takes effect immediately.  Its beginning is
not synchronized with the data stream.  Thus urgent should be set in
the next datagram to be sent, even if it is a retransmission and did
not have urgent set last time.  (This may be hard to implement of
course, and as far as I know is not.  But conceptually it would make
sense, and it would improve some aspects of telnet and rlogin
behavior.)  Furthermore, if two sections of "urgency" are adjacent,
they may look like one.  Both of the uses of urgent data that I know
-- telnet and rlogin -- are designed with these concepts in mind.
This means that the concept of "urgent message" is not well defined.
Only the concept of "last urgent byte" makes any sense, and with the
off by one fiasco, even that is ambiguous.  I would suggest that you
*not* try to "clarify" urgent, but stick with the 4.3 semantics.
Anyone who needs urgent "messages" should arrange to delimit the
messages by some sort of marker in the data.

-----------[000344][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 23:09:45 GMT
From:      hedrick@geneva.rutgers.edu (Charles Hedrick)
To:        comp.protocols.tcp-ip,comp.unix.xenix
Subject:   Re: TCP/IP network "crash"

Your software is buggy.  Now and then we've run into implementations
where for some reason or other the software hung.  These have
generally been new implementations.  Such bugs were regarded
(correctly) as serious problems, and fixed.  It's also possible that a
bug or misconfiguration has resulted in a "broadcast storm".  In that
case, your software isn't hung -- it's just being saturated by lots of
packets.  I would suggest getting one of the MS/DOS TCP/IP
implementations, and running netwatch.  That should show you what is
going on if it's a broadcast storm.  If it's a fragile Ethernet device
driver, looking at the net may not shou anything.  Probably that can
only be debugged if you have source to the software.

-----------[000345][next][prev][last][first]----------------------------------------------------
Date:      28 Sep 89 23:30:10 GMT
From:      sra@lcs.mit.edu (Rob Austein)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

Vint,

GNU Emacs, at least, has a major mode called "picture" which somewhat
eases the task of drawing pictures in ASCII.  It's not perfect, and
could use some further development, in particular to do useful things
with mice, but it's a start.

I agree with Karl completely.  I haven't got the room to keep an
entire hardcopy RFC manual set in my office, let alone at home, let
alone take it with me when I travel.  Pictures are nice and there are
some things that can be said much more easily with pictures, but I
can't quote chapter and verse of a picture in a mail message (unless
it's in ASCII) and I can't read it to somebody over the phone.  I
think that until the available tools for transmitting arbitrary
pictures become as cheap and available as home terminals are now, the
core of any RFC really ought to remain remain English text.

I would be content with ASCII versions of RFCs which replaced all the
pretty pictures with little boxes that read:

	+-------------------------------------------------+
	|						  |
	|   If you had a PostScript (TM) printer, you'd   |
	|   see a pretty picture here.  You lose.         |
	|						  |
	+-------------------------------------------------+

One other thing.  According to RFC-1111, page 3: "Since PostScript is
not editable, an editable source version of the document must also be
submitted."  This is entirely reasonable.  Perhaps this same editable
source version be made available to the rest of us after the RFC
Editor has performed his office?  This would help somewhat even if the
rest of the question degenerates to an insoluable religious debate.

--Rob Austein, MIT

-----------[000346][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 89 01:25:13 GMT
From:      baker@VITAM6.UUCP (Fred Baker)
To:        comp.protocols.tcp-ip
Subject:   MAC BOFs

May I suggest that the folks going to the FDDI or Toekn Ring BOFs look at
IEEE 802.1A Rev 8, which has passed TCCC and is well on the way to being an
ANSI Standard.  This specifies (section 5.2.1) how a MAC address should
be encoded when found at a layer above the MAC.

The principal part of the problem with bit ordering relates to the fact
that end stations DO encode MAC addresses in layers other than the MAC -
ARP and XNS IDP for example.  Building an 802.3/802.5 bridge is significantly
complicated when the ES must know that the device it is addressing may
be specifying its address in an ARP response in the reverse order from the
way the receiving station needs to use them.

The most elegant enswer - IEEE's - is to specify a generic format, and
require the MAC layer to swap them at its interface if it needs to.  Anything
else forces the bridge to understand all possible protocols and swap them
in the HLL headers as well in at least some cases.

I can bring some copies to the meeting if people need them - send me a
request at:

Fred Baker
baker@vitalink.com

-----------[000347][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Sep 89 09:21 MST
From:      Terry Wimmer <WIMMER@rvax.ccit.arizona.edu>
To:        TCP-IP@SRI-NIC.ARPA
Subject:   RE: UNINTERRUPTED POWER SUPPLY (UPS) SYSTEMS

I've always had good luck with these systems.

CLARY CORP
320 W. CLARY AVE
SAN GABRIEL, CA 91776
(818) 287-6111

UPS FROM 360VA TO 37.5 kVA
On-line, Sinewave output
rack-mountable up to 3 kVA



DISCLAIMER:
I HAVE NO RELATIONSHIP NOR DIRECT ENVOLVMENT WITH CLARY CORP.



-----------[000348][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Sep 89 12:07:54 CST
From:      steve <SNSTR%TTUVM1.BITNET@ricevm1.rice.edu>
To:        TCP-IP <TCP-IP@SRI-NIC.ARPA>
Subject:   Re: LAN adapter for IBM 3081
>>	We decided that the time had come to get a real, supported,
>>IBM 8332 LAN channel station. After all, we should have a supported
>>ethernet adapter. We were so serious about it that we got a quotation.
>>The quotation was....
>
>>		SEVENTY-SEVEN THOUSAND DOLLARS
I assume you mean 8232 rather than 8332.  IBM sells the
8232 lan channel station model 1 for $17,560, which with
the average educational discount comes to about $14,500.

Still pricey for what you get, but not nearly $77k.
-----------[000349][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 89 11:00:02 GMT
From:      epsilon@wet.UUCP (Eric P. Scott)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

In article <5446@asylum.SF.CA.US> karl@asylum.SF.CA.US (Karl Auerbach) writes:
>I propose that we ban postscript RFCs.

Where have you been?  PostScript has been the de facto standard
for FTPable documents for quite some time.  IMHO, PostScript RFCs
are long overdue.  More please!

I still have hardcopy RFCs from the days when the NIC mailed them
out.  The text versions pale by comparison.  Now if I can find
textured manilla covers...

					-=EPS=-

-----------[000350][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 89 12:11:28 GMT
From:      mac@proteon.com (Michael A. Curtis)
To:        comp.protocols.tcp-ip
Subject:   seeking token-ether IP router that does proxy ARP to the ether

Tom,

     Where are you??  I'll be happy to send you some information.

Mike Curtis
Proteon, Inc.

-----------[000351][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 89 12:34:05 GMT
From:      davecb@yunexus.UUCP (David Collier-Brown)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

karl@asylum.SF.CA.US (Karl Auerbach) writes:
| There are really two distinct issues on the postscript RFC issue.
| One is the mere readibility of the document [...]
| The second, and to me much more important issue, is that postscript
| hides the content in lots of directives.  [...]

  Given these two requirements, the implication is that one employ a 
notation that expresses the "directives" in as succinct and identifiable
a way as possible. One can then:
	1) read the document in editable form, ignoring the 
	   occasional directive,
	2) process the document into final form, evaluating 
	   the directives, or
	3) process the document into an approximation of the
	   final form, with placeholders used for things which
	   cannto be represented (eg, empty boxes for diagrams)

| My suggestion is, hang onto your hats, to use the ASN.1 body part
| definition from X.400.  Using that you can cleanly separate text from
| postscript from digitized voice from fax from ...  And the ASN.1 isn't
| painful when used in this limited sense (and with some sensible
| limitations on the use of constructors, etc).  [The reason I like
| ASN.1 is that it was designed for precisely this purpose -- mixed
| media representation.]

  I'm not religious about which multi-media standard you wish to use,
subject to the requirements above.  SGML subsets, ASN.1 subsets or just
postscript run through a postprocessor to make it readable in its editable
form all meet the requirements.  Which to use is a managment decision, 
based on which standards body we respect (:-)).


--dave
ps: For mere ease of implementation, a requirement that fill-but-no-justify
    be used when creating postscript plus a few sed scripts would probably
    render an editable form that we could live with...
-- 
David Collier-Brown,  | davecb@yunexus, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave 
Willowdale, Ontario,  | Joyce C-B:
CANADA. 416-223-8968  |    He's so smart he's dumb.

-----------[000352][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 89 13:06:39 GMT
From:      aggarwal@JVNCA.CSC.ORG (Vikas Aggarwal none)
To:        comp.protocols.tcp-ip
Subject:   Thinwire vs. Thickwire


Just to collect one's views on Thinwire ethernet vs Thickwire ethernet,
I am listing what I know about the topic:

THINWIRE

	Flexible
	Low cost ( app. $3.00 per meter )
	10 Mb bandwidth
	Max segment length - 185 meters (30 nodes per segment)
	One multiport repeater can handle upto 8 segments

THICKWIRE

	More resilient for running through floors and ceilings
	Higher cost (app $11.00 per meter)
	10 Mb bandwidth
	Max segment length - 500 meters

Based on the above, I would choose thickwire ONLY if the length of the
segment had to be more than 500 mts or if the wire was going to run 
through adverse areas.

Any comments ??

-vikas

-------------------------------------------------------------------------
	JOHN VON NEUMANN NATIONAL SUPERCOMPUTER CENTER


INTERNET: aggarwal@jvnca.csc.org
UUCP:	  rutgers!jvnca!aggarwal
BITNET:   aggarwal@jvncc
--------------------------------------------------------------------------

-----------[000353][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 89 14:59:28 GMT
From:      roy@phri.UUCP (Roy Smith)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)


	One of the recent PS RFCs that came out (NTP) recently was of
interest to me.  Unfortunately, it took me about3 days to get a printed
copy of it.  I tried to display it with NeWS, but my NeWS server just died.
I tried to send it to my Apple LaserWriter, but what I got was several
copies of the front material and none of the rest.  It turned out that it
was actually two PS documents in one file, with some strangeness (I don't
remember the details) with the headers, and I had to manually split the
file into two pieces and make some minor changes to each part, and I
*still* ended up getting multiple copies on my LW, but at least I got it
printed and could hand-assemble the pages so I could read it.

	I got into a bit of a discussion with the author about whether the
fault was in my line printer spooling software or the PS document producing
software he used.  I was left with a bad feeling about the whole thing.  I
agree; PS-only RFCs are not a good idea just yet.  Take an example from
NYSERNet; they distribute PS maps of the network, but they always also have
ascii versions for people who can't deal with PS.
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

-----------[000354][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 89 15:08:27 GMT
From:      guy@guy.uucp (Guy Streeter)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent Data Handling

hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
> ...
>Only the concept of "last urgent byte" makes any sense, and with the
>off by one fiasco, even that is ambiguous.  I would suggest that you
>*not* try to "clarify" urgent, but stick with the 4.3 semantics.
> ...

RFC 1011 - Official Internet Protocols                          May 1987


         Urgent:  Page 17 is wrong.  The urgent pointer points to the
         last octet of urgent data (not to the first octet of non-urgent
         data).

 ...

***DRAFT RFC***          TRANSPORT LAYER -- TCP            June 16, 1989

         4.2.2.4  Urgent Pointer: RFC-793 Section 3.1

            The second sentence is in error: the urgent pointer points
            to the sequence number of the LAST octet (not LAST+1) in a
            sequence of urgent data.

 ...

BSD 4.3 sets the urgent pointer to the LAST+1 octet in a sequence of urgent
data.  Whenever anyone else violates a protocol, the response in this
newsgroup is always "Fix your software!"  Should we propagate Berkeley's
error in the interest of compatibility, or should we do it right?

Guy Streeter
b11!guy!guy@ingr.com
...uunet!ingr!b11!guy!guy

-----------[000355][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 89 15:25:38 GMT
From:      jtw@lcs.mit.edu (John Wroclawski)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)


In article <Sep.28.18.25.03.1989.1289@geneva.rutgers.edu>
hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
(About RFC's in PostScript)

   If we
   get to the point where we can assume that everybody is using a
   workstation or X terminal, I'd be willing to consider a document
   format that could only be displayed on such a beast. 

This and the next several messages in this thread suggest that people
might be happy if they could display PostScript RFC's online.  That
doesn't seem like enough to me -- I haven't seen a PostScript (dvi,
whathaveyou) previewer yet that had search or cut-and-paste
capability.  I think ASCII will be the best choice unless/until there
is some sort of universal WYSIWIG editor description format and a
-whole bunch- of programs that use it.

John Wroclawski - MIT Lab for Computer Science - jtw@lcs.mit.edu

-----------[000356][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 89 15:45:18 GMT
From:      scp@bpa.BELL-ATL.COM (Steve Parowski)
To:        comp.protocols.tcp-ip,comp.protocols.ibm
Subject:   SNA to TCP/IP gateway



Help?

I am looking for information on hardware and software that 
will enable my SNA network to have access  to a TCP/IP network.
The 3270 type terminals should have FTP and Telnet services available
and the the TCP/IP terminal users should have access to a 4381(vm)
running the SNA/SNI.

Mitek is one possibility that I am pursuing. Any Feedback?

Tandem SNAX and TCP/IP with Panoramic CONNECT software is another. Any Comments?

Also buyin a TCP/IP to SNA software from IBM directly and loading it on to the
4381.  I understand that this may create a problem in overhead, but I need 
something more concrete.

-----------[000357][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 89 15:48:44 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

The postscript guys want to use postscript so they can include figures
and other graphical information. How about doing it this way:

Start with some text text text text text text text text text 
more text text text text text text text text text text text text 
and more text text text text text text text text text text 
text text text text text text text text text text text text 
#!some magic line.
P(OSTSCRIPT) TYPE {stuff}
#!some other magic line.

Converting this to something either postscript or text folks can deal
with would be a SMOP.
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"That is not the Usenet tradition, but it's a solidly-entrenched            U
 delusion now." -- brian@ucsd.Edu (Brian Kantor)

-----------[000358][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 89 16:21:00 GMT
From:      WIMMER@RVAX.CCIT.ARIZONA.EDU (Terry Wimmer)
To:        comp.protocols.tcp-ip
Subject:   RE: UNINTERRUPTED POWER SUPPLY (UPS) SYSTEMS


I've always had good luck with these systems.

CLARY CORP
320 W. CLARY AVE
SAN GABRIEL, CA 91776
(818) 287-6111

UPS FROM 360VA TO 37.5 kVA
On-line, Sinewave output
rack-mountable up to 3 kVA



DISCLAIMER:
I HAVE NO RELATIONSHIP NOR DIRECT ENVOLVMENT WITH CLARY CORP.

-----------[000359][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 89 17:07:24 GMT
From:      subbu@hpindda.HP.COM (MCV Subramaniam)
To:        comp.protocols.tcp-ip
Subject:   Re: TCP Urgent Data Handling


>multi-character message is urgent and 4.3 BSD assumes the last byte.  Also,
>4.3 breaks large urgent messages into several segments with the URG bit
>set and the urgent pointer pointing to just past the data *in each segment*.

	4.3 TCP considers only one byte in the message as urgent. Therefore,
	if you call send() with 2000 bytes, the last byte will be considered
	urgent, and the SND.UP pointer will be updated to that value. 
	Thereafter, every packet sent will have the URG flag set, but
	the URP in the packet will be equal to SND.UP. That is, each
	segment will contain the same value of URP in it. I believe 4.2
	used to set URG flag and URP only in the segments in which the
	OOB byte is actually transmitted. (Someone correct me if I am 
	wrong).

>The receiver will believe each segment is an urgent message and each segment
>will override the last saved urgent byte unless inlining is specified.  This
	
	If, however, you call multiple send()s with MSG_OOB, then each
	segment sent will contain one urgent byte, and if the user has not
	received the last OOB byte, it will be overridden with the new one,
	and RCV.UP will be moved past the new URP received.

	The following bugs exist in 4.3 BSD urgent (OOB) data handling:

1.	If you send Out of band bytes *too* frequently, i.e. send the 
	next OOB before the first is acknowledged, then 4.3 BSD TCP leads
	to data corruption (if you don't use OOBINLINE option). 
	[Bug in the sender]

2.	Also, if 4.3 BSD TCP transmits (say) 3 segments and the third one
	had the URG flag set, and the first one got lost, then SND.UP
	gets messed up when the first segment is retransmitted. This, again,
	leads to data corruption. [Bug in the sender]

3.	If segments containing urgent bytes have to be retransmitted, and
	get reassembled in the receivers TCP reassembly queue, data corruption
	could result [Bug in the receiver - Reassembly code]

-Subbu

-----------[000360][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 89 18:07:54 GMT
From:      SNSTR@TTUVM1.BITNET (steve)
To:        comp.protocols.tcp-ip
Subject:   Re: LAN adapter for IBM 3081

>>	We decided that the time had come to get a real, supported,
>>IBM 8332 LAN channel station. After all, we should have a supported
>>ethernet adapter. We were so serious about it that we got a quotation.
>>The quotation was....
 
>>		SEVENTY-SEVEN THOUSAND DOLLARS
I assume you mean 8232 rather than 8332.  IBM sells the
8232 lan channel station model 1 for $17,560, which with
the average educational discount comes to about $14,500.

Still pricey for what you get, but not nearly $77k.

-----------[000361][next][prev][last][first]----------------------------------------------------
Date:      Fri, 29 Sep 89 18:53:10 GMT
From:      henry@utzoo.uucp (Henry Spencer)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

In article <932@manta.NOSC.MIL> budden@manta.nosc.mil.UUCP (Rex A. Buddenberg) writes:
>At the risk of sounding too rational, why don't you employ
>the CALS standards for what they were settled on for?
>(SGML for text, IGES for CAD, CCITT Group 4 for images).

Because only a very small percentage of the intended audience has software
that can understand them, and the purpose of the exercise is supposed to
be communication, not standards conformance for its own sake.
-- 
"Where is D.D. Harriman now,   |     Henry Spencer at U of Toronto Zoology
when we really *need* him?"    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

-----------[000362][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 89 18:55:57 GMT
From:      tkostan@TRWIND.IND.TRW.COM (Tyson Kostan)
To:        comp.protocols.tcp-ip
Subject:   RFC Compliant NetBIOS and ULANA

In reference to some of the comments reguarding TRW's failure to meet
the ULANA performance specifications:

I can only make comments reguarding the TRW products, but not the EDS
products (even though I have personally tested them both).

I would first like to respond to your comments reguarding performance
requirements.  So that those who are listening in may understand what
ther ULANA performance specifications are, let me lay them out:

		100 Packets/Sec with 1K Byte packets with 1 TCP connections open
		120 Packets/Sec with 1 Byte packets with 1 TCP connections open
		70 Packets/Sec with 1K Byte packets with 32 TCP connections open
		84 Packets/Sec with 1 Byte packets with 32 TCP connections open

These may not be realistic requirements (Try to force 1 byte or 1K byte
packets) but a baseline had to be set.  TRW exceeded all of the requirements
listed above.  

	Ty Kostan 
	PC Product Manager
	TRW Information Networks Division
	Ty@trwind.TRW.COM

-----------[000363][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 89 19:34:40 GMT
From:      rwa@cs.AthabascaU.CA (Ross Alexander)
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)


I agree, let's ban (severely deprecate, anyway) postscript RFC's.
I don't have a postscript printer handy - if I want I can print them,
but they're a royal pain on-line.  And they're so **big**!

	Ross

-----------[000364][next][prev][last][first]----------------------------------------------------
Date:      29 Sep 89 23:10:13 GMT
From:      johnny@edvvie.at (Johann Schweigl)
To:        comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc,comp.sys.ibm.pc
Subject:   FTP (the company, not the protocol) required

I am *VERY URGENTLY* searching for the address of FTP (they have TCP/IP
products for the PC). Please can anybody tell me?
Reply by email.
Thanks, Johnny
-- 
       ------------------------------------------------------------------
       EDV Ges.m.b.H Vienna              Johann Schweigl    
       Hofmuehlgasse 3 - 5               USENET: johnny@edvvie.at
       A-1060 Vienna, Austria      Tel: (0043) (222) 59907 257 (8-19 CET)

-----------[000365][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 89 00:01:50 GMT
From:      dbs@hprnd.HP.COM (Dave Sheehy)
To:        comp.protocols.tcp-ip
Subject:   Re: Token Ring BOF at Interop


Will you write up a summary of the discussions and post it here? I won't
be going but am very interested in what comes out of all this.

Dave Sheehy
(916) 785-4012

-----------[000366][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 89 02:07:36 GMT
From:      sob@harvisr.harvard.edu (Scott Bradner)
To:        comp.protocols.tcp-ip
Subject:   Router tests v2.5

TCP/IP Router Tests, v2.5

I got a phone call the other day.  Wellfleet now could bring in
one of their routers for testing.  A bit last minute, but since I wanted to
update the Wellflee numbers before heading out to INTEROP, I said
ok.  The box complete with VP showed up 2 days later.  The elves out there
in Welfleet land had been doing their homework; this box is fast.

I was going to post only the new Wellfleet numbers but then I'd get
1000s of "I did not see your v2 posting, can you ...".  So, I've
edited the v2 posting to include the Wellfleet figures, renamed it v2.5
and now send it along.  (Easer for me even if a bit of extra load on the net.)

This testing game is getting harder, I just gotta get back to work
on the new "be all to end all" hardware. (and get ready to test FDDI)

Scott

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

Well here we go again.  I've just finished another batch of tests on
some routers.  There is real data later on in this posting but first
what was tested, how it was tested and other miscellany.

The info in this posting was first presented at the IBM user's group
SHARE last month. (parenthetical aside, don't give me a hard time
about the venue for the talk, once upon a time IBM & TCP/IP did not
quite see eye to eye and that problem may still be there with some
other 3 letter companies & their 3 letter operating systems, but
in the last few years IBM has done much to introduce TCP/IP products
for its line of computers and many of these products have evolved
into packages that are quite good - now if only the salesmen could
learn how to spell TCP/IP :-) ), copies of the slides for this 
talk can be ftp'ed from husc6.harvard.edu, look in the pub/rtests
directory.  Retrieve the README to find out what is what.

For those of you going to INTEROP, I've been asked to give the SHARE
talk again as a BOF (Wed at 2:30). Come give me a hard time if you
think it is warranted.

I asked all of the companies that 1) producing routers that support
TCP/IP & 2) I could find a phone # for, if I could get a router from
them for 2 days of tests ( I told them 2 days but most of the tests 
took longer than that ), I asked for a router & SE who could set it
up for one day & just the set-up router for the 2nd day.  I asked for the
SE so there would be no way that it could be claimed that we had set
things up wrong.

A number of companies responded "we will get back to you" or "yes,
we will get back to you" and when the time came, the router did not.
I will admit that I gave some of the vendors very short notice and
that was a legit reason for some, an excuse for others.  What I did get
were boxes from cisco, Network Systems, Proteon and Wellfleet.  We beat
up on these quite a bit and found problems with most of them.  And for
all of them we reported the problems, got to talk to people that knew
what they were talking about and were able to give us assurances that the
problems were understood and in most cases fixed.  We did get follow up
software for cisco & Proteon that did fix many of the problems found.

I'm going to be a bit of a pain here and not tell you all what some of the
problems were since some of them can be used to easily crash a router,
some times in ways that would require someone to manually power cycle
before it would work again.  The problems that fit into this category
are fixed in software that we have tested or that we are assured will
be shipped "any day now".  Publishing what these problems are could 
lead to some crashing of NSF regional nets and that can get to be 
a bit of a drag.

What should be tested?  

All we really tested were the  things that were easy to test,
max throughput under various router setups and various basic
measurements.  What we did not test was something that looked
like a version of the real world.  The real world has many routes,
we had one, the real world has many source-destination sets,
we had one etc.  These tests were done on the cheap, they will
be redone later with additional capabilities.
We tested devices that provided ethernet to ethernet TCP/IP
routing.  We would have liked to test other things like the 
PC based router that has been floating around the net and
the use of a minicomputer, like a microvax or a sun, as a router,
but did not get to it, next time.

Next time we will also include bridges in the tests.  If you people
out there in netland have specific suggestions about tests and/or
devices please let me know.

well, on to the test setup.

We (actually, Dan Lanciani) put together software that runs using
a Micom Interlan NI5210 in a IBM PC/AT. The software made use
of some of the Intel LAN chip's features to
produce packets at a reasonable rate.  We could not get the
interpacket intervile shorter than 55 usec, far longer than the
spec's 9.6 min, so the max packet rate was not up to what it 
should have been, but, I hope, still useful.

(We are working on new hardware to do better, and will redo these tests
about November, by better I mean 9.6 usec gap )

The LAN chip works on a linked buffer list of packet descriptors
to use, if one points the last one at the first one, one has a loop.
(you say that coming, didn't you?)  We just set things up so that
a packet in the loop was addressed to the router and the other
packet was addressed elsewhere and then adjusted the size of the
"other" packet to get the desired packet rate to the router.
(The new hardware will do it right & vary the ipi. ) The software
that was used to run this is named "hammer", don't run it on a live
network.

The other end of the router was attached to a Tandy PC clone with another
NI5210.  This one was put into resource exhaustion mode ( i.e. it
was made to think that there was no place to put incoming packets ).
When the chip gets a packet that it does not have space for, it tosses it
but it also increments a counter.  This counter was displayed
both in a cumulative mode and a packets per second mode.  Note that the
clock that was being used for the packets per second display was the
one in the Tandy and its accuracy is suspect, but seemed to be at least
repeatable.( If you have not already guessed, the counter program is called
"anvil". )

The inputs & outputs of the router were connected to a good 2 trace
Tektronics scope so the actual packets could be seen.

The packets that were used were captured "ping" packets from the
BSD ping program, the packet size changed with the command line
option.

The tests that were run:
   Delay through router:
	The scope was used to measure the delay from the end of a 
	packet going into the router to the beginning of the packet 
	coming out.
	
	Although much concern has been expressed on the net about
	the delay though routers, we found that the tested routers
	all had small (<3ms) and consistent delays under light
	loading, it is not easy to do this test for heavy loads.

   Idle state:
	Run anvil & count the number of packets over a min.

	Again, there has been discussion on the net about the
	load that a router (or bridge) can place on a net just
	by being there and being turned on.  We found very low
	loads from the tested routers. 1 packet every 3 to 30 sec.
	Note that we did not have routing info in the test setup
	the addition of this type of thing would add a lot to
	the traffic generated.

   max good throughput
	Hammer was run generating packets into the router,
	anvil was run counting what came out.  The input rate
	was adjusted for the max rate where the calculated
	packets-to-router-rate matched to rate shown by anvil. 
	Packets of length 64, 128, 256, 512, 1024 and 1518 were
	tested.

	This is a common but flawed test.  The actual "good" rate
	should be the max rate at which no packets are lost.  Since
	one lost packet can have quite an impact on the application
	to application throughput of a system.  We hope that the
	new hardware will be able to do this test correctly.

	The rates varied quite a bit.  While the slowest router was
	still faster than the current average load on the Harvard 
	backbone (since we have segmented things) it is only a
	small fraction of the throughput of the best router.

   +25%
	To test simple overload conditions, the packet rate found
	above was raised by 25% and the output rate was measured.

	See data for results, some of the routers were too fast for 
	hammer to be able to generate the +25% rate.

   flood 
	Packets were sent to the router as fast as hammer could generate
	them.

	This flood condition, something that one could see with broadcast
	storms, caused many problems.  The most common problem was that
	the processor in the router stopped responding to the console
	port so that an operator could not get in there and disable
	things.

   filter 1
	A single filter condition was added to the router configuration
	and the max good rate was determined

	In most routers, the addition of a filter condition did effect
	the max throughput.

   filter 10
	Nine additional filter conditions were added to the configuration
	and the max rate was determined.

	This had an effect on some routers, no effect on others.

   back to back
	A series of packets were sent to the router as fast as hammer
	could send them and the point was found where the router
	started losing packets. In the real world, NFS servers
	can often generate back to back packets.

	The test equipment was not quite up to doing a good test here
	but the results might be useful.  In particular the Proteon
	router showed much better performance under the episodic
	load conditions of this test than it showed under constant
	load.

   counter accuracy
	The counters in the router were tested by passing a known
	number of packets through the router and checking the before
	and after counts.

	All of the counters were accurate.

   errors
	Packets with errors were sent to the routers to see 1/  that
	the router would toss the packets and 2/ if there were stats
	kept on the discarded packets.  The errors tested were
	crc errors, runt & giant packets.

	All routers discarded the packets.
	Most routers did not have all of the counter required to
	keep track of all of the errors.
----------------------------------------------------------------------------
Data:
	
size - packet size including CRC
theor - theoretical bandwidth of ethernet if 9.6 usec ipi
hammer - all that hammer could do
max - max rate that seemed to pass all packets
+25% - max +25% offered
flood - offered at hammer's max rate
f1 - one filter condition
f10 - ten filter conditions

cisco between MCI cards
size	theor	hammer	max	+25%	flood	f1	f10
64	14880	8919	5782	5782	5782	4463	3650
128	8445	6121	4320	4320	4320	3578	3023
256	4528	3757	2917	2917	2917	2544	2279
512	2349	2123	1772	1772	1772	1628	1516
1024	1197	1139	990	990	990	943	901
1518	812	782	695	695	695	672	651

cisco within MCI card
size	theor	hammer	max	+25%	flood	f1	f10
64	14880	8919	8919	8919	8919	6808	5338
128	8445	6121	6121	6121	6121	6083	5226
256	4528	3757	3757	3757	3757	3757	3757
512	2349	2123	2123	2123	2123	2123	2123
1024	1197	1139	1139	1139	1139	1139	1139
1518	812	782	782	782	782	782	782

nsc between interface cards
size	theor	hammer	max	+25%	flood	f1	f10
64	14880	8919	5216	6245	6245	4454	4454
128	8445	6121	3759	3980	3980	3526	3526
256	4528	3757	3741	3741	3741	3741	3741
512	2349	2123	2123	2123	2123	2123	2123
1024	1197	1139	1139	1139	1139	1139	1139
1518	812	782	782	782	782	782	782

nsc within interface card
size	theor	hammer	max	+25%	flood	f1	f10
64	14880	8919	6797	6797	6797	4672	4672
128	8445	6121	5572	5572	5572	3816	3816
256	4528	3757	3748	3748	3748	3740	3740
512	2349	2123	2123	2123	2123	2123	2123
1024	1197	1139	1139	1139	1139	1139	1139
1518	812	782	782	782	782	782	782

Proteon p4200
size	theor	hammer	max	+25%	flood	f1	f10
64	14880	8919	994	889	1017	994	994
128	8445	6121	971	995	266	971	971
256	4528	3757	902	738	33	902	902
512	2349	2123	764	704	107	764	764
1024	1197	1139	469	456	4	469	469
1518	812	782	324	318	39	324	324

Wellfleet between interface cards
size	theor	hammer	max	+25%	flood	f1	f10
64	14880	8919	8919	8919	8919	7680	7675
128	8445	6121	6121	6121	6121	6121	6121
256	4528	3757	3757	3757	3757	3757	3757
512	2349	2123	2123	2123	2123	2123	2123
1024	1197	1139	1139	1139	1139	1139	1139
1518	812	782	782	782	782	782	782

Wellfleet within interface card
size	theor	hammer	max	+25%	flood	f1	f10
64	14880	8919	7571	7571	7571	6154	6148
128	8445	6121	6121	6121	6121	5496	5517
256	4528	3757	3735	3735	3735	3760	3779
512	2349	2123	2123	2123	2123	2123	2123
1024	1197	1139	1135	1135	1135	1139	1134
1518	812	782	782	782	782	782	690

-----------------------------------------------------------------------------
Cpu under load:

How does the cpu respond while sending 1024 byte packets at
listed rates.

router		max	+25	flood
cisco b		ok	ok	dead
cisco w		ok	ok	ok
nsc b		ok	ok	ok
nsc w		ok	ok	ok
Proteon		ok	ok	dead
Wellfleet b	ok	ok	ok
Wellfleet w	ok	ok	ok

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

back to back

how many packets can one send to the router before it starts to
drop packets?

router		64	256	1024

theoretical	140	59	17
cisco b		90	45	15
cisco w		device is faster than the test setup
nsc b		22	57	17
nsc w		device is faster than the test setup
Proteon		20	15	6
Wellfleet b	device is faster than the test setup
Wellfleet w	device is faster than the test setup

Something does look wrong with the nsc between interface cards
values but redoing the test came up with the same results.

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

errors

cisco
    bad crc	- CRC error counter incremented.
    runt	- Runt error counter incremented.
    giant	- Giant error counter incremented

nsc
    bad crc	- Alignment error counter incremented, CRC error
		  counter was not.
    runt	- No counter.
    giant	- No counter.

Proteon
   bad crc	- CRC error counter incremented.
   runt		- No counter
   giant	- No counter
   
Wellfleet
   bad crc	- CRC error counter incremented.
   runt		- No counter
   giant	- Incomplete frame counter incremented
   

-----------[000367][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 1989 08:17-EDT
From:      CERF@A.ISI.EDU
To:        tcp-ip@NIC.DDN.MIL
Subject:   PostScript Versus ASCII
Jon Postel should not take the heat on the PostScript matter.
I was among the several who pushed rather hard on this point,
largely out of a concern that we were losing opportunities to
improve our ability to express ourselves by continued lack of
quality figure/graphics which desktop publishing software has
placed in our hands. I'm less infatuated with multifont
capability. Creating figures with tools available almost never
results in an ASCII rendition. Rather, one gets bit maps or
PostScript or other encoding as output. Of course, one also
gets paper.

It's clear that PostScript is less widely available than I
had thought; more interestingly, and I think properly, Karl
and others have pointed out the difficulty of doing meaningful
searches through the PostScript forests. This I must agree with -
it is impossible to even imagine what the content means when
confronted with the PostScript (ASCII) rendition. 

Here is the conundrum. Many of us are regular users of editing
tools which allow combined text and graphics. Since print medium
publishing still dominates (let's face it, it's cheap and 
convenient), these tools are often the source of the documents
we'd also like to submit as RFCs. Some of these tools do permit
the preparation of simple, ASCII unformatted (or, sometimes,
formatted) presentations in addition to PostScript. Its a separate
production, though, because pagination changes with font, for
instance. So one would do one layout for multifont printing
and another one for plain ASCII on-line presentation. 

It gets worse when you have to maintain two separate texts
for this purpose (e.g. a LATEX version and a plain ASCII version).
Keeping the texts in sync as changes are made is a pain - maybe
I just don't know about the right editing tools?.

Finally, if you do produce any graphics and they are only
printable by means of, say PostScript, then one would have to
do a separate set of ASCII graphics for the on-line version, or
forego the graphics altogether. We've been largely forced to do
the latter for a long time, in my opinion.

So, it comes down to wondering how we can ever introduce 
an agreed and widely-shared on-line publishing infrastructure
which will give us support for non-textual content. It seems
apparent that, in the short term, we will have to produce 
plain ASCII, non-graphic versions to satisfy search and
on-line display (not counting display-PostScript) and
allow PostScript files as alternatives. Is that the best we can
do? Are we on no noticeable vector which will allow us to
standardize on a common way of displaying non-text material?
Can we define such a vector and work towards it?

Vint
-----------[000368][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 89 12:17:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   PostScript Versus ASCII

Jon Postel should not take the heat on the PostScript matter.
I was among the several who pushed rather hard on this point,
largely out of a concern that we were losing opportunities to
improve our ability to express ourselves by continued lack of
quality figure/graphics which desktop publishing software has
placed in our hands. I'm less infatuated with multifont
capability. Creating figures with tools available almost never
results in an ASCII rendition. Rather, one gets bit maps or
PostScript or other encoding as output. Of course, one also
gets paper.

It's clear that PostScript is less widely available than I
had thought; more interestingly, and I think properly, Karl
and others have pointed out the difficulty of doing meaningful
searches through the PostScript forests. This I must agree with -
it is impossible to even imagine what the content means when
confronted with the PostScript (ASCII) rendition. 

Here is the conundrum. Many of us are regular users of editing
tools which allow combined text and graphics. Since print medium
publishing still dominates (let's face it, it's cheap and 
convenient), these tools are often the source of the documents
we'd also like to submit as RFCs. Some of these tools do permit
the preparation of simple, ASCII unformatted (or, sometimes,
formatted) presentations in addition to PostScript. Its a separate
production, though, because pagination changes with font, for
instance. So one would do one layout for multifont printing
and another one for plain ASCII on-line presentation. 

It gets worse when you have to maintain two separate texts
for this purpose (e.g. a LATEX version and a plain ASCII version).
Keeping the texts in sync as changes are made is a pain - maybe
I just don't know about the right editing tools?.

Finally, if you do produce any graphics and they are only
printable by means of, say PostScript, then one would have to
do a separate set of ASCII graphics for the on-line version, or
forego the graphics altogether. We've been largely forced to do
the latter for a long time, in my opinion.

So, it comes down to wondering how we can ever introduce 
an agreed and widely-shared on-line publishing infrastructure
which will give us support for non-textual content. It seems
apparent that, in the short term, we will have to produce 
plain ASCII, non-graphic versions to satisfy search and
on-line display (not counting display-PostScript) and
allow PostScript files as alternatives. Is that the best we can
do? Are we on no noticeable vector which will allow us to
standardize on a common way of displaying non-text material?
Can we define such a vector and work towards it?

Vint

-----------[000369][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 1989 19:47-EDT
From:      CERF@A.ISI.EDU
To:        mcc@WLV.IMSD.CONTEL.COM
Cc:        avsd!vixie!asylum!karl@UCBVAX.BERKELEY.EDU, tcp-ip@NIC.DDN.MIL
Subject:   Re: Comment on RFC1124 (?)
Merton,

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

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

Vint
-----------[000370][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 89 16:33:12 GMT
From:      Mills@UDEL.EDU
To:        comp.protocols.tcp-ip
Subject:   Re:  PostScript Versus ASCII

Vint,

I've been waiting for this discussion to ripen before commenting, but you
have nicely captured my own thoughts and said it better than I could. I
too argued the issue in favor of PostScript, not so much because of infatuation
with the language, but because I perceived it to be the most widely
supported in the various WP and DP packages and compatible printers most
widely distributed. While there have been squawks about compatibility on
my own submission (RFC-1119), which (hopefully) have been fixed, I still
cling to that view. In a world that must in my view encompass commercial
software and non-Unix systems, and if a non-ASCII-compatible presentation
capability is required, then PostScript is a logical choice.

On judgement calls, such as when is PostScript "justified" for figures,
tables and formulae, not to mention fonts, I stand mute. I don't think it
is productive to argue the conditions under which an author is "allowed"
to choose PostScript or be "required" to choose ASCII. Having submitted
bunches of RFCs of both kinds now, I probably would make different choices
a year back or a year hence. It does seem reasonable (as my friends tartly
reminded me) to avoid use of any but the basic PostScript features, for instance
found in the relatively ubiquitous Apple LaserWriter (standard model). It
may in any case be useful to scout the features (or lack thereof) with printers
of various manufacture and develop a hints-and-kinks guide for prospective
authors.

On the matter of duplicate submissions in PostScript and ASCII. I have to
resist this for the same reasons as Vint points out. The tools I use every
day include mathematics manipulation and presentation packages, image
scanners and other computer-aided publishing (CAP - you heard it here)
software which produce PostScript as output. My WP and DP software is
capable and even convenient for the process of combining and formatting
reports and papers containing that data. In fact, in my PostScript submissions
you may notice the images and graphs are in Encapsulated PostScript (EPSF)
format and can be snipped from the document. The point is that the job of
rendering that, not to mention formulae, stylish fonts and visually exciting
tables is simply beyond the resources of my time and the time of my supporting
staff.

Finally, there is the issue of production efficiency and staff training. In
the past most of us who wrote RFCs were intimately involved in the work
reported and edited, formatted and published the RFCs ourselves. I still do
this myself. However, I have a lot of friends in the university and industry
research community who depend on secretarial staff to do the legwork. Most
of the publishing done is in research reports, conference submissions and
journal submissions, which clearly call for something prettier than ASCII.
Therefore, staff are usually trained to produce good-looking documents 
consistent with the quality expected in these publications. Asking them to
maintain dual-track editing, formatting and archiving with available software
systems (and that includes 'roff, 'Tek, Scribe, MS-Word, Ventura and the rest)
is simply not practical.

Now, it might even be possible to entertain an ad-hoc "standard" WP/DP
software suite, such as 4.3bsd Unix tools or Ventura/MS-Word or Slate or
something, but I don't think so. The WP/DP community is evolving like
fruitflies - I have gone through two versions each of WordPerfect, MS-Word,
Ventura and even several versions of hardware and operating systems in the
last couple of years. I conclude that such a standard is elusive, even if
ODA is said to be immensely imminent. When ODA and/or the other sprouting
standards mentioned recently become available more-or-less ubiquitously
to our community, I will be among the first to subscribe to them.

Meanwhile, note that PostScript contributors are asked to submit the source
files used in the preparation of the document, as I did. There is no
guarantee that these files would be compatible with every WP package; however,
it is true that the bulk of the text is available in a form that would
not violate the Principle of Least Astonishment assumed in many ASCII
editors. While I am not sure the RFC archive keepers would wish to make
these files part of the archive itself, I would assume the author could
make them available upon request.

Finally, I propose a cardinal rule that might satisfy the widest community
that have no access to PostScript printers. If an author chooses to publish
in PostScript, that author should be prepared to mail paper copies upon
request. I am happy to comply with that rule. Meanwhile, we have urgent need
for a browser program that can munch through PostScript output looking to
collect just the text and do something reasonable to produce an ASCII document
that can be gripped, grepped and grokked by the masses.

Dave

-----------[000371][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 1989 21:04-EDT
From:      CERF@A.ISI.EDU
To:        oliveb!mipos3!omepd!intelob!rjh@APPLE.COM
Cc:        tcp-ip@NIC.DDN.MIL
Subject:   Re: TCP Urgent Data Handling
Bob,

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

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

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

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

Vint
-----------[000372][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 89 20:24:00 GMT
From:      marc@apollo.HP.COM (Marc Gibian)
To:        comp.protocols.tcp-ip
Subject:   Re: PostScript Versus ASCII

This has been a very interesting discussion, but everyone seems to
have missed what seems to me to be the real problem.  Let me give
it a try ...

The issue here is that many of us have long ago stopped generating
simple ASCII documents.  But, we need some way to interchange these
more complex, multimedia, documents.  The use of Postscript seems
to me to miss the point because it is not a representation of the
document, rather it is a representation of its printed image.

Believe it or not there is actually a standard that addresses
the interchange of these sophisticated documents.. I believe
it is titled ODIF (Office Document Interchange Format), and
is part of ODA (Office Document Architecture).  Rumor has it
that some of the majors in the desktop publishing business
have announced products capable of reading and writing ODIF,
therefore supporting the interchange of documents with ODIF.
Finally, x.400 includes ODIF as one of its defined body part
types, so when we start emailing RFCs over x.400 services,
it is a natural function to send them out in ODIF format.

SO, my conclusion is that a reasonable approach to solving this
problem is to do two things:

1.  always, always provide an ASCII version of all RFCs, since
    as much as we wish it were different, not everyone has a
    workstation, or even a PC, on their desktop.

2.  provide an ODIF version of all RFCs to support interchange
    of the complex, multimedia, form of the documents.

It will be interesting to see what really happens...

Marc
-- 
Project Engineer, email project: Apollo Systems Division of HP
Internet: marc@apollo.hp.COM
NETel:    Apollo: 508-256-6600 x2077
(Copyright 1989 by author. All rights reserved.  Free redistribution allowed.)

-----------[000373][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 89 21:54:18 GMT
From:      guy@auspex.auspex.com (Guy Harris)
To:        comp.protocols.tcp-ip
Subject:   Re: grape abandons FTP continuation lines


 >>Moral: Don't use FTP continuation lines in your FTP server unless you
 >>want to make Sun users confused and unhappy.  And when they get
 >>confused they send you mail.  And when you get tired of answering that
 >>mail, you rip the continuation lines out of your code.  
 >
 >Or you can use the FTP in accrodance with its protocol specification.
 >And when the Sun users get confused, and angry, they send you mail.
 >Bounce the mail to Sun.  Maybe Sun will eventually fix their machines.
 >I'm not holding my breath, though.

Gee, I just tweaked the 4.3-tahoe "ftpd" to put out a 3-line greetings
banner, according to the specs in the FTP RFC, set it up as the FTP
daemon on my 4.0.1 Sun-3, and connected to it with the vanilla FTP
client on the same machine - said client had no problem at all with it. 
Perhaps upgrading from a 4.2-derived FTP client to a 4.3-derived FTP
client in SunOS 4.0 did the trick?

If so, this means:

	1) Sun's *already* fixed their machines in 4.0 (if you're running
	   3.x, you might consider bringing up the 4.3BSD FTP client on it,
	   bearing in mind that it may either depend on 4.3BSD features
	   in the local OS or on added commands in the 4.3BSD server
	   implementation);

	2) any other vendor whose FTP client is 4.2BSD-derived may have
	   the same problem, if the problem was introduced by Berkeley
	   and not Sun.

-----------[000374][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 89 22:18:35 GMT
From:      peter@ficc.uu.net (Peter da Silva)
To:        comp.protocols.tcp-ip
Subject:   Re: PostScript Versus ASCII

Good point about the difficulty of generating ASCII RFCs from newfangled
raster-output-only CAP systems.

If an RFC is in PostScript, then include the source in whatever markup
language (*roff, TeX, or Wysiwyg) you use, without any of the graphics.
-- 
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"That is not the Usenet tradition, but it's a solidly-entrenched            U
 delusion now." -- brian@ucsd.Edu (Brian Kantor)

-----------[000375][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 89 22:43:54 GMT
From:      jacob@gore.com (Jacob Gore)
To:        comp.protocols.tcp-ip
Subject:   Re: Thinwire vs. Thickwire

/ comp.protocols.tcp-ip / aggarwal@JVNCA.CSC.ORG (Vikas Aggarwal none) /Sep 29/
[lists some tradeoffs between thin and thick wire Ethernet]

Also:

THINWIRE

	Transceivers and drop cables can be used
	Transceiver can be (and often is) built into the computer instead
	If using transceivers and drop cables:
		Non-intrusive transceivers are not available
			(cable must be cut to insert new transceiver)
	If not using transceivers and drop cables:
		Cable generally runs within an inch of each computer
		Non-intrusive off-shoot cables are available, but
			their outlets must be inserted into the cable
			in advance, and they add twice their length
			to the total length of the network

THICKWIRE

	Transceivers and drop cables must be used
	Non-intrusive transceivers are available ("vampire-tap")

In short, if your network is best served by a central-spine-with-drop-cables
topology, then one additional advantage of thick Ethernet is that you can
add new transceivers easily.


And then there's Twisted-Pair Ethernet...

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

-----------[000376][next][prev][last][first]----------------------------------------------------
Date:      30 Sep 89 23:47:00 GMT
From:      CERF@A.ISI.EDU
To:        comp.protocols.tcp-ip
Subject:   Re: Comment on RFC1124 (?)

Merton,

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

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

Vint

END OF DOCUMENT