Paul Bryant's Networking Correspondence
Can I have input for the network quarterly progress report for February, March, and April 1988. May have have input by 6th June for a document to be considered at NTMPC on 14 June.
The report should take the same form as last time (see NTMPC/9/88). Please try and follow the format of the document and paragraph numbering to make my job easier.
Thank you.
I have tried to edit in the comments you have kindly supplied.
I have left in the DECNET comment but noted that the use of DECNET is not required for the support of current services. This was really a comment for if and when DECNET is used on the infrastructure.
I disagree with your comment that migration only applies to the international nodes. We have to ENCOURAGE the migration of countries. We have to make it possible to connect national networks in various ways. We expect DECNET, Coloured book protocols be used on an interim basis. These will be phased out with NJE and the user of IBM (non ISO) SNA session service.
I do not agree with your concept of the super backbone. I see all countries (eventually) connecting to the X.25 infrastructure- thus 190 PVCs. The 4/5 sites you are thinking of are the sites with switches which may or may not have SNA international nodes at an early date. I could understand your comment if the switches were to be IBM 37x5 equipment. In fact the decision between XI, Northern Telecom switches, a service from the Dutch PTT has yet to be made. My own view is that the 37X5s have a poor performance (200 packets a second) whereas we need 800 packets a second. Also I am not happy that they will be reliable enough as they will be operated to some extent by the local management. This needs study.
There are still a number of points that I am uncertain of from your second message:
You make no additions to the document. Does this mean that it covers all we need to define to set up the scheme? I am very surprised that you have not found more fault with the document as I am not an SNA expert and it is all from 'the book'.
Central to the transition of EARN to use ISO protocols is the preservation of the existing services. This requires the use of the NJE protocols across the X.25 infrastructure. Any other proposition would be likely to cause a loss of functionality. NJE will be phased out as and when ISO products are available.
Using manufacturers products the only way of using NJE over X.25 is provide by operating NJE over the IBM SNA session service which may be operated over X.25 permanent virtual circuits. Recent announcements indicate that it will be available over switched virtual circuits.
The IBM ISO products are part of the SNA set of products. Thus the use of some SNA products are a prerequisite for migrating to ISO protocols.
There are two possible schemes for operating SNA over the EARN X.25 infrastructure.
The first scheme is to operate EARN as a single SNA network. This would require a tight central control over the whole network. This would certainly provide a high quality network. EARN has the makings of the central management required since this has been undertaken for the current EARN network. For an SNA network more control would have to be given to the management and a more extensive team would be required. The expertise is available as many sites in the community now operate SNA. It is unlikely that countries and sites would be prepared to give EARN the degree of control required.
The second scheme is to regard EARN as a set of interconnected SNA networks. This can be achieved by the use of SNI (SNA Network Interconnect). This provides a gateway between SNA networks which allows them to have a degree of autonomy. This appears to be the only acceptable way to proceed.
There are a number of schemes possible. The gateways is composed of the program GW-NCP residing in an IBM 3705 or 3725 and GW-SSCP in the IBM computer connected to it.
In this scheme one or more gateways are placed between the networks. With one gateway all the traffic would go through a single IBM 3725 which would create bottle necks both in the lines, switches and the 37x5. With several gateways the logical topology would become complex. In addition much traffic would have to pass through the SNA network of a country.
In this scheme a dummy SNA network is created to which gateways to all the other SNA networks connect. Thus each SNA country network would operate a gateway within their country. This scheme appears to be flexible in the way the traffic can be controlled. There are no obvious limitations in the scheme as far as EARN is concerned.
This scheme is recommended.
It would be possible to create hybrid schemes in which some countries could be part of the 'dummy' network and others operate their separate SNA networks.
This should be resisted as it would lead to a more complex situation, more complex management, and some confusion.
It would be possible for some countries to group together in a single SNA network to connect to the backbone.
This should be resisted as it would lead to confusion.
In the limit there may be an SNA network per site and these could all potentially be gatewayed directly onto the dummy network.
This should be resisted as it would rapidly increase the number of PVCs and SNA sessions. Thus only one connection to an SNA network within a country should be allowed. A country is free to have a number of SNA networks which gateway onto networks which gateway onto the dummy network.
It should be noted that SNA within a country is a national issue and not part of the international migration.
It should be noted that similar restrictions should be placed on the use of EARN by DECNET. This is an area for further study if the use of DECNET grows. This is not part of the preservation of current services.
SNA addressing is either:
or:
Each gateway within the dummy network must be numbered with a 'subarea address' within the dummy network. Ideally, an existing address scheme should be used which would imply the X.121 or ISO three digit numbers. Unfortunately the SNA subaddress does not allow this. Thus EARN will have to invent an address scheme. Since there are a number of 3705s in the network is is desirable to avoid ENA.
It is proposed to number the subareas associated with each country 1 onwards. The numbers will be allocated in the alphabetical order of the ISO two character country codes. New countries would obtain the next number in the series rather than reorganising the numbering. These numbers will be the subarea addresses of the gateways within the dummy network.
With 20 countries and allowing for expansion, 64 subareas appears sufficient. This requires 6 bits for the subaddress and 10 for the element address. It is unclear whether 1024 elements addressable per network from within the dummy network is sufficient.
Each country network will have at least one element address which represents the NJE service on the international node, plus one for the gateway system services control point. There be further element addresses for further NJE services.
Each network will maintain a GW-SSCP for establishing the cross network SNA sessions.
The dummy network has no need of a GW-SSCP.
Each network must be named (the NETID). The dummy network will be named EARN and the country networks with the two character ISO code.
Each node requiring visibility across a gateway must be named. The existing EARN names should be used. These names will be used, as now, for NJE traffic.
Tables will be required for each SNA network. Part of the tables will be private to the network and the other part concerned with the cross domain traffic. There is no means provided for ensuring the consistency of the cross domain information.
EARN will have to develop a means of ensuring the consistency of the tables. A system with some similarities to the system supporting the current nodes will be needed but on a smaller scale. Thus there will be a master table distributed which will be processed to provide the tables for each network.
To make this task easier there should be standardised names and addresses. The use of the two character ISO code for NETID has already been recommended and this same name should be used for other names in the cross domain definitions. In this way the only difference in the definitions would be the ISO country code and the gateway subarea number. There is likely to be additional information for further links between specific EARN nodes where traffic demands.
The logical topology is defined by the X.25 Permanent Virtual Circuits (PVCs). The PVC carries a VTAM SSCP to SSCP session over which a number of NJE connections may exist. A complete connection of the international node in every country to every other one would involve 190 PVCs for 20 countries. Traffic from other SNA nodes could use the same VTAM SSCP to SSCP sessions across the backbone. Traditional nodes connected to the international node would require that node to spool files as now.
The current NJE scheme and its management could remain. It would now reflect the logical topology of the SNA sessions and the physical topology of the parts of the network not using SNA.
There could be some additional complexity due to alternative routings being available.
It is recommended that the current node management is maintained.
EARN (European Academic Research Network) is a computer network between academic institutions like universities or research centres for the purpose of world-wide communication. It consists of a set of independent host nodes connected by means of leased telecommunications lines in an open, un meshed topology. A central computer in each country provides international connectivity and some central services.
EARN is a 'store and forward network'. It utilises the transmission techniques of the JES2/JES3 or RSCS subsystems of the IBM operating systems MVS and VM respectively. Emulations are available for several non-IBM systems such as SIEMENS BS2000/BS3000, DEC VAX VMS or UNIX, or CDC Cyber NOS.
The following functions are available:
EARN provides world- wide connections to:
In the remainder of this document any statements concerning EARN will also be true of BITNET (in the USA), NETNORTH (in Canada), and GULFNET (in the Middle East) as the networks are technically a single network and differ only in their management.
The European scientific community gratefully acknowledges the support of IBM, who supplied skilled technical staff and carried the costs for international and some national PTT-lines as well as for the central node computers of the EARN backbone network up till the end of 1987. The network is now financed by the community.
JANET (Joint Academic Network) is a computer network for the use of academic and research institutes in the UK. It is operated under the auspices of the UK Secretary of State for Education and Science. It has connections to virtually all client sites and in many cases these connections are to local area networks to which the various services are connected. There are gateways to the public X.25 network, to US INTERNET, to UUCP networks USENET and EUNET, to EAN based message handling systems, as well as to EARN.
JANET provides facilities for file transfer, mail, interactive services and job transfer although the services on any system depend on the particular machines and on the local management. The protocols used are X.25 and the so called 'Coloured Book' ones. The network is expected to migrate to the use of ISO protocols over the next few years.
The UK has a single EARN node at the Rutherford Appleton Laboratory (RAL). This node is also connected to JANET. A gateway is provided on an IBM computer at RAL, which allows the transfer of mail and files between the two networks. It does not allow interactive traffic. This gateway is the subject of the remainder of this document.
Financial support for this gateway is provided by a consortium of funding bodies. Overall policy control is exercised through the Network Advisory Committee. Operation of and support for the gateway is provided by staff at RAL.
JANET users are advised that, although it is technically possible to send and receive mail from other networks via EARN, these services are not guaranteed to work.
In JANET, files may be sent to EARN nodes from machines offering 'Blue Book' file transfer. Files can not be 'fetched' from EARN nodes. The transfer of binary files is allowed but is probably only meaningful if both the EARN node and JANET node are IBM or IBM compatible machines.
To transfer mail the EARN node should offer an RFC822 mail service. RFC822 is an ARPA mail standard. This may be provided by systems such as the Columbia Mailer and its associated user interface under VM/CMS although this is not essential. The JANET node must offer a 'Grey Book' mail service.
Message transfer, as provided in EARN, is not possible within JANET. It is possible to the RAL EARN node from other EARN nodes.
The RAL EARN node, in common with the other EARN backbone nodes, offers NETSERV which provides an EARN information service. The information files may be requested from within JANET using 'Grey Book' mail. Those with accounts on the RAL IBM computer may access NETSERV as if they were on an EARN node.
The RAL EARN node, in common with many others, offers LISTSERV which provides file and mail distribution services both within EARN and JANET.
NETSERV is an information service provided within EARN. There is one site in most countries providing it. The JANET network is technically different to EARN and therefore the method of access to the service is restricted from JANET.
NETSERV responds to commands sent to it in a file, in mail, or in a CMS message. From JANET, commands may only be sent by mail.
Full details of using NETSERV are in the NETSERV file NETSERV HELPFILE. This may be retrieved by sending a file or mail containing:
GET NETSERV HELPFILE in EARN the file is sent to NETSERV at UKACRL. in EARN the mail is sent to NETSERV@IB.RL.AC.UK in JANET the mail is sent to NETSERV@UK.AC.EARN-RELAY
On EARN CMS services (including RAL) the file may be retrieved using the CMS command:
TELL NETSERV AT UKACRL GET NETSERV HELPFILE
A computer readable copy of this document is held as JANET GATEDOC within NETSERV.
Every accessible 'entity' has a network address. An 'entity' is some service accessible via a network, such as a mail service. Thus a particular computer may be several network entities. Each network has its own address scheme. Gateways and relays sort out how an entity on one network can be accessed from another network. Unfortunately this often means that additional addressing information has to be supplied by the users to enable the gateways to operate. This may have to be provided in an inconvenient form, such as within the data file being transferred.
Using addresses is inconvenient as these are often changed and they are also not easy to remember. Thus, entities are usually 'named' to provide a stable 'name' for the user.
Each 'name administration' has named the entities in its 'domain' and possibly in other domains. Typically EARN, JANET and ARPA are name administrations who have set up schemes for naming. It is worth drawing a distinction between names used for file transfer and those used for mail although they look somewhat similar. In the case of file transfer names can usually only be used for moving files between entities in the same administrative domain and if a file is to be sent to an entity in another domain some fairly ad hoc schemes may have to be devised. In the case of mail the naming information is designed to go through relays and thus can be made easier for the user (assuming the use of the ARPA RFC822 standard). It is fortunate that RFC822 is used in EARN and JANET which allows the mail relays to handle names in a fairly convenient way.
A full list of EARN, BITNET and NETNORTH node names can be obtained from NETSERV. These have a CMS 'filetype' of NODELIST. For example, DEARN NODELIST contains the list of German nodes.
An EARN node name is normally associated with a computer. The names have no hierarchical structure. Names often have some informal structure as in many cases the first few characters define the country, the next the site and the rest may indicate the operating system in use. The EARN network protocols limit a name to 8 or less characters. The names can be used for file transfer and for mail although mail can often make use of more more complex names not related directly with node names. The use complex names is important in traverse gateways.
Names in the JANET network are registered with the 'Name Registration Scheme'. Names are hierarchical. The top level is UK and the second level contains AC - meaning academic community. Site names are at the third level. Any structure below the third level is at the discretion of the site. The name components may have a 'standard form' or an 'abbreviated form'. The two forms are provided as a compromise between meaningful names and quick to type ones. The components of a name are separated by '.'. A name has 'contexts' associated with it which define which services it applies to. For example, file transfer or mail.
Note that other networks also have a similar scheme but in all other cases the most significant or top level element comes last. In JANET it comes first. You are warned that this causes unending confusion.
A typical standard form name might be:
UK.AC.RUTHERFORD.GEC-K
The corresponding abbreviated form might be:
UK.AC.RL.GK
For use within JANET the UK.AC. may generally be omitted.
On any system on JANET only a selection of names may be available. The name UK.AC.EARN-RELAY or the incomplete domain EARN must be available in MAIL contexts if mail is to be sent from JANET to EARN. The name UK.AC.EARN-RELAY must be available in FTP (file transfer) context for file transfer purposes although it may be possible to use some alternative method of addressing the IBM computer at RAL. If there are difficulties the local site management should be consulted.
The names of entities within JANET are held in the UK NETSERV as file NRS DATABASE. Only the file transfer and mail entities may be accessed from EARN and not the others, such as interactive ones, although the list contains a complete set.
The registration of an entity does not necessarily mean that it can be accessed from EARN. Most entities of the form UK.AC. can be accessed and most others cannot.
File transfer is only possible if the JANET node offers 'Blue Book' file transfer and the NETSERV file NRS DATABASE gives this information. Look for the entries marked 'FTP'.
The RSCS protocol is unable to carry sufficient information within the protocol to satisfy the requirements of the 'Blue Book' file transfer protocol used within JANET. The additional information required has to be carried either as NOP records in the spool file (as inserted by the FTP exec), or within the data using '*FILE' records.
It is recommended that if the EARN node uses VM then the FTP exec should be used as this provides reports on the progress of a transfer, allows files to be fetched and is more convenient to use. The exec may be found in the file JANETFTP PACKAGE in NETSERV. It is a composite file that also contains some help files. This method should not be used if there is an MVS node between the VM node and UKACRL as the MVS node will alter the NOP records which the FTP exec generates. This restriction is hopefully temporary. You are warned that traffic to the USA currently passes through an MVS system at Montpellier.
The most useful FTP command structures for sending, fetching, and sending in DISK DUMP format follow but there are several other modes available. Full details are in the FTP Help file.
FTP SEND fn ft {fm} {AS remfile} TO userid {pswd} AT nrsname (options
FTP FETCH remfile {AS fn ft} FROM userid {pswd} AT nrsname (options
FTP DUMP fn ft {fm} TO userid AT nrsname
Items enclosed by {} are optional. Upper-case denotes fixed keywords. 'fn ft fm' are CMS filename, filetype, and filemode. 'remfile' is the remote file name on the JANET node and it must be a valid on that node. 'userid' is normally the 'user id' associated with the file store of the JANET node. 'pswd' is normally the password associated with the user id. For VM systems it is not required with SEND, and is the 'read-password' with FETCH. 'nrsname' is the name of the JANET node. 'options' are such things such as BINARY, LOG2, etc. (See HELP file). The DUMP mode delivers arbitrary files in DISK DUMP format.
The operation of the gateway may be controlled by a number of '*FILE' records which should be as near to the front of the file as possible, as their content must be determined before the file transfer through the gateway can start. Files can only be sent from EARN to JANET and may not be fetched. There are no reports of the progress of a transfer once it has reached the gateway.
The file, containing the '*FILE' records must be sent to EARN node UKACRL and user id JANET either as 'punch' files of up to 80 characters per record, or as 'print' files of up to 132 characters per record plus carriage control.
There may be several '*FILE' records which must be adjacent. Only the first set of such records is recognised. The format is:
//* *FILE key=value,......,key=value
The 'key=value' pairs from all the '*FILE' records provide the parameters to control the file transfer through JANET and they may occur in any order. A 'key=value' pair may not span two records. If a value contains a blank, a comma, or a single quote then the value must be enclosed in single quotes. Single quotes within a value must be doubled. If a sequence number is present in columns 73 to 80, then there must be at least one blank between the last parameter value and the start of the sequence number. If sequence numbering is not used then *FILE records may be up to 80 characters. The 'key' is a keyword and the possible 'values' are defined below:
SITE (Mandatory)
Normally the registered name of the destination such as
UK.AC.OXFORD.PHYSICS.VAX1 or its abbreviated form
UK.AC.OX.PH.V1 . Exceptionally it may be an X.25 DTE address
with 'Yellow Book' subaddress (normally .FTP). Advice should
be sought before using this form.
USER (Optional)
The user id on the remote entity.
PSWD (Optional)
The password associated with the user id on the remote entity.
DEV (Optional, default is LP)
The options available depend on the remote entity but normally include:
FILE - the file will go to the remote file store with access
mode 'replace or make'. Thus if the file already exists it
will be over written and if it does not it will be created.
LP - the file will be printed at the remote entity.
JOB - the file will be expected to be a job for execution at
the remote entity.
RDR - the file will be sent in printing format to a virtual
reader (IBM systems only).
No checks are made as to whether the file is suitable for the
purpose defined or whether the remote entity is a suitable
recipient. In most cases the transfer will be rejected by the
remote end if the transfer is not sensible.
FILE (Optional)
If the value of DEV is FILE the value is the name of the file
on the remote entity. This must be in a form suitable for the
remote entity. If the value of DEV is LP the value will
probably be used as a banner on the line printer output. If
DEV is JOB the value will probably be used to identify the job
on the remote entity. The exact effect will depend on the
destination system.
QUAL (Optional)
If a value for QUAL is supplied it will be sent in the 'device qualifier'
parameter. This parameter is only useful if the
remote entity attaches a specific meaning to it.
TRANSP (Optional, default is YES)
If the value is 'NO' all control characters are translated to nulls.
If the value is 'YES' no translation takes place.
MAIL (Optional)
The value is a CMS user id on the RAL IBM system to which file
transfer logging information is sent. This is used for testing
and monitoring only.
CC (Optional, default is YES)
For a file being sent as a print file (using Take Job Output)
CC=NO would cause the carriage control character at the start
of each line to be suppressed.
KEEP (Optional, default is YES)
If the value is 'NO' all the '*FILE' records recognised will
be removed from the file. If more than one set of *FILE
records exist, only the first is removed.
PSIZE (Optional, default is 256)
If the value is 128 an X25 packet size of 128 will be
requested otherwise a packet size of 256 will be used. There
should be no need to use this facility which exists for
historical reasons.
DTYPE (Optional, default is not BINARY)
If the value is BINARY the file will be sent as binary and no
code translation will take place. The remote end must support
the reception of binary. This facility is mainly useful for
sending MODULE files to another IBM. The file must still
conform to the general requirements for 'job output' such as
the limit of 80 characters per record for punch files or 132
characters plus carriage control for print files. By using
DISK DUMP format (which is transmitted as 80 character punch
records), any type of file can be sent between two VM/CMS
systems.
Example of parameters specified on two adjacent records:
//* *FILE SITE=RL.GK,USER=DEMO,PSWD='ABC DEF'
//* *FILE DEV=FILE, FILE=.TESTFILE
Once the file has entered the gateway no diagnostics or indications of success or failure are returned.
The local system must offer 'P' end 'Blue Book' file transfer. The details of any particular system should be obtained from the local management.
Files can only be sent from JANET to EARN and cannot be fetched.
The file transfer parameters should be set as follows:
SITE (Mandatory)
UK.AC.EARN-RELAY
Note that the JANET X25 DTE number is 000000000002 and the
'Yellow Book' sub-address is FTP.
FILENAME (Mandatory)
This must be any CMS file id consisting of a filename, a
filetype, and optionally a filemode although this is ignored.
The parts may be separated by space or '.'. The gateway makes
no use of this name.
USER ID (Mandatory)
'VNET/earnnode.userid' or 'VNETP/earnnode.userid'
'earnnode' is the name of the EARN node which is a string of 1
to 8 characters. 'user id' is a logging in identifier on the
relevant node and is between 1 and 8 characters. Files are
delivered in DISK DUMP format unless the
'VNETP/earnnode.userid' form is used, in which case they are
delivered in card image format but the logical record lengths
must not exceed 80 characters.
ACCESS MODE (Mandatory)
The access mode must be one of the following:
Make only, Replace only, Append only, Make or Replace, Make or
Append. These are all equivalent. Take job input. (For
delivery of 80 column punch format). Take job output. (For
delivery of printing format).
FILESIZE (Optional)
Files must be less than the 'filesize' if supplied. If no
'filesize' is given a file must be less than 8 M Bytes.
CODE (Optional)
EBCDIC, IA5 or BINARY are supported. BINARY is only meaningful
between IBM computers. The effect of BINARY is mostly to
ensure that no translations are carried out en route. The
default code used between IBM systems is EBCDIC to avoid
inconsistent conversion tables.
PFCONTROL (Optional)
ANSI paper-feed control should be specified for files destined
for a CMS file of filetype LISTING.
MAXIMUM RECORD SIZE (Optional)
The maximum record size is 1024 bytes. Files of arbitrary
record size can be transferred between IBM systems by means of
DISK DUMP format.
BINARY WORD SIZE (Optional)
For the transfer of binary files the word size must be 8.
All other file transfer parameters are optional and are ignored.
Once a file has entered the gateway no further diagnostics or indications of success or failure are returned.
Examples for popular machines transferring a file named FRED.DAT to SID at EARN node DEARN are:
For VAX computers running VMS and UWIST communications software:
$ TRANSFER %_input filename ? FRED.DAT %_output filename ? UK.AC.EARN-RELAY::"XX XX" %_remote username ? "VNET/DEARN.SID" %_remote username password ? $
For IBM computers running VM/CMS and RAL communications software:
FTP SEND FRED DAT AS XX XX TO VNET/DEARN.SID AT UK.AC.EARN-RELAY
Note that the RAL IBM machines are connected directly to EARN and thus the CMS command SENDFILE or similar should preferably be used.
UK.AC.EARN-RELAY is registered in the UK 'Name Registration Scheme' with FTP context as DTE 000000000002 and 'Yellow Book' sub-address FTP.
The EARN node must offer some means of constructing mail according to the RFC822 standard and for sending it to user id MAILER at EARN node UKACRL. The destination system must offer 'Grey Book' mail.
The 'To:' field must contain:
receiver@revnrsname
or less desirably
receiver%nrsname@UKACRL
'receiver' is the identification of a recipient which may be a distribution list, a user id, or a real name depending on the destination. 'nrsname' is a registered name of a 'Grey Book' mail system. 'revnrsname' is an 'nrsname' with the components in the reverse order. For example, if the 'nrsname' is UK.AC.RL.GK then the 'revnrsname' is GK.RL.AC.UK.
Access to some destinations may be barred for regulatory reasons.
A mail file may be constructed with an editor in which case it must contain as a minimum:
From: userid@earnnode
To: receiver@revnrsname
Date: day, date time timezone (this is not checked)
a blank line - very important
The text of the mail.
The file must be sent as a PUNCH file to user MAILER at EARN node UKACRL with class M.
Example of a mail file:
From: Fred@CERNVM To: Harry@VAX1.PHYSICS.OXFORD.AC.UK Date: Wed, 8 Oct 1986 22:26 GVA
This is the text of the message.
Detail of the mail protocol may be obtained from the relevant RFC822 document.
The gateway is tolerant and attempts to deliver mail which is incorrectly addressed. It will only deliver it if the destination is not ambiguous.
The JANET system must offer 'Grey Book' mail and the receiving system should offer an RFC822 mail system. Its absence will only cause inconvenience by not providing error reports to the sender.
The 'To:' field must contain:
receiver@EARN.revearnnode
or less desirably
receiver%earnnode@UK.AC.EARN-RELAY
'receiver' is the user id on the remote entity. 'earnnode' is the name of the remote EARN node. 'revearnnode' is an 'earnnode' with the components in the reverse order. In most cases EARN node names are only one component so there is no problem.
Examples of the content of the To: field are:
FRED@EARN.DEARN
or less desirably
HARRY%CUNYVM@UK.AC.EARN-RELAY
Mail is dispatched to the EARN gateway which will normally be automatic as EARN and UK.AC.EARN-RELAY are registered in the UK Name Registration Scheme. If this is not the case there are a number of system dependent methods of overcoming the problem and the local management should be consulted.
The name EARN is used regardless of whether the mail is for EARN, BITNET or NETNORTH.
In passing the JANET EARN gateway a 'received' field will be added to conform with the EARN standard.
Mail which cannot pass the gateway will be returned to the sender with a suitable diagnostic if possible. A very frequent diagnostic states that the name is too long. At many EARN sites there is no mail system and in these cases names are limited to 8 characters and longer names cause this diagnostic.
Line lengths in mail must be less than 80 characters as lines are truncated before reaching the gateway. This is a temporary restriction.
Details of the various 'Grey Book' mail implementations are outside the scope of this document.
Once mail has left the gateway its reception is the responsibility of the remote system and there is no guarantee that it will be delivered or that non delivery will be notified. The use of so called 'mailers' at EARN sites makes delivery highly likely but only 50% of sites do so.
Lists of 'earnnode' are held in NETSERV in files with 'filetype' NODELIST.
Note that for mail purposes the RAL IBM computer is a JANET node and mail from this machine would, for example, be addressed to:
Fred@EARN.DEARN.
Note that UK.AC.EARN-RELAY is registered in the UK Name Registration Scheme for MAIL as DTE number 000000000002 and 'Yellow Book' sub-address FTPR.MAIL. EARN is registered as an incomplete domain in the same way.
There are a number of gateways from EARN to other sub-networks and these are known to the JANET EARN gateway and it is not necessary to know where the gateways are. The 'To:' field should contain:
recipient%address@UK.AC.EARN-RELAY
Where 'address' is the address of the recipient on the remote network.
Thus to send mail to Fred at the SUNET location ASITE the 'To:' field should contain:
Fred%ASITE.SUNET@UK.AC.EARN-RELAY
A number of '%address' fields may precede the '@'.
The gateway attempts to correct some faulty addresses where the domain order is wrong. Thus Fred%SUNET.ASITE@UK.AC.EARN-RELAY will succeed. This will cause ambiguities and alternative domain orders are only attempted if the correct ordering fails.
The current list of gateways is contained in the file DOMAIN NAMES which is held in NETSERV.
Testing of these gateways from within JANET is incomplete. Although 'user support' services will attempt to help users this is provided on a best endeavours basis and success cannot be assured.
LISTSERV is a VM/CMS based mailing lists manager, designed and written by Eric Thomas of the Ecole Centrale de Paris, France.
Distribution lists may contain entries for EARN and JANET recipients. Lists are set up after application to the User Support Group at RAL, US@UK.AC.RL.MAIL. Charges may be made for such lists. Once set up the owner of a list may control the list and define who may join it and monitor its use. This is achieved by sending mail messages to LISTSERV@UK.AC.RL.MAIL.
Sending mail for distribution is no different to sending any other mail and is sent to ListName@UK.AC.RL.MAIL.
Details of LISTSERV may be obtained by sending mail to LISTSERV@UK.AC.RL.MAIL containing the line INFO and/or INFO PR >
The LISTSERV documentation is written from the point of view of a user within EARN. Facilities involving interactive messages and non-mail files are not available within JANET. This is a minor inconvenience and involves no loss in functionality. Examples will use the EARN domain ordering but use from within JANET must use the JANET domain ordering. When requesting a list of the members of a list this will use EARN domain ordering.
No changes to file transfer are planned.
Lines in mail from JANET to EARN are truncated to 80 characters before reaching the gateway.
No access to EARN directory service.
Traffic from EARN cannot be passed through the PSS gateways operated by the JANET Network Executive.
Use of VM/CMS FTP exec
FTP SEND fn ft {fm} {AS remfile} TO userid {pswd} AT nrsname
(options
FTP FETCH remfile {AS fn ft} FROM userid {pswd} AT nrsname
(options
FTP DUMP fn ft {fm} TO userid AT nrsname
Use of *FILE records. Insert one or more records at the top of the file
//* *FILE SITE=nrsname,USER=userid,PSWD=pswd,DEV=FILE
//* *FILE FILE=remfile,KEEP=NO
The file is sent to JANET at UKACRL
Use 'Blue Book' FTP to send file with parameters:
to NRS destination UK.AC.EARN-RELAY
user id VNET/earnnode.userid (disc dump)
or VNETP/earnnode.userid (80 char punch)
remote file name any valid CMS file name (MAX8CHAR.MAX8MORE
password not required
Send the mail To: userid@revnrsname
or To: userid%nrsname@UKACRL
Use 'Grey Book' mail. To: userid@EARN.earnnode
or To: userid%domain@UK.AC.EARN-RELAY
Send a mail file to NETSERV@UK.AC.EARN-RELAY containing:
GET filename filetype
Send mail for distribution to ListName@UK.AC.RL.MAIL
For information send a mail file to LISTSERV@UK.AC.RL.MAIL containing:
INFO
and/or
INFO PR
The EARN president has asked me to give you the following information.
The EARN Board of Directors spent some time discussing the views of the Executive on the future of Earntech which were also discussed by Earntech itself.
Earntech list members who were not in Israel should know that the paper by Eric Thomas was endorsed by Earntech and the EARN Executive responded with some views which included the co-option of two technical members to the Executive and the statement that Earntech was an advisory group.
The Board of Directors asked the Executive to draw up detailed terms of reference for Earntech.
They did not approve the co-option of two technical members whether they voted or not. The determining issue was that a technical Executive member would be able to discuss and influence policies and that the policies thus determined could be embarrassing to the technical member's Board Member. The Board was happy for the Executive to invite technical experts to their meetings for specific items.
It was clear that the Earntech was not happy with the views of the Executive for the future of the group. The Executive has been following the recent discussion in the EARNTECH list and hope to extract any constructive suggestions.
Interconnection of public X.25 networks in Europe as of 25 May 1988
Country codes show the first transit country where there is no direct connection. Where there are numbers the top row is the number of 48 or 64 K lines and the lower one the number of 9.6, 14.4 or 19.2 K lines.
AT| | BE| | 2 DK| DE NL | FI| DE SE | 1 FR| 2 | 1 1 2 DE| 1 2 1 2 | 2 1 GR| FR DE FR FR | FR 2 IS| GB GB | 1 IE| GB GB GB GB GB FR GB | DE FR 1 GB IT| DE FR FR FR | 1 1 2 1 YU| DE DE GB | 1 1 LU| 4 DE FR BE FR BE | 2 2 2 GB GB NL| BE 1 SE 2 2 FR DK BE BE | 2 1 1 NO| GB NL 1 SE GB GB GB GB SE NL 1 | DE 1 SE FR PT| FR FR FR FR FR FR FR FR | DE 1 GB SM| | ES| CH DE FR FR GB GB FR BE GB | 1 2 2 2 1 SE| DE 1 1 1 1 FR GB FR 1 FR | 1 2 1 1 2 1 1 1 1 CH| DE SE 2 2 FR GB FR FR GB FR DE | 1 2 GB 1 2 1 TR| GB | US GB| DE 1 1 2 FR 1 DE BE 1 FR 1 1 1 US | 1 2 1 1 1 5 1 2 2 2 2 2 2 3 --+--------------------------------------------------------------- | AT BE DK FI FR DE GR IS IE IT YU LU NL NO PT SM ES SE CH TR GB
Brussels------+ Nordic Countries
| (Stockholm G )
Dublin-G----+ | |
| | |
Rutherford-G-----------------------CWI G--- Management
\ / Centre
\ /
\ /
/ \
/ \
Montpellier G CERN G
||||||| ||
Barcelona ---+|||||| |+-----Bonn G
Abidjan-------+||||| |
Lisbon---------+|||| +------Vienna
Heraklion-------+|||
Izmir------------+||
Tel Aviv----------+|
Pisa-G-------------+
14A
Switch configuration
Northern Telecom DPN100 20S
+--Processor--------+---X.21--- Trunk to other switch
| Element +---V.24--- Spare
|
+--Processor--------+---X.21--- Trunk to other switch
| Element +---V.24--- Spare
|
+--Processor---- Spare
| Element
|
+--Processor--------+---8xV.24--- X.25 < 19.2
| Element
| |
| Processor Bus----+---8xV.24--- X.25 < 19.2
| Extender
| |
| Processor Bus----+---8xV.24--- X.25 < 19.2
| Extender
| |
| Processor Bus----+---8xV.24--- X.25 < 19.2
| Extender
|
+--Processor--------+---8xV.24--- X.29
Element
|
Processor Bus----+---8xV.24--- X.29
Extender
17B
NORTHERN TELECOM SWITCHES
Based on Northern Telecom DPN-100/20S
Meets most requirements
Also-
switches 3200 data packets per second
supports 500 calls per line pair
extendable to 30,000 lines and 30,000 dpps
wide range of facilities - hunt group
call redirection, closed user group
X.25 dial out, NUI validation, 3270 bisynch
SDLC, SNA, XXX, X.75
requires VAX/VMS or IBM/VM for management
used by many PTTs
availability claim 99.999%
Problems with connection to other networks
no gateway X.25 yet.
17A
EARN PHILOSOPHY
Expect:
Europe to be served by many national
and international networks
Networks interconnected be X.75 or
network level gateways
Networks will use common standards
Networks will co-operate and carry
transit traffic
Interim:
Variety of network interconnections
Variety of high level protocols
6B
X.25 ADDRESS STRUCTURE
Because of limitations of Northern Telecom-
Can only have one DNIC per network
+----------+--------------------+-----------------+-------------------+
|EARN DNIC | X.121 3 digit code | 5 digit machine | 2 digit subaddress|
| | | | |
|2000 | | | |
+----------+--------------------+-----------------+-------------------+
Management machines in EARN area
Examples-
20002000000100 EARN management computer
20002340000100 UK G-box
20002340000200 UK E-box
20002720000100 Irish G-box
20A
PRESERVATION OF SERVICES
Must preserve use of IBM Network Job Entry
Use NJE over ISO session over X.25
Require suitable relay between traditional
EARN and NJE/X.25
100
G-BOX
Based on VAX, VMS, DAC ISO products and JNET
+----------------------------------------+
| JNET |
+-----------------+--+-------------------+
| JNET link driver| |Bisynch link driver|
+-----------------+ +-------------------+
| OSAK | |
+-----------------+ to EARN node
| VOTS |
+-----------------+
| VAX PSI |
+-----------------+
|
to X.25
101
G-BOX STATUS
JNET code complete - done by JOINERS
Being tested under VMS V5
G-Boxes expected late this year
102
E-BOX
Based on IBM VM and MVS
Uses IBM OSI products -
RSCS GTMOSI OSNS OTSS NPSI
Implemented by IBM
103
At the Board meeting EARN pledged to take a full part in the COSINE pilot project. It is unclear what this 'full part' is. I believe we should resolve this question to guide our interaction with the project. To start the discussion I list below and in no particular order some possible interpretations with their pros and cons.
1 Take part in the various meetings for planning the project and in the RARE working groups. This will not effect our transition programme unless we want to take advantage of information gained. We have to find some staff effort.
2 Connect G-boxes to the COSINE network. We expect all our G-boxes to connect to our network. We could use some of them for COSINE. We could, I think, but further interfaces into the G-boxes for EARN and COSINE. We would need DEC permission for these developments and for the last proposal finance for interfaces.
3 Invite non-EARN owned VAXes to use G-box software for COSINE. I have no idea whether this would attract support. We may need finance for the software and possible some hardware upgrades.
4 Use E-boxes to connect to COSINE. Permission would be needed to allow the software to be used in this way.
5 Connect EARN to COSINE with an X.75 or network level gateway. This could not be done until well into next year when suitable software was available.
We must take account of any finance and manpower needed that may detract from our project. While we intend to use our network for service as soon as possible it is unclear what the object of using COSINE is since it will merely provide alternate routes and I am not sure whether NJE allows this.
I would like to produce a proposal for the next Exec meeting so that we can follow a well known policy. Can I have some input please.
At the BOD Joe gave a presentation which showed the transition having three overlapping phases. This paper was on a foil and has otherwise not been published (am I right?). At a later date Kees was assured that only the first phase of the transition would be undertaken prior to further BOD agreements.
Now we have a problem - As Joe says - the three phases overlap. Four switches are on order and phase one envisages two. We cannot wait for the next BOD meeting for further phases. What exactly are we allowed to do? What shall we do?
This paper reports on the major events at the EARN Board of Directors meeting in Israel - October 1988. No doubt it is biased by my interests and by when I was awake.
This was covered in two sessions (beginning and end). it was a very messy discussion. The reason was that the budget was not in a conventional form and the items were not clearly explained. The meeting wanted to discuss all the items requiring finance before agreeing the budget. Eventually there was agreement although there was a call to include a 10% or so eventuality, this was not pursued.
There was a suggestion that the subscriptions for the larger countries should have a ceiling in order to persuade Germany and the UK to agree. Since both the UK and Germany were waiting for an agreed budget before there funding bodies would consider the payment it was agreed not to change the subscriptions. Thus the UK subscription is still 74774 ECU. Germany are confident of obtaining finance, all other countries bar the UK agreed the subscription.
Transition attracted a long discussion. The discussion was led by Kees Neggers who was upset that the pilot was going ahead as he did not consider that this was agreed in Izmir. After a very long discussion the BOD agreed with one abstention with the transition actions. Later votes supported the transition of EARN after a discussion on the relationship of EARN to the IBM super computer network. In fact it is now agreed that the super computer network is nothing to do with EARN. We have not heard the last of this as Belgium intend to use their super computer network for EARN and drop their Paris link. Will they be an EARN member or not?
Feelings on the membership of East European countries are mixed. Although members seem to believe that the Cocom rules are to do with USA commercial interests they do not want to risk their interests. DEC claim that if an EARN VAX computer connects to East Europe then DEC is liable under US law. I find that difficult to believe. Anyway - the Exec will continue to investigate the possibilities.
There are problems with the technical group who are upset that the Exec do not follow their advice and they want clear terms of reference and representation on the Exec. The Exec agreed to this but the technical group were still not satisfied and the Board did not agree to technical members being on the executive. It was thought improper for non elected people to take part in policy decisions. The technical group believe they should be in charge of any technical decisions and should not be worried with politics. The BOD does not share this view.
The new officers are:
President: Froda Griesen (Denmark)
V President: Michael Hebgen (Germany)
Secretary General: Paul Bryant (UK)
Treasurer: Jean-Claude Ipollito (France)
Members: Stephano Trumphy (Italy)
Dennis Jennings (Ireland)
Avi Cohen (Israel)
Previously the members were dedicated to technical, CEPT, and membership - there are now many more jobs and these will be allocated by the executive at their first meeting.
At last it is agreed that any changes to the international part of the network must be agreed by the Exec or Board before implementation. This issue became live due to the establishment of an SNA link between Bonn and Montpellier to exploit the 64K line. There was the usual discussion on SNA where misunderstandings abound.
Please check for accuracy and please raise any further questions.
Clayton Thornton Northern Telecom Paul Bryant EARN Dominique Dumas Montpellier Other Montpellier staff
The Northern Telecom switch will shortly be delivered to Montpellier. This meeting was to plan for the installation.
Dominique Dumas is the prime contact at Montpellier.
The switch is a Northern Telecom DPN 100 20/S as specified in the Northern Telecom document (1).
The switch is a single rack with a footprint of 30 inches square. The switch itself takes one third of the space. It was decided that the power supply would be placed in the rack. The power supply is designed to fit in a 19 inch rack and Montpellier is responsible for any shelving required for the power supplies.
The proposed location in the machine room was inspected but the exact position will be defined by Montpellier.
Montpellier will provide a 220 volt supply at about 10 amps.
The switch will be shipped on November 21 and should arrive December 6. Montpellier will unpack and locate. Northern Telecom will install and check the equipment on a date to be advised.
The 64K lines to CWI Amsterdam and CERN have not been ordered. Paul Bryant will ask Dennis Jennings what is proposed.
When the 64K CERN Montpellier line becomes active it is hoped to use it for the current EARN traffic. The 9.6 K line will then be used for the link between the Montpellier and CERN switches pending the 64K link. This connection should become available about January 1.
Montpellier prefers V.35 to X.21 interfaces for 64K. Initially there will be 3 V.35 and 2 X.21 interfaces. This will be sufficient for the high speed links to CWI, CERN, and the E or G-box.
The X.21 interfaces will probably be swapped with V.35 interfaces from Rutherford who prefer X.21.
Note that the labelling on the Northern Telecom document (1) is incorrect.
Montpellier is expecting to connect an E-box (their current IBM computer) and a G-box to be provided by DEC. Paul Bryant will check whether a G-box is to be provided and when.
The connections from the E-box and G-box to other parts of EARN require further study.
Discussions with Michael Hebgen suggest that the 64K line to Bonn should be connected to the Northern Telecom switch at an early date. Initially the connection will be to a 3725 acting as a DTE. Further study is needed to determine how this link should be developed.
The connection will require a further high speed connection which has no technical problems.
This network uses OST switches (ECON 25). It provides X.25 1984 and it will shortly provide X.75.
The network shares the Telepac address space having addresses of the form
3402 0009 xxxxxx
This suggests that an X.75 connection should be possible when the Northern Telecom switch has X.75 in early 1989.
Further study is required to develop a definitive proposal should this be thought desirable.
The contact is Piere Chausson.
(1) Document on the project from Northern Telecom.
(2) Draft EARN documentation.
Present: Joe Chester EARN
Paul Bryant EARN
Clayton Thornton NT
Piet Bietome
Daniel Karrenberg
Delivery is expected in early December but installation will be in January.
The location was agreed. The equipment requires 26inch width rack space. The power supply will be put in to switch racking which will be done by CWI.
Two 10 amp single phase power outlets are required.
Signal ground and safety ground require two cables to a suitable ground.
The switch will be operated from the management centre now in Dublin.
A console may be attached to observe the operation of the switch. This will be provided by CWI if required.
The provision of the CERN and RAL 64K lines will be discussed at the EARN Executive meeting 8/9 December. Funding from EARN.
It is expected that the line to KTH will be provided on the expected 64K line.
It is expected that the a Nordic bisynch EARN connection will be provided on the 64K line.
There are two possibilities:
The bisynch line will go into the CWI G-box.
There will be a G-box in KTH and the bisynch line will not be needed and can be combined with the X.25 9.6 line to give 19.2. Joe will discuss with KTH.
It is hoped to provide a temporary X.25 connection between CWI and CERN. Jope and Bob Bloxall will progress.
It is expected to make a connection between the Telepac and NT switches when suitable X.75 or gateway X.25 is available - probably mid 1989.
It is expected that a connection to the other switches will be possible in February.
Contact at CWI is Piete Beetomer.
Since its inception in 1982 EARN has used the IBM NJE (Network Job Entry) protocol. This allows files to be relayed from machine to machine through the network. The RFC822 mail protocols is used over NJE. A large number of database and mail distribution facilities now exist. Lately a small number of IBM SNA links exist in order to take advantage of some 64K connections.
In order to be allowed to exist by the PTTs EARN had to agree to migrate to ISO protocols by the end of 1987. EARN also believes that it is in the interests of the users to undertake such a migration. EARN is a member of RARE which also demands that it supports ISO protocols.
Unfortunately manufacturer products and finance for transition have not been available until recently.
The first documents on transition came from a meeting in Perugia (Italy) in the early Autumn of 1987. There was a broad measure of agreement on the strategy. Later that year promises of support were obtained from DEC, Northern Telecom, and IBM.
A further series of meetings were held early in 1988 sponsored by DEC which developed an alternative scheme for high level protocols.
The current situation is that the X.25 infrastructure required is being constructed. The high level products are available. A service should be possible in early 1989.
The low level protocols used is X.25. Discussions suggested that a strategy based on developments of TCP/IP towards TP4 had many unknowns and were at variance with current European ideas for wide area networks. The TP4 ideas are probably more appropriate for high speed networks (greater than 64K) and such lines look to be very expensive in Europe. X.25 is satisfactory for slow and sometimes unreliable lines currently available.
Examination of the public networks revealed that they would be impossibly expensive for EARN traffic patterns. Costs would have risen by a factor of 10. It also seems that the data rates to be expected can be fairly low.
Thus a private network is being developed.
The strategy is to provide an international transit network. Each country would have its own network which may be the current EARN service, a national X.25 network, or a network of some other technology. Thus there will be gateways or relays between the international part of EARN and national parts.
As an aside it is believed that this is a better model than the PTT one where each country connects to many others via bilateral agreements. With an international transit network a network only has to negotiate with one other network and it is the international one which guarantees the bandwidth required with any other network.
Whilst the strategy looks nice and clean the practice is not so. There are a large variety of gateways and relays needed. For example:
The requirements for the switches and topology is to minimise costs and maximise performance.
To maximise performance there would be one switch with a high speed connection to each country.
To minimise costs there should be a number of switches located in low tariff countries.
The result of these conflicting requirements is to have 4 switches located in UK, Netherlands, France, and Switzerland. Although Switzerland is not cheap it does contain CERN which is a large source of traffic. These switches are to be interconnected by 64K lines. The other countries will connect to the switches with existing 9.6K lines or new 64K lines depending on demand and finance.
The switches are being supplied by Northern Telecom - model DPN100/20S.
These are near the bottom of the range of switches and have the following specification:
Further developments will allow the use of 2M connections.
Variations on the above configuration are possible to meet local requirements. Other models of the switch can be very large but all models are made from the same basic components.
The switches are managed from a DEC VAX. Terminals connected to a switch are only able to interrogate its operation and cannot control it. All control comes from the VAX and all alarms are sent to it. In the event of failure the management can be taken over by another VAX in the network.
As EARN expects that eventually the international infrastructure will only interconnect other networks it is not expected that there will be a need for many ports. In the short term provision has to be made for a small number of connections into a country for an X.75, and other gateway connections.
The structure of a DTE number is:
+-----------+---------------------+---------+-------------+ | DNIC | 3 digit country | 5 digit | 2 digit | | 4 digits | code based on X.121 | address | sub address | +-----------+---------------------+---------+-------------+
The DNIC is 2000 but is not registered with CCITT. It is unclear whether such a registration application would be successful.
The 3 digit country codes of each county connected to the switch is allocated to that switch and any equipment in that country has that code. The country code 200 is reserved for the network management equipment which needs a set of addresses.
The 5 digit addresses are allocated from 1 upwards.
The 2 digit sub address is not policed.
The principle requirement is to maintain the current services. This means devising a scheme for carrying NJE across X.25.
It was not feasible to convert NJE to FTAM, or similar schemes, since these would need a lot of implementation effort and there may well be loss of quality.
The first scheme is to run NJE across SNA across X.25. This would be easy as the products exist. The draw back is that the software only exists for IBM machines and about half the machines are VAXes.
The second scheme which has been adopted is to implement NJE over ISO session layer. This can be easily implemented on VAX and IBM computers. It has the psychological advantage that it uses more ISO protocol than SNA session.
For an IBM computer the required code has kindly been developed by IBM in Heidelberg. This uses the IBM products OTSS and OSNS. The system is now available. This is known as an E-box.
For a VAX computer under VMS the required code has kindly been developed by Joiners Associates using as a basis the JNET NJE code. It uses the DEC products OSAK, VOTS and PSI. The system is now available. This is known as a G-box.
The scheme works by the E or G boxes operating as a relay between NJE over X.25 and NJE over bi-synch. The E or G boxes set up virtual calls between each other over which NJE operates. Unfortunately it is not easy to detect the end of an NJE document and so the calls are left up permanently. This limits the number of E and G boxes which can be interconnected if there are a lot of boxes in countries.
The expectation is that there will be an E-box, a G-box or both in each country. DEC is kindly supplying the G-boxes.
Other ISO protocols are expected to operate over the network. So far the only one sufficiently developed from the point of view of available products is X.400. It is hoped that this will operate early in 1989.
Although not strictly ISO some X.29 interactive use is expected.
FTAM should be available in a year or so but it is to early to lay plans. JTM and VT are not expected in the foreseeable future.
In the case of X.400 a gateway between X.400 and the currently used RFC822 mail is being developed by Joiners and will reside in the G-box. Details of the use of X.400 have still to be worked out but will align with the Rare work.
EARN believes that Europe should be provided for by a number of national and international networks. These should be interconnected under suitable arrangements.
Thus EARN expects to connect to national parts of EARN, other international, and other national networks. The exact nature of these connections is unclear. However, EARN would prefer X.75 connections as this follows the X.25 model which is well worked out. The connections will be very dependent on the plans within a country and it is not EARNs intention to influence a country in any particular direction as long as the service to the user can be maintained. None the less there are benefits in European countries following a common path.
Dear Mr. Horrocks,
I wrote to you in August concerning the allocation of a UK DNIC for the EARN network. I attach my letter to save you searching your files.
We are now busy building our X.25 network which is now partly operational. We expect to offer a user service early in 1989.
May I ask whether there has been any progress with our application as I would like to finalise the X.25 addressing scheme as soon as possible.
Please contact me if you require any further details and I look forward to the results of your deliberations.
Yours sincerely
Dear Ms. Tait,
I would like to ask whether there has been any progress in the renewal of the above licence. I wrote to you some time ago and attach my letter to save you searching your files.
EARN is now making expenditures in order to develop its services and I would like to be assured that the licence will be extended after April of next year. I am sure you will appreciate that as communications lines and equipment are on a long delivery we are having to place orders now for delivery next year. We have a large user population and and if the licence is not be be renewed they require early notice so that they can make alternative arrangements.
Yours sincerely
Paul Bryant. UK Director of the European Academic and Research Network.
The decision making within the EARN Executive is not as effective as it should be. The reasons seem to be:
This paper suggests a way in which meetings can be made more effective.
The agendas could be:
Items for decision should be accompanied by a paper. Papers should contain a proposal or set of proposals. Papers should summarise the issues and reasoning behind the proposals. This should not be a collection of mail documents but key documents may be appended if really necessary. Normally the proposal should take all the relevant correspondence into account.
The result of a proposal should be:
Proposal papers should be numbered, filed, and if appropriate published.
As for section 3 except that documents and minutes for these items will not be published.
The draft agenda will be developed for the subsequent meetings. Actions will be placed for the development of proposals either from members or from sub-groups.
Attendance at future external meetings will be agreed and any policy for these meetings developed.
Items will be circulated. There will be un-minuted discussion if time permits. Any papers will not be catalogued.
Items should include:
Reports of meetings. Any proposals from these meetings should be in the decision section.
Reviews of relations with other organisations.
General discussion.
The minutes will contain:
Minutes will be published as soon as approved together with accepted proposals. Confidential items will be removed.
The aim of this proposal is to ensure that decisions are taken and that such decisions are clear and complete. If a decision cannot be arrived at then this is a sure indication that discussion should cease and a person or sub-group should produce a revised proposal at their leisure. This should prevent long discussions with no concrete outcome.
The hope is that good meeting preparation and taking important items first will reduce the time to take decisions and leave the remainder of the meetings for less important items.
EARN EXECUTIVE: Paul Bryant, (PB) Technical Director
Frode Greisen, (FG) Membership Secretary
Michael Hebgen, (MH) Secretary
Jean-Luc Delahay representing
Jean-Claude Ippolito,(JCI) Treasurer
Dennis Jennings, (DJ) President
David Lord, (DL) Vice President
Stephano Trumpy, (ST) CEPT liaison
ELECTED EXECUTIVE MEMBER: Avi Cohen (AC)
EARN STAFF: Alain Auroux, (AA) Paris Office
Joe Chester, (JC) Dublin Office
Cathy Gregury (CG) Paris Office
23.0.1 The meeting was chaired by Frode Greisen the President elect.
23.0.2 The Executive warmly thanked Dennis Jennings for his work in EARN over the past two years as president. Grateful thanks were extended to Joe Chester as this would be his last meeting as the Presidents assistant.
23.0.3 The following items were added to the agenda:
(1) 14 CERN to Montpellier link
(2) 15 LISTSERV
(3) 16 Morocco/Italy link
(4) 17 Joiners software support
23.1.1 Resolved: To accept the minutes of the last meeting with the following corrections:
(1) Item 14 paragraph 4 line 5 - replace "exploid" by "exploit".
(2) Item 22 paragraph 5 line 1 - replace "analysis" by "review".
(3) Item 23 paragraph 5 line 4 - replace "correct" by "reasonably accurate" and "The idea" by "However, the idea".
23.2.1 Resolved: That for these minutes and future minutes-
(1) Minutes will be circulated electronically to the Executive for comment for one weeks.
(2) Minutes corrected from Executive comments will be circulated electronically to the Board of Directors for comment for two weeks.
(3) Minutes corrected from Board of Director comments will be signed as correct at the subsequent Executive meeting.
23.2.2 Noted: The following Executive comments -
(1) Section 88.30.2 paragraph 1 line 6 - Delete sentence "It was agreed..." by "It was agreed that either the total contribution should be invoiced by January 1, 1989 to be paid by January 31, 1989 or half be paid by January 31, 1989 and the remainder by July 1, 1989.".
(2) Section 88.30.4 page 17 paragraph 3 - add "KECU" to each cost.
(3) Section 88.30.4 penultimate paragraph - add second sentence "Germany can commit to the 1988 model, not the level.".
(4) Section 88.30.4 paragraph 8 line 7 - delete "and eventually Belgium.".
(5) Section 88.31 (EARN ASSOCIATION page 14) paragraph 1 line 2 - replace "seat" by "registered office" which is a better translation of the French term "siege".
(6) Section 88.32.2 paragraph 1 line 3 - delete sentence "Together...".
(7) Section 88.33 paragraph 2 line 2 - replace "Paul Bryant...MDNS pilot" by "Paul Bryant stated that EARN wants to be technically as close as possible to the COSINE specification. EARN is ready to adjust or modify its plans to take account of the MDNS pilot.".
(8) Section 88.36.1 line 4 - add to end of line ", Udo Meyer"
(9) Section 88.36.2.2 paragraph 1 line 2 - replace sentence "Dennis Jennings..." by "Dennis Jennings stated that there should be only one international node in a country.".
(10) Section 88.37.4 paragraph 1 line 3 - replace "permanent" by "full time".
(11) Further amendments have been sent electronically to MH.
Executive meeting 21
Memorandum on use of SNA on international lines (MH) Delete Catalogue of EARN documents (AA) Retain Proposal for rationalising various lists (AA) Retain AA to report to Exec on responses to agreed mailer recommendations Retain Clarification: AA should inform sites not using mailers what mailers are available and ask why a mailer is not in use. Message to BoD and EARN Tech re staff utilisation and clarification with DEC (DJ) Retain Forward projection to end of year for Dublin office (JC) Complete Check with DEC re 150K cheque (JC) Complete Check re maintenance with DEC (JC) Complete Check with auditor re G-boxes (AA) Complete Executive meeting 22 DJ/JC to prepare annex to Management of Change proposal (examples, etc.) Retain AA to discuss EARN89 with PC Complete AA to ask relevant Board Members about registration of EARN name Complete AA to clarify position of Berthold Pasch Complete JC to add "software support over the network (Joiners)" to next Exec agenda Retain AA to arrange a meeting on scope and impact on CERN- MOP (single link) and of SNA sessions CERN to CUNY Complete JN - BEARN changes - paper required Retain JC to co-ordinate papers from ST, JCI, DJ on exploitation of TAL's Retain AA formalise position of deputy to NCC Retain PB to communicate Exec views on EARN Tech to EARN Tech Complete PB/JC to discuss interoperability test with suppliers Retain DJ to write to Czechoslovakia Retain AA to distribute official (French) version of statutes and English translation Retain DJ - write to Physics Library Retain Impact and scope statement on DEARN changes (MH) Delete ST - paper on CNUCE-NSF link Retain JCI - paper on NSFNET IP link Retain JC to co-ordinate this Retain Board Meeting October 24/25, 1988 JC to circulate action list Retain JC to update action list before next BoD Ongoing JCI/AA accounts to end of September to BoD Retain JCI/AA to split travel by category Retain JCI/AA to produce more accurate projections to year end Retain This action is now urgent AA invoices to countries for contributions (January 1) Complete AA legal services contract, including termination for non payment Retain DJ to raise issue of TAL costs with BITNET Retain Membership Committee - discuss and propose model for funding of links to associate networks Retain Circulate BITNET charter for Associate Networks Retain DJ - E-bloc issues to CPG Complete Write to COCOM (DJ) Complete Write to countries concerned (DJ) Complete Men-Comm. - proposal for new procedure for Associate Members Retain Exec - continue discussion and get more clarification from NORDUNET Complete JC - copy NORDUNET letter and reply to BoD Complete ST/DJ to have informal discussion with CEPT on 1989 Delete DJ write to CPG - participation in pilot MDNS, CIP, and seek support (resources) for that involvement Complete JC - statement on conformance by EARN to COSINE specs, RARE paper Retain JC - OSI Phase 2 detailed plan Retain AA - EARN Manager to pursue countries not implementing directives Ongoing MH to add topology diagram to Minutes Deleted AA to discuss connection of Morocco to Pisa not Bari Complete Exec - Terms of reference for EARNTech Retain Agenda for next BoD - SNA Retain Exec - Management plan, staff description, organisational plan, hiring plan for EARN staff Retain Exec - discussion with UK and Germany on budget Retain
23.4.1 Resolved: FG will set up a sub-group to draw up a proposal based on the Executives discussion on the structure of sub-groups and the place of EARN TECH.
23.4.2 Resolved: In the light of the request from CERN to be represented on the EARN Board of Directors, FG will seek the agreement of the Board of Directors.
23.4.3 Resolved: that the responsibilities of Executive members are:
Operation MH aided by JCI and AC
Present international backbone, NOG, NAD,
statistics, security.
Information/Communications PB aided by DJ
Minutes, lists, file-store for documents,
annual report, brochure.
Finance JCI aided by FG
Accounts, budgets, funding, payment model.
Development DJ aided by PB and MH
OSI, SNA, second transatlantic line.
Policy AC aided by FG
Membership, charter, code of conduct, BOD
operational procedures.
Liaison FG aided by MH and ST
CEC, CEPT, RARE, COSINE, suppliers, other
networks.
Users ST aided by AC
Applications, user services, earntech,
users' meetings.
Further details and other topics will be provided by the relevant member.
23.4.4 Resolved: That JC will provide a paper on the future of EARN TECH to be agreed with ST to the next Executive meeting based on discussions at this meeting. The paper when accepted by the Executive will be sent to the Board of Director's members for discussion with EARN TECH members.
23.4.5 Resolved: PB will draw up operational procedures for Executive meetings which include how Executive minutes and papers should be circulated.
23.5.1 Resolved: That-
(1) The OSI operations centre will be in the Einstein Centre in Amsterdam.
(2) DJ will provide a plan for the resources involved to be developed from the OSI project plan.
(3) DJ will provide a staffing plan for 1989 for at least one man year for OSI which will be approved by The Board of Directors before implementation.
(4) FG will provide a paper on recruitment for the Amsterdam Centre.
23.6.1 Resolved: that EARN will contract with site staff for essential activities for 1989. The activities to be contracted and the manpower to be allocated are based on estimates by EARNTECH. The activities and possible contractors are-
Node management 1 week per month Ulrich Giese GENROUTES maintenance 0.4 weeks per month Ulrich Giese NETSERV maintenance and No estimate Berthold Pasch development LISTSERV maintenance 1 week per month Eric Thomas and development DOMAIN tables to be investigated Hank Nussbacher
Contracts may be with organisations or individuals depending on circumstances.
Work other than maintenance, financed by EARN will be the property of EARN. This will be clarified with the person or organisation involved before setting up an agreement
LISTSERV support will be on the basis of full, free, and continuing access to LISTSERV by EARN members.
Contracts will be on a temporary basis for 6 or 12 months or on a 6 month rolling basis so that jobs can be allocated to full time staff in due course. Ideally, EARN should be able to discontinue contracts with as short a notice as possible.
The permission of contractors' managers to undertake EARN work will be sought.
EARN would not expect to pay for computer resources.
Confidential - there is a payment ceiling of 721 ECU a week calculated from the funds available.
AA will approach possible contractors and contracts will be cleared with MH and FG.
23.6.2 Noted: That it is expected that IBM will continue to support Berthold Pasch.
23.6.3 Resolved: In the light of the requirement for an improved GENROUTES, BITNET will be approached by DJ as to how this should be achieved.
23.6.4 Resolved: In the light of the common interests of EARN and BITNET to maintain GENROUTES, NETSERV, LISTSERV, and DOMAINS discussions will be started with BITNET on the sharing of the costs of maintenance and development by DJ.
23.7.1 Resolved: That EARN will fund half the cost of a secretary for the President. UNI-C will fund the remainder. This will be funded from the office budget since the projected increase in the office budget for the Paris office will not be required in the light of the projected Amsterdam office.
23.7.2 Resolved: That starting January 1, 1989, Kathy Gregury will work full time rather than 80% as secretary of the EARN Paris office.
23.8.1 Resolved: That Executive meetings will be held at two monthly intervals and last for two days.
Discussed in other sections.
23.10.1 Resolved: AA will provide a report on the state of implementation of the EARN directives to the Board of Directors.
23.10.2 Resolved: MH will send the security papers to IBM and report their response to the executive.
23.10.3 Resolved: DJ will provide a copy of the DEC contract to AA.
23.11.1 Noted: The report on an MDNS meeting by JC (page 41).
23.11.2 Noted: The un-adopted minutes of the above MDNS meeting (page 43).
23.11.3 Noted: It was reported that the request for EARN's requirements for participation in the MDNS pilot were not included in a paper from DG13 to MDNS as the Executive had not had time to comment on the draft paper.
23.11.4 Resolved: That -
(1) the paper on EARN MDNS requirements (page 51) be adopted subject to re-drafting by DJ as indicated by the Executive.
(2) a letter be sent by DJ to RARE with copies to MDNS and CPG noting that EARN's requirements are not included and including the EARN MDNS requirements paper.
23.11.5 Noted: Organisational Responsibility for Pilot MDNS Project by JC (page 53).
23.11.6 Noted: Comments on current proposal of MDNS company for X.25 pilot by JC (page 54).
23.11.7 Noted: Comments to the Executive on the RARE COA meeting December 2 by JC (page 55).
23.11.8 Resolved: DJ and FG will produce a list of transition activities where it would be appropriate to seek COSINE funding.
23.11.9 Noted: EARN X.25 Backbone and OSI transition - Nordic position. Page 57 in the briefing document. The letter from Dennis Jennings proposed that EARN should contribute 14.5 KECU in 1989 for the line.
The Executive were unclear as to-
(1) the contribution the Nordic countries, EARN and EUNET would make to the proposed 64K line between Stockholm and CWI.
(2) whether the Nordic countries should be paying to EARN the current cost of their connection to CEARN.
(3) the funding of any overlap period of the two lines.
The Executive considered that the overlap period of the current and proposed Nordic lines should be minimal in the interests of economy. It was not clear whether the early use of a G-box at CWI rather than a bi-synch connection for an interim period would be the best approach. In addition the use of a channel on the CWI to CERN HEP line for an interim period for X.25 or bi-synch had not yet been resolved.
The DEC offer was to fund the upgrade of the backbone to 64K. It is not clear whether this is only applicable to the inter switch links or whether it can also be applied to aiding the move of other connections to X.25.
A number of countries may require to make local changes to the G-boxes. The Executive notes that this may have an implication on the way G-boxes are managed. For example, a G-box may be subject to failures due to local changes or upgrading of software may have implications for local changes.
23.11.10 Resolved: FG will clarify the financial details of the funding of the proposed 64K Stockholm CWI line. Also JC will inform the EXEC of the apparent commitment of EARN to provide 14.5 KECU towards the cost of the Stockholm CWI line.
23.11.11 Resolved: The use of the CWI to Stockholm and the CWI to CERN HEP lines will be further studied and a proposal provided by JC.
23.11.12 Resolved: DJ will clarify the use of DEC provided finance for lines.
23.11.13 Resolved: That the G-boxes are EARN property and that any local changes must be agreed with EARN. Any changes required by EARN will be implemented regardless of local changes (such as operating systems).
23.11.14 Noted: The joint EUNET-HEPNET-NORDUNET-EARN discussions which the Executive is urged to study. Page 68 of briefing document.
23.11.15 Resolved: That it was premature to negotiate co-operative agreements with the proposed super computer network.
23.12.1 Noted: in the absence of a written report AA reported that as of November 31 the figures are-
Office current expenditure budget
Paris 46 KECU 51 KECU
Dublin 98 KECU 86 KECU
144 KECU 137 KECU
The expected out-turn for 1988 is expected to show a deficit of 15 KECU.
23.12.2 Resolved: AA will provide accurate figures by electronic mail to the Executive and Board on December 13.
23.12.3 Resolved: AA will inform Ulrich Giese of the Executives decision to fund his attendance at the forthcoming BITNET meeting subject to a satisfactory outcome of an agreement for EARN table maintenance with Ulrich Giese.
23.12.4 Resolved: In the light of the unresolved situation with respect to the funding of EARN by Germany, AA will issue an invoice for the first 6 months of 1989 for 47 KECUs noting that the amount of the second instalment will be negotiated by FG. Invoice to be sent to Klauss Ullman with copy to MH.
23.12.5 Resolved: In the light of the unresolved situation with respect to the funding of EARN by the UK, AA will issue an invoice for the first 6 months for 37 KECU noting that the second instalment is subject to negotiation. Invoice will be sent to PB. PB will attempt to find an additional 10 KECU of funding to meet the full UK contribution. DJ will reply to the funding letter from Bob Cooper.
23.12.6 Resolved: In the light of the unwillingness of the UK to contribute to the 64K RAL to CERN line, PB will determine the conditions for cancelling the line.
23.12.7 Noted: Due to delays in the installation of OSI 64K lines the funding for 1989 is expected to be sufficient. Page 37 and page 77 of briefing document.
23.12.8 Noted: Clarification of the funding of the Sweden to CWI link is required and there is an action in 23.11.3.
23.12.9 Resolved: FG aided by AA and DL will undertake further work on the funding model which is accepted as a basis for development. Page 74 of briefing document.
23.12.10 Resolved: The registering of EARN as a trade mark will continue and and charges within countries will be paid by EARN.
23.13.1 February 7/8, 1989 - Paris starting at 1030.
23.13.2 April 3/4, 1989 - Paris starting at 1030.
23.14.1 Resolved: AA will provide a report on the current state of the Montpellier lines and on the related CERN meeting.
23.14.2 Noted: that the CERN to Montpellier 64K line is expected by the end of 1988. The availability of this line is a high priority.
Discussed in other sections.
Not discussed.
Not discussed.
Executive meeting 21
Catalogue of EARN documents (AA)
Proposal for rationalising various lists (AA)
AA to report to Exec on responses to agreed mailer
recommendations.
Message to BoD and EARN Tech re staff utilisation
and clarification with DEC (DJ).
Executive meeting 22
DJ/JC to prepare annex to Management of Change proposal
(examples, etc.)
to next Exec agenda
JN - BEARN changes - paper required
JC to co-ordinate papers from ST, JCI, DJ on
exploitation of TAL's
9AA formalise position of deputy to NCC
PB/JC to discuss interoperability test with suppliers
DJ to write to Czechoslovakia
AA to distribute official (French) version of statutes
and English translation
DJ - write to Physics Library
ST - paper on CNUCE-NSF link
JCI - paper on NSFNET IP link
JC to co-ordinate this
Board Meeting October 24/25, 1988
JC to circulate action list
JC to update action list before next BoD
JCI/AA accounts to end of September to BoD
JCI/AA to split travel by category
JCI/AA to produce more accurate projections to year
end
This action is now urgent
AA legal services contract, including termination for
non payment
DJ to raise issue of TAL costs with BITNET
Membership Committee - discuss and propose model for
funding of links to associate networks
Circulate BITNET charter for Associate Networks
Men-Comm. - proposal for new procedure for Associate
Members
JC - statement on conformance by EARN to COSINE specs,
RARE paper
JC - OSI Phase 2 detailed plan
AA - EARN Manager to pursue countries not implementing
directives
Exec - Terms of reference for EARNTech
Agenda for next BoD - SNA
Exec - Management plan, staff description,
organisational plan, hiring plan for EARN staff
Exec - discussion with UK and Germany on budget
Executive meeting 23
23.4.1 To set up sub-group to produce proposals
for sub-groups and EARN TECH FG
23.4.2 To ask CERN if they want an Board member FG
23.4.3 Add to the list of responsibilities Group leaders
23.4.4 To provide paper on future of EARN TECH JC
23.4.5 To draw up Executive meeting procedures PB
23.5.1 To provide OSI resource plan DJ
23.5.1 To provide OSI staffing plan DJ
23.5.1 To provide recruitment plan FG
23.6.1 To arrange contracts for essential tasks AA
23.6.3 To approach BITNET on GENROUTES DJ
23.6.4 To approach BITNET on cost of maintenance DJ
23.10.1 To report on EARN directives AA
23.10.2 To send security paper to IBM MH
23.10.3 To provide DEC contract to AA DJ
23.11.4 To re-draft MDNS requirements paper DJ
23.11.4 To send MDNS requirements paper to RARE DJ
23.11.8 To list activities for COSINE funding DJ
23.11.10 To clarify funding of Stockholm 64K line FG
23.11.10 To inform EXEC on basis of 14.5KECU funding JC
23.11.11 To study use of CWI to CERN HEP line JC
23.11.12 To clarify use of DEC finance DJ
23.12.2 To provide financial figures AA
23.12.3 To provide funding for BITNET meeting AA
23.12.4 To send invoice to Germany AA
23.12.4 To negotiate 2nd German contribution FG
23.12.5 To send invoice to UK AA
23.12.5 To attempt to secure further UK funding PB
23.12.5 To reply to Bob Coopers letter on funding DJ
23.12.6 To find conditions for cancelling UK64K line PB
23.12.9 To refine funding model for 1989 FG
23.14.1 To review Montpellier situation AA
Executive meeting 21
Catalogue of EARN documents (AA)
Resolved: AA and PB to agree the list of documents and provide a
catalogue for the next meeting.
Action AA PB
Proposal for rationalising various lists (AA) Complete
AA to report to Exec on responses to agreed mailer
recommendations. Retain
Message to BoD and EARN Tech re staff utilisation
and clarification with DEC (DJ). Delete
Executive meeting 22
DJ/JC to prepare annex to Management of Change proposal
(examples, etc.)
to next Exec agenda Retain
JN - BEARN changes - paper required Complete
JC to co-ordinate papers from ST, JCI, DJ on
exploitation of TAL's Delete
AA formalise position of deputy to NCC
Resolved: It is recommended that but not mandatory that each Board
of Directors member appoint a deputy for the NCC who will be a
member of the relevant distribution list. AA will inform the BoD.
Action AA
PB/DJ to discuss interoperability test with suppliers
Retain
FG to write to Czechoslovakia Retain
AA to distribute official (French) version of statutes
and English translation Complete
Resolved: The English translation issued as EXEC INF/3/89 will be
amended in the light of comments and reissued for approval by the
Executive as the official English translation by PB.
Action PB
DJ - write to Physics Library Retain
ST - paper on CNUCE-NSF link Retain
JCI - paper on NSFNET IP link Retain
JC to co-ordinate this Delete
Board Meeting October 24/25, 1988
JC to circulate action list Complete
PB to update action list before next BoD Ongoing
JCI/AA accounts to end of September to BoD Complete
JCI/AA to split travel by category for 1989 Retain
JCI/AA to produce more accurate projections to year
end Complete
AA legal services contract, including termination for
non payment Retain
FG to raise issue of TAL costs with BITNET Retain
Membership Committee - discuss and propose model for
funding of links to associate networks Complete
FG Circulate BITNET charter for Associate Networks
Retain
Men-Comm. - proposal for new procedure for Associate
Members Complete
DJ - statement on conformance by EARN to COSINE specs,
RARE paper Retain
DJ - OSI Phase 2 detailed plan Complete
AA - EARN Manager to pursue countries not implementing
directives Complete
Exec - Terms of reference for EARNTech Complete
PB - Agenda for next BoD - SNA Retain
Exec - Management plan, staff description,
organisational plan, hiring plan for EARN staff Complete
FG - discussion with UK and Germany on budget Retain
Executive meeting 23
23.4.1 To set up sub-group to produce proposals
for sub-groups and EARN TECH FG
Complete
23.4.2 To ask CERN if they want an Board member FG
Complete
23.4.3 Add to the list of responsibilities Group leaders
Complete
23.4.4 To provide paper on future of EARN TECH JC
Complete
23.4.5 To draw up Executive meeting procedures PB
Complete
23.5.1 To provide OSI resource plan DJ
Retain
23.5.1 To provide OSI staffing plan DJ
Complete
23.5.1 To provide recruitment plan FG
Complete
23.6.1 To arrange contracts for essential tasks AA
Ongoing
23.6.3 To approach BITNET on GENROUTES FG/MH
Retain
23.6.4 To approach BITNET on cost of maintenance FG
Retain
23.10.1 To report on EARN directives AA
Complete
23.10.2 To send security paper to IBM and inform
EARNTECH of any results MH
Retain
23.10.3 To provide DEC contract to AA DJ
Complete
23.11.4 To re-draft MDNS requirements paper DJ
Complete
23.11.4 To send MDNS requirements paper to RARE DJ
Complete
23.11.8 To list activities for COSINE funding DJ
Complete
23.11.10 To clarify funding of Stockholm 64K line FG
Complete
23.11.10 To inform EXEC on basis of 14.5KECU funding JC
Complete
23.11.11 To study use of CWI to CERN HEP line JC
Retain
23.11.12 To clarify use of DEC finance DJ
Retain
23.12.2 To provide financial figures AA
Complete
23.12.3 To provide funding for BITNET meeting AA
Complete
23.12.4 To send invoice to Germany AA
Complete
23.12.4 To negotiate 2nd German contribution FG
Retain
23.12.5 To send invoice to UK AA
Complete
23.12.5 To attempt to secure further UK funding PB
Retain
23.12.5 To reply to Bob Coopers letter on funding FG/DJ
Retain
23.12.6 To find conditions for cancelling UK64K line PB
Complete
23.12.9 To refine funding model for 1989 FG
Retain
23.14.1 To review Montpellier situation AA
Complete
ACTION LIST
Executive meeting 21
AA to report to Exec on responses to agreed mailer
recommendations. Retain
Executive meeting 22
DJ/JC to prepare annex to Management of Change proposal
(examples, etc.)
PB/DJ to discuss interoperability test with suppliers
FG to write to Czechoslovakia Retain
DJ - write to Physics Library Retain
ST - paper on CNUCE-NSF link Retain
JCI - paper on NSFNET IP link Retain
Board Meeting October 24/25, 1988
PB to update action list before next BoD Ongoing
JCI/AA to split travel by category for 1989 Retain
AA legal services contract, including termination for
non payment Retain
FG to raise issue of TAL costs with BITNET Retain
FG Circulate BITNET charter for Associate Networks
Retain
DJ - statement on conformance by EARN to COSINE specs,
RARE paper Retain
PB - Agenda for next BoD - SNA Retain
FG - discussion with UK and Germany on budget Retain
Executive meeting 23
23.5.1 To provide OSI resource plan DJ
23.6.1 To arrange contracts for essential tasks AA
23.6.3 To approach BITNET on GENROUTES FG/MH
23.6.4 To approach BITNET on cost of maintenance FG
23.10.2 To send security paper to IBM and inform
EARNTECH of any results MH
23.11.11 To study use of CWI to CERN HEP line JC
23.11.12 To clarify use of DEC finance DJ
23.12.4 To negotiate 2nd German contribution FG
23.12.5 To attempt to secure further UK funding PB
23.12.5 To reply to Bob Coopers letter on funding FG/DJ
23.12.9 To refine funding model for 1989 FG
EARN EXECUTIVE: Paul Bryant, (PB) Technical Director
Frode Greisen, (FG) Membership Secretary
Michael Hebgen, (MH) Secretary
Jean-Luc Delahay representing
Jean-Claude Ippolito, (JCI) Treasurer
Dennis Jennings, (DJ) President
David Lord, (DL) Vice President
Stephano Trumpy, (ST) CEPT liaison
ELECTED EXECUTIVE MEMBER: Avi Cohen (AC)
EARN STAFF: Alain Auroux, (AA) Paris Office
Joe Chester, (JC) Dublin Office
Cathy Gregury (CG) Paris Office
Information of a contractual or personal nature which could prejudice EARN negotiations is not included in the published EARN Executive minutes.
23.0.1 The meeting was chaired by Frode Greisen the President elect.
23.0.2 The Executive warmly thanked Dennis Jennings for his work in EARN over the past two years as president. Grateful thanks were extended to Joe Chester as this would be his last meeting as the Presidents assistant.
23.0.3 The following items were added to the agenda:
(1) 14 CERN to Montpellier link
(2) 15 LISTSERV
(3) 16 Morocco/Italy link
(4) 17 Joiners software support
23.1.1 Resolved: To accept the minutes of the last meeting with the following corrections:
(1) Item 14 paragraph 4 line 5 - replace "exploid" by "exploit".
(2) Item 22 paragraph 5 line 1 - replace "analysis" by "review".
(3) Item 23 paragraph 5 line 4 - replace "correct" by "reasonably accurate" and "The idea" by "However, the idea".
23.2.1 Resolved: That for these minutes and future minutes-
(1) Minutes will be circulated electronically to the Executive for comment for one weeks.
(2) Minutes corrected from Executive comments will be circulated electronically to the Board of Directors for comment for two weeks.
(3) Minutes corrected from Board of Director comments will be signed as correct at the subsequent Executive meeting.
23.2.2 Noted: The following Executive comments -
(1) Section 88.30.2 paragraph 1 line 6 - Delete sentence "It was agreed..." by "It was agreed that either the total contribution should be invoiced by January 1, 1989 to be paid by January 31, 1989 or half be paid by January 31, 1989 and the remainder by July 1, 1989.".
(2) Section 88.30.4 page 17 paragraph 3 - add "KECU" to each cost.
(3) Section 88.30.4 penultimate paragraph - add second sentence "Germany can commit to the 1988 model, not the level.".
(4) Section 88.30.4 paragraph 8 line 7 - delete "and eventually Belgium.".
(5) Section 88.31 (EARN ASSOCIATION page 14) paragraph 1 line 2 - replace "seat" by "registered office" which is a better translation of the French term "siege".
(6) Section 88.32.2 paragraph 1 line 3 - delete sentence "Together...".
(7) Section 88.33 paragraph 2 line 2 - replace "Paul Bryant...MDNS pilot" by "Paul Bryant stated that EARN wants to be technically as close as possible to the COSINE specification. EARN is ready to adjust or modify its plans to take account of the MDNS pilot.".
(8) Section 88.36.1 line 4 - add to end of line ", Udo Meyer"
(9) Section 88.36.2.2 paragraph 1 line 2 - replace sentence "Dennis Jennings..." by "Dennis Jennings stated that there should be only one international node in a country.".
(10) Section 88.37.4 paragraph 1 line 3 - replace "permanent" by "full time".
(11) Further amendments have been sent electronically to MH.
Board Meeting October 24/25, 1988 JC to circulate action list Retain JC to update action list before next BoD Ongoing JCI/AA accounts to end of September to BoD Retain JCI/AA to split travel by category Retain JCI/AA to produce more accurate projections to year end Retain This action is now urgent AA invoices to countries for contributions (January 1) Complete AA legal services contract, including termination for non payment Retain DJ to raise issue of TAL costs with BITNET Retain Membership Committee - discuss and propose model for funding of links to associate networks Retain Circulate BITNET charter for Associate Networks Retain DJ - E-bloc issues to CPG Complete Write to COCOM (DJ) Complete Write to countries concerned (DJ) Complete Men-Comm. - proposal for new procedure for Associate Members Retain Exec - continue discussion and get more clarification from NORDUNET Complete JC - copy NORDUNET letter and reply to BoD Complete ST/DJ to have informal discussion with CEPT on 1989 Delete DJ write to CPG - participation in pilot MDNS, CIP, and seek support (resources) for that involvement Complete JC - statement on conformance by EARN to COSINE specs, RARE paper Retain JC - OSI Phase 2 detailed plan Retain AA - EARN Manager to pursue countries not implementing directives Ongoing MH to add topology diagram to Minutes Deleted AA to discuss connection of Morocco to Pisa not Bari Complete Exec - Terms of reference for EARNTech Retain Agenda for next BoD - SNA Retain Exec - Management plan, staff description, organisational plan, hiring plan for EARN staff Retain Exec - discussion with UK and Germany on budget Retain
23.4.1 Resolved: FG will set up a sub-group to draw up a proposal based on the Executives discussion on the structure of sub-groups and the place of EARN TECH.
23.4.2 Resolved: In the light of the request from CERN to be represented on the EARN Board of Directors, FG will seek the agreement of the Board of Directors.
23.4.3 Resolved: that the responsibilities of Executive members are:
Operation MH aided by JCI and AC
Present international backbone, NOG, NAD,
statistics, security.
Information/Communications PB aided by DJ
Minutes, lists, file-store for documents,
annual report, brochure.
Finance JCI aided by FG
Accounts, budgets, funding, payment model.
Development DJ aided by PB and MH
OSI, SNA, second transatlantic line.
Policy AC aided by FG
Membership, charter, code of conduct, BOD
operational procedures.
Liaison FG aided by MH and ST
CEC, CEPT, RARE, COSINE, suppliers, other
networks.
Users ST aided by AC
Applications, user services, earntech,
users' meetings.
Further details and other topics will be provided by the relevant member.
23.4.4 Resolved: That JC will provide a paper on the future of EARN TECH to be agreed with ST to the next Executive meeting based on discussions at this meeting. The paper when accepted by the Executive will be sent to the Board of Director's members for discussion with EARN TECH members.
23.4.5 Resolved: PB will draw up operational procedures for Executive meetings which include how Executive minutes and papers should be circulated.
23.5.1 Resolved: That-
(1) The OSI operations centre will be in the Einstein Centre in Amsterdam.
(2) DJ will provide a plan for the resources involved to be developed from the OSI project plan.
(3) DJ will provide a staffing plan for 1989 for at least one man year for OSI which will be approved by The Board of Directors before implementation.
(4) FG will provide a paper on recruitment for the Amsterdam Centre.
23.6.1 Resolved: that EARN will contract with site staff for essential activities for 1989. The activities to be contracted and the manpower to be allocated are based on estimates by EARNTECH.
Contracts may be with organisations or individuals depending on circumstances.
Work other than maintenance, financed by EARN will be the property of EARN. This will be clarified with the person or organisation involved before setting up an agreement
LISTSERV support will be on the basis of full, free, and continuing access to LISTSERV by EARN members.
The permission of contractors' managers to undertake EARN work will be sought.
EARN would not expect to pay for computer resources.
AA will approach possible contractors and contracts will be cleared with MH and FG.
23.6.2 Noted: The IBM contribution to the maintenance of EARN.
23.6.3 Resolved: In the light of the requirement for an improved GENROUTES, BITNET will be approached by DJ as to how this should be achieved.
23.6.4 Resolved: In the light of the common interests of EARN and BITNET to maintain GENROUTES, NETSERV, LISTSERV, and DOMAINS discussions will be started with BITNET on the sharing of the costs of maintenance and development by DJ.
23.7.1 Resolved: That EARN will fund half the cost of a secretary for the President. UNI-C will fund the remainder. This will be funded from the office budget since the projected increase in the office budget for the Paris office will not be required in the light of the projected Amsterdam office.
23.7.2 Resolved: That starting January 1, 1989, Kathy Gregury will work full time rather than 80% as secretary of the EARN Paris office.
23.8.1 Resolved: That Executive meetings will be held at two monthly intervals and last for two days.
Discussed in other sections.
23.10.1 Resolved: AA will provide a report on the state of implementation of the EARN directives to the Board of Directors.
23.10.2 Resolved: MH will send the security papers to IBM and report their response to the executive.
23.10.3 Resolved: DJ will provide a copy of the DEC contract to AA.
23.11.1 Noted: The report on an MDNS meeting by JC (page 41).
23.11.2 Noted: The un-adopted minutes of the above MDNS meeting (page 43).
23.11.3 Noted: It was reported that the request for EARN's requirements for participation in the MDNS pilot were not included in a paper from DG13 to MDNS as the Executive had not had time to comment on the draft paper.
23.11.4 Resolved: That -
(1) the paper on EARN MDNS requirements (page 51) be adopted subject to re-drafting by DJ as indicated by the Executive.
(2) a letter be sent by DJ to RARE with copies to MDNS and CPG noting that EARN's requirements are not included and including the EARN MDNS requirements paper.
23.11.5 Noted: Organisational Responsibility for Pilot MDNS Project by JC (page 53).
23.11.6 Noted: Comments on current proposal of MDNS company for X.25 pilot by JC (page 54).
23.11.7 Noted: Comments to the Executive on the RARE COA meeting December 2 by JC (page 55).
23.11.8 Resolved: DJ and FG will produce a list of transition activities where it would be appropriate to seek COSINE funding.
23.11.9 Noted: EARN X.25 Backbone and OSI transition - Nordic position. Page 57 in the briefing document. The letter from Dennis Jennings proposed that EARN should contribute 14.5 KECU in 1989 for the line.
The Executive considered that the overlap period of the current and proposed Nordic lines should be minimal in the interests of economy. It was not clear whether the early use of a G-box at CWI rather than a bi-synch connection for an interim period would be the best approach. In addition the use of a channel on the CWI to CERN HEP line for an interim period for X.25 or bi-synch had not yet been resolved.
The DEC offer was to fund the upgrade of the backbone to 64K. It is not clear whether this is only applicable to the inter switch links or whether it can also be applied to aiding the move of other connections to X.25.
A number of countries may require to make local changes to the G-boxes. The Executive notes that this may have an implication on the way G-boxes are managed. For example, a G-box may be subject to failures due to local changes or upgrading of software may have implications for local changes.
23.11.10 Resolved: FG will clarify the financial details of the funding of the proposed 64K Stockholm CWI line. Also JC will inform the EXEC of the apparent commitment of EARN to provide 14.5 KECU towards the cost of the Stockholm CWI line.
23.11.11 Resolved: The use of the CWI to Stockholm and the CWI to CERN HEP lines will be further studied and a proposal provided by JC.
23.11.12 Resolved: DJ will clarify the use of DEC provided finance for lines.
23.11.13 Resolved: That the G-boxes are EARN property and that any local changes must be agreed with EARN. Any changes required by EARN will be implemented regardless of local changes (such as operating systems).
23.11.14 Noted: The joint EUNET-HEPNET-NORDUNET-EARN discussions which the Executive is urged to study. Page 68 of briefing document.
23.11.15 Resolved: That it was premature to negotiate co-operative agreements with the proposed super computer network.
23.12.1 Noted: in the absence of a written report AA reported that as of November 31 the figures are-
Office current expenditure budget
Paris 46 KECU 51 KECU
Dublin 98 KECU 86 KECU
144 KECU 137 KECU
The expected out-turn for 1988 is expected to show a deficit of 15 KECU.
23.12.2 Resolved: AA will provide accurate figures by electronic mail to the Executive and Board on December 13.
23.12.3
23.12.4 Resolved: In the light of the unresolved situation with respect to the funding of EARN by Germany, AA will issue an invoice for the first 6 months of 1989 for 47 KECUs noting that the amount of the second instalment will be negotiated by FG. Invoice to be sent to Klauss Ullman with copy to MH.
23.12.5 Resolved: In the light of the unresolved situation with respect to the funding of EARN by the UK, AA will issue an invoice for the first 6 months for 37 KECU noting that the second instalment is subject to negotiation. Invoice will be sent to PB. PB will attempt to find an additional 10 KECU of funding to meet the full UK contribution. DJ will reply to the funding letter from Bob Cooper.
23.12.6 Resolved: In the light of the unwillingness of the UK to contribute to the 64K RAL to CERN line, PB will determine the conditions for cancelling the line.
23.12.7 Noted: Due to delays in the installation of OSI 64K lines the funding for 1989 is expected to be sufficient. Page 37 and page 77 of briefing document.
23.12.8 Noted: Clarification of the funding of the Sweden to CWI link is required and there is an action in 23.11.3.
23.12.9 Resolved: FG aided by AA and DL will undertake further work on the funding model which is accepted as a basis for development. Page 74 of briefing document.
23.12.10 Resolved: The registering of EARN as a trade mark will continue and and charges within countries will be paid by EARN.
23.13.1 February 7/8, 1989 - Paris starting at 1030.
23.13.2 April 3/4, 1989 - Paris starting at 1030.
23.14.1 Resolved: AA will provide a report on the current state of the Montpellier lines and on the related CERN meeting.
23.14.2 Noted: that the CERN to Montpellier 64K line is expected by the end of 1988. The availability of this line is a high priority.
Discussed in other sections.
Not discussed.
Not discussed.
As this is the last report this year it is appropriate to take a broad look at this year and next.
The last major component of the LAN - the LAN WAN gateway - is now in place and the service is about to be passed to operations. This marks the culmination of a two year development period. It is appropriate to pay tribute to Gunadhi for the initial and far sighted project plan and to Graham Robinson for bringing it to fruition. The efforts of the many other members of this and other Departments should not be forgotten.
Looking forward the DEC Pink Book will soon be officially released by DEC. Thus the scene is now set to start to capitalise on the investment. If all goes well there should be an increase in the current 5% level of Pink book traffic. For comparison the DECNET traffic accounts for about 80%, 5% is TCP/IP, and 10% is management overheads. How quickly the Pink Book traffic will rise and how this will effect the current X.25 network will be interesting to see.
An interesting aspect of the site traffic is that more and more terminals are either 3270 or VT 200 (or equivalent. It seems the days of the simple line at a time terminal are numbered. Another aspect is that workstations seem to be on the brink of popularity. Already we see that IBM PCs are replacing dumb terminals - we expect the more advanced workstations to become more widespread. The job of the network experts is to integrate all this equipment. The ideas are well advanced - the implementation is expensive and needs further product development in many cases. The existence of the LAN provides a firm basis for development.
Perhaps the most immediate area of concern is how off site workstations are connected and here study is under way.
TMPC has asked for comparative statistics to be appended to the Quarterly Progress report. This is the subject of a detailed study which should be reflected in a later report.
1.1.1 JTMP Host-end Service
Release 3 of Network/VM continues to provide a reliable service for network job submission/retrieval for the Cray and Slacbatch jobmills. This version has also been exported to UMRCC now.
A bug that causes a process within the software to hang has been circumvented, but is not fully understood yet. It appears to be a problem in the ULCC interface code. Work is currently in progress to tidy up and rationalise this interface.
Documentation of the local mods to the software, including the ULCC interface, has been produced.
A further local mod was needed to make the package run under VM/XA.
1.1.2 NIFTP
The new facilities for communicating with the NIFTP virtual machines have been installed. In particular, end-users can now use the 'FTP QUERY' or 'FTP QUERY ALL' commands to enquire about the progress of their files. There are also new user support facilities.
Mods were necessary to make the virtual machines run under VM/XA:
(1) Spooling is asynchronous under VM/XA.
(2) The FTP and JTMP execs needed to cope with the different way that spoolids are used.
The NIFTP retry mechanism has been re-designed to reduce overheads substantially and to prevent crises due to accumulations of large numbers of EARN files. This is now in service.
1.1.3 NETJOB and NETFILE
These are alternative user interfaces for job and file transfer respectively, produced by ULCC, and intended to be portable across a number of machine types. It is possible that NETJOB at least may be of interest for use at RAL. To allow some evaluation, NETJOB has been set up to spool files to NIFTP, and it looks as if it would be fairly easy to do the same for NETFILE. The alternative of interfacing NETJOB to SPCP (which is what ULCC envisaged) would be less easy, but UMRCC say they wish to do the work for this in any case.
1.1.4 SSMP
Version 1.1.2 is now installed, and is an improvement over the previous version. It contained a bug which prevented it working under VM/XA, but it was possible to fix this by a local zap.
1.1.5 Pink Book
Still not a service. The latest MAC driver from ULCC is now installed, but performance measurements have not yet been made.
1.1.6 CMS-PAD
Version 1.6, and then 1.7 were installed during this period. These dealt with the backlog of known bugs and defects, and also the mods necessary for running under VM/XA and from terminals connected via the new line-mode support code in VMNCP.
1.1.7 VTAM
VTAM was brought into service under VM/XA with the limited role of supporting the new method of line-mode terminal handling. It also supports some Lee Data terminals located at Swindon.
The project to use VTAM with IBM's NCP/NPSI in the 4705 is separate. Two successful 1-hour sessions have been conducted, but it was not possible to do a prolonged test under normal load because extra memory for the 4705 was awaited. This arrived in late October. Progress with this project must now await resolution of the remaining problems with the VM/XA transition. The major problem preventing the use of 48K links turned out to be a bug in NPSI. This has been fixed temporarily by a local zap. Another defect in NPSI, which failed to negotiate window and packet sizes for outgoing calls, has been fixed temporarily by a fairly large mod at source level.
1.1.8 Line mode terminal support
The new method of supporting this is now installed under VM/XA. It comprises two new routines in VMNCP, which pass the calls through VTAM to VSCS, which in turn maps them onto the SNA-CCS service in CP.
Although technically this solution is applicable to the Ethernet service also, it has not yet been installed there.
The service in general works ok, but there are reliability problems due to an abend occurring in the VTAM application program interface code (problem under study by IBM), and a hang that occasionally occurs due to VTAM exits not being scheduled. It is not known whether these problems are really in VTAM or in the VMNCP code that drives it.
1.1.9 VMNCP
For the VM/XA transition, it was necessary to put into service a version that runs under GCS, and containing the new line-mode terminal support (see last Section). These are substantial changes.
1.1.10 Routine Maintenance
Nothing specific to report.
1.2.1 The top priority must be to re-attain the pre-XA degree of reliability in the network services generally. This is likely to consume a lot of effort as there seem to be several quite separate problems.
1.2.2 Production testing of Coloured Books over VTAM/NCP/NPSI using the 4705 should occur. If satisfactory, a service could be offered by this method, instead of using the COMM-PRO software.
1.2.3 Versions of NIFTP, and of the FTP, JTMP and PAD user interfaces, will be needed for running under CMS 5.5. This may be a non-trivial task.
1.2.4 Versions of VMJTMP and SSMP for CMS 5.5 are also needed, but we will probably be dependent for these on Salford and Edinburgh respectively, and compatible versions are unlikely to appear yet.
1.2.5 Some support for the restarting ('resumption') of large transfers should be introduced into NIFTP.
1.2.6 Performance testing of the Ethernet trial service with the latest ULCC MAC driver should occur. Line-mode terminal support should be re-introduced via the VTAM/VSCS route. A substantial amount of work is required to turn the trial service into a full, properly-maintained service: possibly a few man-weeks. Whether this is done will depend on its priority relative to other things.
In the longer term, migration towards ISO protocols using manufacturer-provide software.
2.1 Review of August/September/October
2.1.1 LOCAL
Overall the period has been quieter than normal. PACX had three incidents each affecting one user. Camtec PADs had twenty incidents of which half were cured by re-load, three required boards to be returned to Camtec for repair and the others were fixed with chip changes done locally. CPSE had a number of restarts during AUGUST and these were fixed by cleaning the edge connectors, CPSE2 had no unscheduled breaks during the period.
One worrying incident concerns the reliability of the Pilkington Muxs. A power supply failed and was duly returned for repair, only for another to fail within days. Pilkington have now admitted a fault in the power supplies and we are currently endeavouring to get all (seven) of ours changed.
The BSC connections to Glasgow and Imperial College have now been removed and the BT lines cancelled. Lines to Edinburgh and Imperial for PACX connections have also been cancelled. Arrangements are in hand to remove the Brunel PACX connections.
The UK end of the CERN (PPD) 64K line has been installed. BTI have changed the reporting centre for International lines and they like BT have had teething problems.
The SEEL Multipac (previously call Telepac) has been connected to the Spider X200 gateway and calls established through.
GPT PSE type 3.1J has been loaded on CPSE2, this allows X.25(84) support, and support up to 104 links per exchange.
One additional PAD has been added onto the X.25 network, this to support Diablo Terminals that previously went directly into the 4705 for Profs users, as direct 'line mode' access was dropped with the introduction of VM/XA. Telecoms were informed retrospectively of this requirement.
2.1.2 JANET
Another period of very poor reliability on the JPSE. However a number of faults have been identified and cured. The first of these being a clash of Way numbers between the last channel on the second FMC and the first channel on the DMAC - this was a GPT set-up fault. A memory problem appears to have been the cause of a number of random IPLs. The remaining problem is with CI Timeouts (Channel Interface) and this has been escalated by GPT Field Service to GPT Engineering. The current situation is that hardware analysers have been attached to the system to determine what is happening.
GPT Type 3.1J has been loaded and this has X25(84) support and this is currently set for the trunk lines to Edinburgh and Cambridge.
AERE Harwell and RAE Farnborough have both now connected to the JPSE. Swansea now have a 64K line to BUCS and the analogue line has been closed and is expected to be removed soon.
BT have still to arrange for the installation of the Warwick 64K line to RAL, the latest date is 4 November.
The table below shows the statistics for the period for the CPSEs and JPSE.
CPSE2 CPSE JPSE
Aug Sep Oct Aug Sep Oct Aug Sep Oct
Downtime .00 .00 .52 4.19 .23 .00 2.33 1.34 25.07
Scheduled .00 .00 .52 .11 .00 .00 2.21 .09 7.00
Unscheduled .00 .00 .00 4.08 .23 .00 .12 1.25 18.07
Interruptions 0 0 1 7 1 0 9 13 35
Scheduled 0 0 1 1 0 0 3 2 10
Unscheduled 0 0 0 6 1 0 6 11 25
MTBF - - - 124 720 - 124 65 30
Availability 100 100 99.88 99.42 99.95 100 99.42 99.95 100
(percentage)
Ave Daily Traf 50 45 57 164 148 179 382 383 429
(Mbytes)
Merge the two site CPSEs - scheduled for 5th November. Installation of CERN 64K line and multiplexors, started late October, now awaiting final line-up of line and delivery of multiplexors. Chase Amdahl about delivery of X.21 interface. Connect SEEL into JPSE and CPSE.
Continue rationalisation of external lines. Evaluate 'Enhanced Consoles' for SEEL Multipac.
There was a 24% increase in the number of faults reported to the sub-section in this quarter.
The section has lent support in the repair of IBM and Memorex screens by Kode. During the period there were 10 of these included in the 31 shown below.
During the period 128 faults were reported to the sub-section, of which 60 were repaired by sub-section staff and the other 68 by maintenance agencies.
The distribution of agency repairs is as follows:
MSM 34 Movable terminals
KODE 31 Non-movable terminals
SIGMEX 4 Sigmex terminals only
The 128 faults have been analysed for divisional distribution.
___________________________________________________
| | REPAIR AGENCY | |
|Division|_________________________________| |
|-Project| TCOM | MSM | KODE |SIGMEX|OTHER| TOTALS |
|________|______|______|______|______|_____|________|
| ADM | 5 | | 3 | | | 8 |
| AG | 2 | 2 | 1 | | | 5 |
| ALVEY | 2 | | | | | 2 |
| BNSC | 3 | 1 | 4 | | | 8 |
| CCD | 26 | 13 | 7 | 3 | | 49 |
| CO | | | 2 | | | 2 |
| EBW | | 1 | | | | 1 |
| ECF | | | | | | |
| HEP | 10 | 7 | 4 | | | 21 |
| ID | 3 | 3 | | | | 6 |
| INS | 1 | 2 | 1 | | | 4 |
| ISIS | 2 | 4 | 2 | | | 8 |
| LASER | 1 | | | | | 1 |
| ND | | | | | | |
| SL | 1 | | 1 | | | 2 |
| TEC | 4 | 1 | 6 | | | 11 |
|________|______|______|______|______|_____|________|
| TOTALS | 60 | 34 | 31 | 3 | | 128 |
|________|______|______|______|______|_____|________|
It is expected that the sub-section will assist in the repair of the IBM screens at Central Office Swindon, in the same way as the RAL terminals already mentioned.
Various coaxial cables were installed due to the expansion in the use of full screen devices; extra cables were also installed due to office moves.
Cables were installed at very short notice to support Diablo printers following the introduction of VM/XA.
An X.25 link was installed to R25 for a microVAX.
A thick ether cable was installed around the Atlas Centre, this will be used for the CCD production ether. The BNSC ether was extended in R25 and several new DECservers connected to the ether in R68.
Cabling for Appletalk was installed in R20.
A 9600 bps dial-up modem was installed in Henrietta Street (London office) to provide PROFS; this is a temporary measure until BT has re-routed the leased line that was going to Great Portland Street.
The 39 panels and the majority of the cables required for the new patching facility for full screen devices have been completed.
Extra coaxial cables will be laid to the R61 library to support an additional twelve terminals.
The CCD production ether should be commissioned. Additional DECservers to be installed in R25 on the A&G ether. A 32 channel terminal server is to be installed in R68 to replace four DECservers. Switches are to be installed so that a village may be quickly disconnected from its bridge.
Linedrivers and switches will be installed to allow operators in R27 to control the Xerox printer in R1.
There will be a phased replacement of the Focom full screen multiplexors.
5.1.1 Network Software
The field test on the CBS V5.0 has taken place on the 11/750 (RL.VE) between September and early October. The final production version of the CBS V5.0 was received and installed on RL.VE on 27th October. Minor problems are still being uncovered with this production release and they are being reported back to DEC.
PSI V4.2 has been released in October but since this release of PSI does not work with the current version of CBS (V4.2-4), sites using CBS including the CRAY Front-End VAX (RL.VMSFE) have to wait for CBS V5.0 before they can install this release of PSI.
5.1.2 Network Hardware
There has been no change of hardware on both the development VAX and the Cray VMS Front-End VAX. However it may be worth mentioning that the recent addition of an X.25 line on RL.VE in May has been found very efficient and reliable in handling the X.25 traffic for the VAX.
In addition, the provision of the dual X.25 lines also enabled the field test of the CBS to take place with easier control on the test and with minimal disruption to the users .
The regular networking support of PSI, CBS and Red Book continues. NRS updates continues to be produced and queries on Pink Book, DECNet, LAVC, PSS/IPSS, VMS-COMMS, EARN and Janet mailshr continue to be handled.
Some assistance has been provided to a few SERC sites with the installation of LLC2 V1.0 which was released in late July.
Another security loophole has been reported by a VAX manager and subsequently a replacement image has been obtained from DEC and has been made publicly available via RL.VE.
A few hacking incident reports have been received with the sources suspected from UCL and Manchester, both allowed their local PADs to accept network calls and route them out to JANET. These sites have been contacted and are understood to have taken some measures to remove the loophole.
No major problems have been reported.
It has been disclosed in the October VUG meeting that the GIFT service between JANET and CERN would be terminated in the near future due to the reasons that the major CERN Wylbur machine was about to be phased out and there was insufficient personnel to upgrade the Gift software to work on CBS V5.
The CBS V5.0, JTMP V5.0 and LLC2 V1.1 are hoped to be released by the end of November. It is expected that considerable efforts will be required to assist the SERC VAX managers to resolve the problems that they may encounter with this new software.
Problems may also be encountered with the underlying software PSI V4.2 which has just been recently released in October.
With the release of the CBS V5.0 and LLC2 V1.1, it is expected that there will be an increase in the use of the CBS on LLC2 over the backbone Ethernet from the VAX users on site. The LLC2 provides a much faster channel for communications between VAXes and the IBM.
6.1.1 NJE
The re-arrangement of the EARN and HEP traffic has finally been completed. Figures should now reflect more accurately the HEP and other traffic. It turned out that the topology in CERN is complicated and it is impossible to direct traffic over the correct line.
The traffic levels continue to rise erratically and are now over 2G bytes a month.
Mick Reid has now completed the statistics work to the satisfaction of the Network Executive. A number of tables and graphs can now be obtained by the use of SAS.
6.1.2 File transfer between EARN and JANET
There have been no changes. The FTP exec will still not operate through Montpellier.
6.1.3 Mail
Most of the work on the mail system is now directed to the improvement of the site service.
The experiments with LISTSERV have shown that lists can span EARN and JANET. The VAXVMS list has been set up and now has over 100 members. A data base has been set up for the humanities as well as a distribution list and this is working well.
Further exploitation is now a question of manpower to support lists and politics on who can have lists. The development group cannot support any further extension of the service.
6.1.4 EARN management
The EARN Board of Directors meeting was held in Israel in October.
The budget and subscriptions were agreed with the exception that Germany and the UK required to have further consultation. Discussion with the JNT on funding issues are continuing.
Much of the discussion concerned EARNs transition which is now entering its implementation phase.
EARN has agreed to take part in the COSINE X.25 pilot project as long as this does not prejudice EARNs own network.
The EARN UK user meeting has revealed that the users are well satisfied. Mail does not get lost in the gateway. The service is valued and is very popular. The poor performance of the USA link is considered by the users to be exaggerated. The user support provided by RAL is very highly valued.
The Northern Telecom EARN switch will be delivered and commissioned as well as the switches in CERN, CWI, and Montpellier in December. The CERN-RAL 64K EARN X.25 line will be delivered in February.
The VAX system for the G-box will be delivered in January and test will be carried out with other sites. The IBM E-box software will be delivered and tested.
The efficiency changes in the mailer should start to reduce the overheads of the EARN mail gateway. It has yet to be determined whether the two mailers can be amalgamated. This study has been shelved until the new mailer is in use. Unfortunately it will not work under XA yet.
The X.25 network should replace the bi-synch network in mid 1989.
The Hyperchannel and all its connections performed without trouble during the period.
The Cray specialist for the VAX station spent several occasions at RAL still trying to resolve why the VAX logged errors when none were actually occurring. By the end of October a final fix had been obtained and we now see no errors logged by the VAX. The reason for the problem was a lack of understanding by Cray on how it should handle contention problems on the A400.
None expected
None.
A beta test version of the Edinburgh Rainbow software has been briefly tried. This is an implementation of Pink Book and supports both FTP and terminal emulation. Initial impressions were favourable and as it supports VT100 and Network/3270 protocols this is likely to be used at RAL in preference to the Exeter/BICC software. The Network/3270 implementation has yet to be tested due to addressing problems to the IBM.
The MOS Network/3270 program, version 2, is almost ready for release. Considerable effort has been expended to improve the lot of remote users with extensive support for setting PAD parameters and customisation of host addressing. MOS can now reliably support 19.2Kb on a PC/AT or PS/2 model 50 giving a response level not far short of a coaxial connection. An initial implementation of a file transfer system based on that used by the PC3270 coax links is on beta test. It requires RAL versions of IBM's SEND and RECEIVE programs to be written before it can be released to avoid licensing problems.
Development of a PC based Console Monitor program (S J L Addams) for GEC X.25 Exchanges continues and a reliable version is now under test with the Network Executive. Documentation is currently being written and Bill Jenkins of the Network Executive is working on printer support.
Further testing and releases of the Edinburgh Rainbow software should produce a version that can be tested by selected CCD users.
The release of MOS v2 is expected to bring demand for an early user release of file transfer.
The pressure of PC support work is seriously curtailing PC networking developments and this will continue until additional effort is provided.
There have been three incidents on the backbone this period. One was the first equipment failure when a Fibre Optic transceiver failed. It was diagnosed and fixed in one and half working hours. The other two were due respectively to operational problems and human error pulling on cables.
Papers defining how both the backbone, the CCD ethernet and CCD services will go into production service have been agreed and are being implemented. Both ethernets should commence a production service in January. CCD services will be available via the CCD development ethernet and will migrate to to the CCD production ethernet when they achieve production status.
Traffic is rising very slowly but a boost is expected when the VAX Pink Book software goes into service on several machines.
A hardware fault was diagnosed on the spare Auscom and the boards have been sent away for repair. KMW has verbally proposed a maintenance contract for both hardware and software but despite repeated requests has failed to put it into writing. The software problem where several restarts cause the Auscom to run out of memory is still with us and awaits N Gunadhi's attention.
Progress on resolving problems with the Spider PADs has been slow but a new release of the firmware in December is supposed to have fixed some of them. Problems when Network/3270 is used over the Spider PAD are now understood and may require further development of the PAD for resolution.
A Camtec PAD has also been loaned for evaluation.
The Spider X200 X25 gateway has arrived and is being installed ready for testing.
A trial X25 gateway service on the CCD village should commence.
Both the backbone and CCD ethernets should become production services.
Plans for the provision of TCP/IP support on the IBM should be clarified.
The failure to recruit a LAN Specialist means that networking developments are being held back.
Monitoring utilities for NIFTP are now in place. This allows files to be pin-pointed which cause problems here or other on sites. These problems are due to protocol problems or with retry algorithms. Often mail fields can cause other NIFTPs to reject EARN mail, however there is now advice on this and failed mail is causing fewer problems. ARPA-BITNET lists are losing Date: fields - this looks like a problem of LISTSERVs at other sites, however this is being investigated. There is now some better information on IBM translation tables - the report pin-points the characters which trouble us as a difference between two translation options at various sites. It may be possible to discover When EARN can pass ASCII characters used by TEX.
The name 'earn-relay' is now well established. There is now better contact with UCL. It appears that the syntax '@relay:user@site' signifies either a faulty mailer or badly set-up user command as several sites have agreed to fix the problem on knowing of it. The gateway's ability to cope with longer names immediately reduced the amount of failed mail when it was made to work reliably.
Ted Chance is now trying out the Fawn Box to get remote access to JANET in full-screen mode. This is something not available in the USA without a direct modem link. Montpellier seem to be the cause of fewer delays, however Cambridge claim that the delays are increasing - Unfortunately, Montpellier back up files at random intervals so it is difficult to measure the real problem. The size of files which are likely to be held are known and most delays are due to complete break downs rather than over-large files (the cut-off point is around 0.5 Mbytes)
Ireland now has some servers in action. They are quite popular and the gateway permits reliable fetches. Canada has asked whether RAL would like to PEER to their HUMANIST list, which would cut EARN traffic, however at the moment there is a bug in its mail which first needs to be detected. ARPA had a well-publicised total failure (of 600 machines) after a hacker had tried to hack his own machine as a test. This resulted in many enquiries but not many EARN users were in fact affected.
Translation table problems at the moment seem to reduce to IBM 'code page 500', however even the contents of this table are hard to locate and the table has yet to be tested. It may be possible to use graphics abroad and fetch object code if this new evidence is true, EARN would be better able to claim that it was a 'supercomputer network' if encoded files could be transferred.
There is now quite a lot of extra help in returning dead mail in the form of simple XEDIT profiles working from RDRLIST, standard help files and NAMES entries for user supporters on machines where EARN is heavily used.
Dominique Pinse (France) has sent an EARN booklet which contains all the sites and their contact names. It is not hard to produce but would take a very long time and would be onerous to update.
It is still true that diagnosing FTP or addressing errors takes up AT LEAST half a day per month. This does not include enquiries from users with finger trouble and inventors of entire new addressing schemes.
Some sites are on BITNET and not on ARPA, but have ARPA-style names; it will be interesting to see how the traffic shifts as the JNT's INTERNET gateway becomes known in its new 'open' role. Liaison with other gateways is vital as there is no single network with world-wide contact, however more US networks now use X25 and there is even an EAN gateway in the USA. SUNET has not proved easy to reach via EAN.
Our documentation is now generally available from NETSERV@earn-relay or NETSERV@ukacrl.bitnet by mail. This has increased use of that help and also allowed foreign users a simple way to fetch it. At a time when BITNET is improving, a lot of enquiries were received about places other than the UK. This is gratifying, as two years ago the UK were seen as a 'black hole' for mail with a cock-eyed domain order. No users now rely on the 'EARN out - ARPA back' mailing method to reach the USA, as CUNYVM and its fellow gateways provide a good service. CSNET is totally dependable (again that was once a 'black hole') and is mainly used to reach JUNET (Japan). Relaying syntax is a slight problem, but we now make most logical syntaxes work to some extent.
Incoming mail is not yet going through our mailer, except to EARN, however the new ability of the mailer to cope with long lines should allow this to be done soon. This will allow greater exploitation of lists, so I hope to test this facility more thoroughly around Christmas time.
X400 is now in tentative use. The EAN gateway has revealed itself to be fairly non-standard in its form of mail and this will need to be altered or the receiving sites will need to cope with it. It is intended to try out the NOTE400 command to see what the typical EARN user will get from it.
If the mailer could cope with the double quote character (which seems to have a special meaning for BITNET mail) then many syntaxes could be accepted (this is one way to send an escape to the system) and in particular mail to Hawaii should be possible without using IPSS for the whole route.
Following on from Application Switching being successfully installed in XL in July, the original PIXNET installation was switched off on 22 August. All users were transferred to PIXNET XL.
There were only two incidents in the period, each caused by the same fault:
15 Sept: XL crashed, dump taken. Cause: Unknown, dump given to
Paradyne. Downtime 30 mins.
19 Sept: XL crashed, dump taken. Cause: Unknown, dump given to
Paradyne. Failing card
identified from both
dumps. Replaced, all OK.
Downtime 70 mins. total.
In all other respects, the service has been uneventful.
The Lee Data Accelerator trial's full configuration at Swindon Office will be installed when Kilostream KX/GR 601104 is re-terminated in the EDPU area. This will consist of three 32-port controllers, and performance assessments will then be made.
Continuing expansion of PROFS at Swindon using Lee Data links. Finance and Accounts are likely to require JACS access. This can be provided either by PIXNET almost immediately or by Lee Data with additional hardware. My view is that F&A would prefer the Lee Data solution because of easier and quicker Application Switching. If this proves to be the case we will probably need another Kilostream circuit unless we take the more radical approach of downgrading the PIXNET to Kilostream or another high speed line and put Lee Data onto the released Megastream link multiplexed to provide two circuits.
Dear Frode,
I attach an application for associate membership from Pergamon Press.
You will note from the application that Pergamon wish to use EARN for communication with academics to aid in the publication of learned papers in their journals.
May I draw your attention to item 9 of the minutes of meeting 22 of the Executive where they agreed to recommend to the Board that publishers should be admitted to associate membership. I note that the minutes of the Board do not record that they agreed to this proposal and my memory is not good enough to recall whether the issue was raised. None the less I think that we should deal with this application sympathetically as it is in line with the use of BITNET by the Physical Review. Maybe we should also ask for ratification of the Executive recommendation by the Board.
I would like to support this application as I believe the membership of Pergamon will be of benefit to our members. I am sure you are aware of the many learned journals that the company produces.
Please contact me should you require any further information.
Yours sincerely
Paul Bryant.
Dear Dr. Bolman,
Thank you for your application to join EARN.
I have passed your application to the Membership Committee with a recommendation for acceptance. I shall contact you when I receive their decision which will take a couple of weeks as long as Christmas mail and holidays to not delay matters.
Yours sincerely
Paul Bryant.
Dear Mr. McGurrin,
Thank you for your letter asking for further details of EARN.
The reasoning behind EARN's decisions are very complex. A mixture of technical and political considerations. We are committed to following the lead of RARE (the organisation which attempts to co-ordinate international networking in Europe).
The X.25 network is based on four Northern Telcom switches in the UK, Holland, Switzerland, and France. These are to be interconnected by 64K lines in a square thus giving a measure of resilience. The other countries are connected to the switches by 9.6 or 64K lines. The idea is that the X.25 network is a backbone between national networks. We expect to have X.75 gateways between national networks and the backbone. However this will take a long time as such networks are not all that common. Thus we shall have to have other sorts of gateways which connect the current national parts of EARN to the network. In particular the Nordic countries have an extensive network based on interconnecting ethernets which will be capable of carrying X.25 .
The principle problem is to continue to support the current IBM Network Job Entry protocol. Originally we though of doing this by running SNA across the X.25 network. This was dropped as the protocol would not operate on DEC machines. This we will use the IBM NJE protocol over ISO session over transport class zero over network service.
Eventually we shall be running other ISO protocols. The only one of interest at this time is X.400 and we shall be using the products being developed by IBM and DEC. So far we have dome little work in adopting X.400 and no work on FTAM and VTP.
EARN is very pragmatic. We are moving to ISO because we have no option. We were only allowed to set up our network by the PTTs if we agreed to migrate. We also firmly believe that NJE protocols only provide a rather poor service. This is particularly so when large central machines are used for switching. We believe that with dedicated X.25 switches we will be able to offer a far more reliable service.
The NJE/OSI product is being developed by Joiners Associates for VAX computers and by IBM for IBM VM and MVS machines. The products are really 'stop gaps' as NJE does not make a very good ISO high level protocol. Unfortunately it does not exhibit the concept of a file on the driver side. This means that SVCs have to be set up on a semi permanent basis. You can easily see that with several hundred machines the number of SVCs would be enormous. Thus we still expect to stage files at the entry to each country thus keeping the number of SVCs to a reasonable number. Clearly X.400 and FTAM will have no such problems.
We are, of course, using connection protocols. We feel that with the relatively slow (64K and less) lines which are relatively error prone, X.25 provides a suitable vehicle for providing a reliable service. My view is that with reliable 2M lines the parameters will favour connection-less methods. The problem with X.25 is that it takes a large amount of computer resources and X.25 interfaces are a bit slow. TCP/IP type of networks have the opposite characteristics - they like fast reliable connections.
It is interesting that on our local area ethernet we use both connection and connection-less. It is useful to have connection so that the local area can be an extension of the wide area carrying X.25. This removes the need for awkward gateways between the two styles which I cannot see how to construct. On the other hand we also run TCP/IP mainly for use around the site as this gives an excellent service for the many UNIX workstations we have. We hope to put in 2M links into a number of sites so that remote users can also use TCP/IP (X-Windows) into our Cray computer. However on a Europe wide basis high speed lines are hard to get and very expensive and I do not expect them to be widely available at a reasonable cost for some years.
The four switches are now in place but we do not yet have the lines. Over the next few weeks we hope to test the NJE/ISO products and to provide a service about mid year.
I hope these notes answers your questions.
Yours sincerely
Paul Bryant.
The UK EARN Board Membership has now been resolved and Paul Bryant is now the member and Mike Wells the deputy.
Note - subsequent to this meeting Bob Cooper has become the deputy.
A written report was provided. The important developments are:-
IBM is setting up a super computer network. There were some hopes that this could be integrated into EARN but this has not been found possible for various technical reasons. Thus the super computer network will be a separate network but EARN hopes to have close connections with it.
Experiments with the LISTSERV mail distribution service had shown that it is possible to construct lists that span JANET and EARN. RAL had yet to make a decision on providing lists as resources are scarce.
Europe wide statistics are difficult to collect and process but figures are now being collected by Montpellier and these will be provided to the next meeting.
Spool overloading is a problem as there are limits to both the size of the spool and the number of files. Strategies for alleviating the problems have been put in place which limit files to 10,000 records. Larger files are held for transmission at week ends. Very large files overt 50,000 records are held manually and only released when conditions permit.
Yugoslavia is now connected. Algeria, Cyprus, and Tunisia await lines. Connections to Eastern Europe require further negotiation with COCOM and various governments and early connections are not expected.
The changes to the gateway made at the time of the last meeting have proved very successful as less mail is rejected for the POSTMASTER to look at.
The traffic continues to grow erratically. The use of distribution lists is causing much of the increase.
The problems with Montpellier are causing concern. A working party is actively attempting to improve the situation. Unfortunately it has not been possible to persuade Montpellier to run VM instead on MVS which would remove a few problems. It is also unfortunate that the Montpellier site is not manned 24 hours a day 7 days a week. Some thoughts have been put into finding an alternative site but this is not easy.
Members noted that delays were often long and at worst were 3 or 4 days in particular to Holland although in some cases this is due to the remote machine. Although the delays are often long some members felt that they were exaggerated and that most traffic was delivered reasonably quickly.
There were some possibilities that BITNET traffic could use the expected NSF link. It was noted that this link would have to go through gateways in the States which could not handle file transfer traffic. In addition many BITNET hosts could not drive gateways due to the absence of mailers. Thus such a move may reduce the service to the users. In the light of these problems the meeting requested that BITNET should be registered in the NRS as pointing at the EARN gateway rather than the NSF gateway.
In a discussion on lost mail members were not aware of any significant losses and that the network appeared to be reliable.
Mick Reid gave a presentation of the new statistics procedures.
Details of every transfer through the gateway are logged. The IBM SAS (Statistical Analysis System) is used to produce reports of many types. These show bar carts of traffic over weekly periods at the coarse end through lists of the major users to more detailed figures for determining which bodies should fund EARN.
The principle destinations are CERN, USA, FRANCE, Germany, Ireland, and Holland.
Unfortunately the IBM funding for user support will soon end. It was uncertain whether support could continue next year. The meeting valued the service and were anxious for it to continue. EARN management were asked to take whatever steps they could to maintain the user support.
Rutherford maintains a set of 'help' files on many topics to do with EARN and other networking topics. These are held in NETSERV. To obtain a list of the files a mail message to NETSERV@EARN-RELAY containing the text GET NETSERV FILELIST . For the latest news use GET NEWS SUMMARY .
Mail which has defeated the system is now returned to users manually if the header is understandable. This 'education exercise' has reduced failed mail. About 20 mail messages out of 7000 are rejected each day or about 0.3%.
If files are held at Montpellier the postmaster at Rutherford is informed. Thus if large files are taking a long time ask Phil Overy if it is stuck.
The paper describing the EARN transition was presented.
The hope is that current users will not be aware of the transition apart from better performance. The four X.25 switches will be installed by the end of the year. The gateways between the current EARN protocols and those over X.25 should be delivered early in the new year. A service will probably start towards the end of the first quarter.
Ian Smith expected that all users would be using the X.400 mail protocol.
Jill Foster felt that the EARN Board should have a closer liaison with BITNET in the light of their merger with CSNET.
There will be an EARN89 conference in Heraklion May29/30/31. Further details will be circulated when available.
The next UK EARN users meeting will be May 17 at UCL.
Dear Sir,
Further to negotiations between ourselves, yourselves, and the EARN network I am happy loan a modem to your Institute and also a modem to the University of Linz under the following conditions.
Yours faithfully
Paul Bryant. European Academic Research Network, UK Director.
Dear Dr. Maschtera,
Further to negotiations between ourselves, yourselves, and the EARN network I am happy loan a modem to Belgrade also a modem to the University of Linz under the following conditions.
Yours faithfully
Paul Bryant. European Academic Research Network, UK Director.
The following letter, sent to Klaus Ullmann, is a statement of EARN's requirements for MDNS submitted to RARE. I trust it reasonably reflects the needs in each country.
14 December 1988
Mr. Klaus Ullmann, RARE President, DFN, Verein, Pariserstr. 44, 1000 Berlin 15.
Dear Klaus,
The EARN Executive Committee, at its meeting in Paris on 8/9 December 1988, considered and approved the participation of EARN in the proposed MDNS Pilot Project. The EARN Executive Committee reviewed EARN's requirements for the MDNS Pilot and agreed the statement of requirements given below. This statement confirms and extends the statements already provided electronically by EARN. It should be carefully noted that EARN's participation in the MDNS pilot is not a commitment to use the MDNS Service after the Pilot Phase, since the decision to use the future MDNS Service will depend on the outcome of the Pilot, and on the detailed plans for the MDNS Service. EARN's Requirements for the MDNS Pilot Project:
1. That EARN participates fully in the planning, project
management, and evaluation of the MDNS Pilot;
2. That the MDNS Pilot service offering is complementary to,
or enhances, EARN's existing and planned services to its
users;
3. That the full cost of EARN's participation in the MDNS Pilot
is covered by project funds (including travel, manpower,
equipment, communications lines, etc.);
4. That the MDNS Pilot takes EARN's technical requirements
(e.g. addressing schemes, protocols, etc.) fully into
account;
5. That the MDNS pilot provides access to the PPSDN's for EARN
hosts and to/from the EARN X.25 backbone;
6. That X.75 access be provided between the MDNS Pilot Network
and the EARN X.25 backbone, and that the MDNS Project assist
EARN in obtaining a recognised DNIC for the EARN X.25
backbone;
7. That the quality of service measures for the MDNS be defined
and agreed with EARN as part of the MDNS Pilot, and that
service quality is rigorously measured as part of the Pilot;
8. That the MDNS Pilot Project addresses the legal and
regulatory issues already identified, and any others that
arise during the project. These include, for example,
tariffs for communication from PPSDN's to PPSDN's via the
MDNS Pilot network or the EARN X.25 backbone; access control
to ensure that traffic into the EARN network from the MDNS
Pilot network meets EARN's regulations; etc.;
9. That EARN participates fully in the MDNS Pilot Project
Steering Committee, and that this Steering Committee has
control of the project, as agreed at the RARE COA meeting on
2 December 1988;
10. That traffic from EARN countries which are not COSINE
countries be allowed on the MDNS Pilot Network.
At present our best estimate of EARN needs in the COSINE
countries is that the MDNS Pilot Network provides connections
from the national MDNS access points to the following EARN
international nodes, in the manner and with the bandwidth
indicated, and that all costs of lines and modems be met by the
MDNS pilot project;
COUNTRY CITY SITE BANDWIDTH MODE
Austria Linz University of 9.6 K X.25
Linz
Belgium Brussels Universite Libre 9.6 K X.25
Denmark Lyngby UNI-C 9.6 K X.25
Finland Espoo Finnish State 9.6 K X.25
Computing Centre
France Montpellier CNUSC 64 K X.25
Germany Bonn GMD 64 K X.25
Greece Heraklion Research Centre 9.6 K X.25
of Crete
Iceland Reykjavik University of 9.6 K X.25
Iceland
Ireland Dublin UCD 64 K X.75 or X.25
Italy Pisa CNUCE 64 K X.25
Luxem- Walferdange CEPS 9.6 K X.25
bourg
Nether- Amsterdam CWI 64 K X.75 or X.25
lands
Norway Trondheim University of 9.6 K X.25
Trondheim
Portugal Lisbon University of 9.6 K X.25
Lisbon
Spain Barcelona University of 9.6 K X.25
Barcelona
Sweden Stockholm T.B.D. 9.6 K X.25
Switzer- Geneva CERN 64 K X.75 or X.25
land
U.K. Oxford RAL 64 K X.75 or X.25
Yugoslavia T.B.D.
T.B.D. - to be determined
These specific requirements should already have been identified
by the RARE COA members, in consultation with the national EARN
Directors, when identifying the national requirements for use of
the MDNS Pilot Network.
Initial Requirements for the MDNS Service Network:
In addition to the general requirements for participation in the
MDNS Pilot Network, EARN has initial requirements for
participation in any future MDNS Service Network:
1. That the quality of service levels agreed for the MDNS Pilot
have been achieved at least three months before the start of
the MDNS Service Network;
2. That the full costs of participation in the MDNS Service
Network are identified and published at least three months
before the start of the MDNS Service network;
3. If any support to the MDNS Service Network is provided (e.g.
by the CEC, COSINE, etc.) that the complete financial model
covering levels and duration of funding be published at
least three months before the planned start of the MDNS
Service Network.
I trust that EARN's requirements for the MDNS Pilot will be fully
incorporated into the plans for the MDNS, as agreed at the COA
meeting on 2 December 1988. I regret that the EARN Executive
meeting could not have been held earlier to confirm these
requirements, but it was not possible to change the arrangements
already made.
With many thanks,
Yours sincerely,
Dennis Jennings
President
cc: Peter Tindemans
Kees Neggers
James Hutton
LISTSERV or LISTRAL provide under VM/CMS:
LISTSERV operates in the EARN mail domain and LISTRAL in the JANET mail domain. The different domain ordering demands that both LISTSERV and LISTRAL are required. Comments are applicable to both systems except where noted.
Documentation for LISTRAL is held in LISTRAL's file data base. It can be obtained in two ways:
(1) Send a message to LISTRAL of the form:
TELL LISTRAL GET FileName FileType
(2) Send a mail message to LISTRAL containing the text:
GET FileName FileType
The FileName FileType INFO FILELIST is an index to the rest of the documentation and should be retrieved first.
This document gives the minimum information for maintaining distribution lists and data bases. Staff responsible for LISTRAL should be familiar with all the documents. This document includes some information not included elsewhere.
Any mail sent to a 'distribution list' is distributed to the members of that list.
The characteristics of a list are defined in a file on the 191 disc of LISTRAL (see LISTSERV MEMO) and this is followed by the members of the list. The characteristics define who the owner is, how people join, whether a log is to be kept, and many other aspects (see LISTKEYW MEMO).
The list must be set up by the a person defined as the 'postmaster'. After being set up the 'listowner' defined in the file describing the list looks after it. Normally, users join or leave lists by sending messages or mail to LISTRAL. However, the listowner can also add or remove people from a list.
A list is set up by:
:nick. :group.cp :command.transfer change :user.listserv listralthis allows LISTSERV or LISTRAL to transfer files from ListName to themselves for distribution.
PUT ListName LIST NODIST PW=Password * Distribution list for SERC * The above is the name of the list * Entries start with a keyword and if not recognised are taken as * comments. These three lines are comment. See LISTKEYM MEMO. * The Password is the list creation password known only to the list * administrator or after creation the list password. See LISTSERV MEMO * Review= public * anyone can look at this list to find who is on it. * Subscription= Open * anyone can join this list. * Send= Private * only members of the list can send to the list. * Notify= Yes * the list owner will be told of new members. * Reply-to= Respect * set the Reply-to: field to any supplied by the sender * Confidential: No * anyone can know about the existence of the list * Validate: Store only * a password is only needed to re-send the list to LISTRAL * X-tags= Yes * see documentation * Stats= Normal * defines the level of statistics maintained by LISTRAL for the list * Ack= Yes * a sender does not normally get a copy of the mail but gets an * acknowledgement. * Notebook= No * a notebook for the distribution list is not maintained. * Owner= MailName@MailAddress * the owner can manipulate the list and control usage. * Editor= MailName@MailAddress * if Send= Editor all mail is sent to the editor. Only the editor can * send to the list. * Errors-To= MailName@MailAddress * if there are failures they go to this mail address * Sender= MailName@MailAddress * this should be the postmaster- if left out there may be mail loops * as failing mail may go to the list. * PW= PassWord * The password is needed to allow the list to be manipulated * This may optionally be followed by a list of list members in the form:
MailName@MailAddress Fred Bloggs
This file is sent to LISTRAL with a SENDFILE to create the list or subsequently by the list owner subsequent to creation
The above file will need to be adapted for the particular list and will normally have fewer comments.
- The list is now ready.
Lists which are composed of predominantly EARN members are set up in LISTSERV and those predominantly in JANET in LISTRAL.
Mail addresses in JANET are different to those in EARN.
In JANET addresses have the form FRED@UK.AC.RL.IB. Thus in LISTRAL all the addresses are in JANET form.
In EARN addresses have the form FRED@IB.RL.AC.UK. Thus in LISTSERV all the addresses are in EARN form.
This presents problems with lists spanning EARN and JANET which are in LISTSERV.
The difficulty is to force mail coming from JANET for an EARN list to traverse the EARN gateway which reverses addresses. The list is set up in the same way but entries are made in the table of MAILER and EARNGATE as specified below.
To set up a list in LISTSERV, ListName say, with members in JANET:
- Log into EARNGATE. EARNGATE will normally be autologged and on reconnecting the command STOP will halt it. - Edit the file MAILER MTPLATE. Locate the section headed: SPECIAL: and add the line: ListName DISTLIST 1 ListName - Create the file ListName DISTLIST containing the single line: ListName@EARN.UKACRL - Logout of EARNGATE, the system will automatically re-ipl EARNGATE. - Log into MAILER. MAILER will normally be autologged and on re-connecting the command STOP will halt it. - Edit the file MAILER MTPLATE. Locate the section headed: INCOMING: and add the line: UKACRL ListName - Logout of MAILER, the system will automatically re-ipl MAILER.
Normally the sender of mail to a list does not receive a copy of the distributed mail. The command SET ListName REPRO will cause a copy of mail to be send to the originator.
The Sender: field is normally set to the address of the distribution list. This is dangerous as several mail implementations return rejected mail to the Sender: and this causes mail loops. The undocumented solution is to include the line:
* Sender= name@address
This will overwrite the default. The name and address should normally be the supervisor of LISTRAL so that a check can be kept on bad addresses that can then be removed.
- Create a file with the single line: PUT ListName LIST NODIST PW=Password This file is sent to LISTRAL with SENDFILE. - Remove the user ListName. - Remove any entries in MAILER and EARNGATE.
LISTSERV and LISTRAL contain a database of files. These form a hierarchical filestore. Files are retrieved by sending a mail message to LISTRAL containing lines of the form:
GET FileName FileType Directory Directory is optional. Directories have the FileType FILELIST.
To modify a directory:
- Issue the command: TELL LISTRAL GET FileType FILELIST PW=Password (CTL
This will 'lock' the directory to prevent it being changed. The directory will appear on the reader and can be 'received'.
- Edit the directory:
The head of the file contains control information about who is allowed to access and update files. The remainder of the file contains a list of directories and/or files. A directory entry has the form:
/F/ DirName FILELIST rdr wrt A file entry has the form: FileName FileType rdr wrt
This will be followed by other information when created. rdr is a three letter code which defined who can 'GET' a directory or file from LISTRAL. wrt is a three letter code which defines who can 'PUT' a directory of file. If rdr is ALL anyone can 'GET' the file.
A directory contains a header with comments and control information where each line starts with *. The control information starts with *+. The control information defines who can retrieve or update files and passwords. For example:
*+ PEB= PEB@UK.AC.RL.IB * This defines PEB when used as an rdr or wtr *+ PEB= PW= Secret * Defines a password needed by PEB
The edited directory must have the line
PUT FileName FILELIST PW=Password
as the first record where the Password is the password of the owner. The file is then sent to LISTRAL using SENDFILE.
- issue the command SENDFILE FileName FILELIST TO LISTRAL
LISTRAL will return an acknowledgement as a mail file and the directory will be unlocked.
A directory or file may be deleted by sending a file to LISTRAL with no data apart from the PUT command.
A file may be put in a directory by a similar process, that is, by prefacing it with
PUT FileName FileType Directory PW=Password and using SENDFILE to send it to LISTRAL.