🚀 go-pugleaf

Als kleinen Blick ueber die Grenze dachte ich, koennte das folgende
interessant sein:

> janet-ip-request@computer-science.strathclyde.ac.UK:
Original-Via:   UK.AC.RUTHERFORD.INFORMATICS ;  Mon, 21 Oct 91 20:57 BST
        (V39 at UK.AC.RUTHERFORD.GEC-B)

A launch date for the JANET IP Service of *1 November 1991* has now been
fixed, and announced to Computing Services Directors with an invitation
to apply for connection from this date. From 1 November the Shoestring
pilot will officially cease, and the running of IP over JANET will
become a full service. (For those using the pilot this should be a
seamless transition!).

The attached document is an overview of the service provided, with
details of what's required to connect. It is being sent to Directors
along with the letter of announcement/invitation, and may be of
interest to subscribers of this list as well. Note, however, that
applications to connect can be accepted ONLY from central Computing
Services organisations, and not from individual departments etc. Please
talk to your Computing Services people to find out what the intentions
are regarding connection, as this is an option to be taken up at their
discretion, not the JNT's!.

Bob Day

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






Overview of the JANET IP Service  and  of  Requirements  for
Connection

R A Day

Joint Network Team                           16 October 1991
____________________________________________________________


This document provides a summary of the services provided by
the  JANET  IP Service (JIPS), and of the requirements on an
institution wishing to connect.

Much of the advice contained in this document has come  from
work  carried  out in the ``Shoestring'' project - the tech-
nology pilot for the JIPS.  Thanks are due to the individual
members  of  this  project  for  the  effort,  expertise and
enthusiasm they have contributed, and to participating  Com-
puting Service organisations for making available the effort
to mount the pilot.

1.  Overview of the Service

1.1.  General

The service provided is a carrier service for  IP  over  the
existing  X.25  network offered by JANET.  This carrier ser-
vice is managed to provide the necessary routing and manage-
ment  to  ensure  that  best  use  is made of the underlying
bandwidth.  The carrier network is connected to other inter-
national IP networks (the global ``Internet'') in two ways:

 -   to the US via the transatlantic fatpipe;

 -   to (most) European IP networks via  the  RIPE  backbone
     router located in Amsterdam.

The JIPS provides the necessary infrastructure  and  manage-
ment  to  enable  access to international networks via these
two links.  (Access to networks other than in the US and the
European  RIPE  community is also provided - in general this
is achieved by routing through  the  US).   The  details  of
international  connectivity  will be transparent to the user
of the JIPS (apart from the fact that performance will inev-
itably not be as good as within JANET) - the connectivity is
achieved at the network level so applications will run  end-
to-end rather than through relays.

The JIPS also provides connectivity to UKNET, the  other  UK
IP  network  currently  offering  a  general service.  It is
expected that connectivity will be available to  other  such
networks in the UK, should they come into existence.

The design of the JIPS has been carried  out  explicitly  to



                          -- 1 --








make the costs of connecting, both in terms of equipment and
of manpower, as low as possible.  To this end there has been
set  up  a ``backbone'' of routers, with one located at each
of the JANET Network Operations Centres (NOCs).  This  back-
bone  relieves  connecting  institutions of the need to pur-
chase complex routing equipment, and of the need  to  devote
effort to managing routing between the institution and other
connected institutions.  Similarly, the aim has been to pro-
vide  connecting institutions with detailed technical advice
on  the  other  aspects  of  connection.   This  advice   is
presented  in a JIPS Technical Guide, which is freely avail-
able (see Section 5).

Connection to the JIPS is possible only on an  institutional
basis, and via an institution's Computing Services organisa-
tion.  Specifically, it is not possible to  connect  indivi-
dual  Departments  of an institution to the JIPS as separate
entities.

Management of the service is carried  out  on  a  day-to-day
basis  by  the  JIPS  Network  Operations and Service Centre
(NOSC) located at the ULCC NOC.  This has responsibility for

 -   arrangement of initial connections of  institutions  to
     the JIPS;

 -   management of the national  backbone  of  routers  that
     underpins the carrier service;

 -   management of the international  connectivity  provided
     by the JIPS;

 -   overall management of the part of the Domain Name  Sys-
     tem namespace belonging to the UK academic community;

 -   problem diagnosis and solution (in conjunction with the
     NOCs, which provide the interface to individual Comput-
     ing Services organisations);

 -   providing the JNT with statistics and other performance
     data on the operation of the service.

The overall responsibility for the service and its  develop-
ment rests with the JNT, to which the JIPS NOSC reports.

1.2.  Application Services Supported

The set of services supported by the  JIPS  is  as  follows.
(Note:  ``support'' is defined to mean that the JIPS manage-
ment will ensure that these continue to run efficiently over
the  JIPS  -  it does not mean that support will be given to
individual institutions or their users on the  configuration
and  use of the services.  These latter tasks are considered
to be the responsibility  of  each  institution's  Computing



                          -- 2 --








Services organisation.)

ARPA-FTP

     This provides file transfer facilities to and from  end
     systems  on  the  Internet.   It has the advantage over
     Blue Book FTP of giving direct connectivity to Internet
     end  systems,  rather  than  access  via a relay.  This
     means that it  provides  easy  access  to  archives  of
     software  and documentation, particularly via so-called
     ``anonymous ftp'' - the usual access  method  to  these
     facilities.  ARPA-FTP also permits interactive browsing
     of the directory structure of the remote system  as  an
     aid  to  locating  the  file(s) wanted.  Similarly, the
     mode of use of ARPA-FTP for file transfer  is  normally
     interactive  rather  than  spooled.  Some, but not all,
     users cite this as an advantage.  (This is  in  fact  a
     property  of the user interface to ARPA-FTP implementa-
     tions, not of the protocol  itself.   The  majority  of
     implementations  of  ARPA-FTP  provide  an  interactive
     style of use, whereas the majority  of  implementations
     of Blue Book FTP offer a spooled style of use.)

TELNET

     This provides terminal login  facilities  to  and  from
     systems  on  the  Internet.  Its advantage over X.29 is
     that it gives direct connectivity to Internet end  sys-
     tems,  rather  than  access  via  a relay.  (The latter
     currently requires staging ie  an  X.29  login  to  the
     relay system, and then an onward TELNET call.)  Besides
     ease of use, the advantage of using TELNET  is  one  of
     transparency.   Sometimes  there  are niggling problems
     with terminal parameters incorrectly set when  a  relay
     is in use - these are absent for a direct connection.

     Also available is 3270-mode TELNET, for use  in  logins
     to  IBM  mainframes (and compatibles) where full-screen
     access is used.  However, it should be noted that  this
     variant  of  TELNET is not centrally supported over the
     JIPS - it may be used, but formal reliance on this as a
     service is at the institution's own risk.  (In practice
     this risk is small, as 3270-mode TELNET is  well  esta-
     blished,  and  differs  very  little in traffic pattern
     from line-mode TELNET.)

X-Windows

     This provides a distributed windowing system  over  the
     Internet  ie  it  allows a user on a workstation with a
     windowing user interface to open windows  on  processes
     on  other  systems.   He  or she may then interact with
     these using the full range of  windowing  facilities  -
     graphics as well as text, and use of a mouse as well as



                          -- 3 --








     a keyboard.

     X-Windows is a new service, with no equivalent  in  the
     Coloured  Books  suite.  Therefore it is likely that it
     will see significant use between sites connected to the
     JIPS, and not just for international connectivity.  (In
     fact, due to the bandwidth requirements for interactive
     graphical  use of X-Windows, it may be that most of the
     use is initially  confined  to  JANET.   The  bandwidth
     available  over JANET is considerably greater than that
     available over international links.)

All other services available over IP may be  used  (but  are
not  centrally  supported) except for those given in Section
1.3 below.

1.3.  Unacceptable Services and Protocols

The use of the services and/or protocols  in  the  following
list is regarded as unacceptable over the JIPS:

        SMTP;
        NFS;
        Use of IP to carry OSI application protocols;
        Use of mixed lower layers (eg DECNET over IP).

The use of these services has been strongly  discouraged  by
the  ISC,  on the grounds either of potential for fragmenta-
tion of existing services based upon Coloured Books, of rea-
sons  of performance, or of potential to impede the progress
towards the transition of JANET to OSI.

Note:The JNT's IP advisory group - the DoDAG - has just com-
     pleted  a  technical  review  of  this policy, based on
     experience gained in the Shoestring pilot.  The JNT  is
     considering  the advice given, and expects to offer the
     ISC, through its Network Advisory Committee,  later  in
     1991  further  advice  on the soundness or otherwise of
     the categorisation of services given  in  Sections  1.2
     and 1.3.

2.  Alternatives to the Use of the JIPS

If an institution's Computing Services elects not to connect
to the JIPS it will still be able to interwork with end sys-
tems connected to the Internet and which offer either  ARPA-
FTP or TELNET.

In the case of ARPA-FTP, the relay UK.AC.FT-RELAY will  con-
tinue  to be available.  Currently this gives the ability to
initiate file transfers to and from  Internet  end  systems,
from  an  end  system  on JANET using Blue Book FTP.  (It is
planned also to provide the ability for  users  on  Internet
end  systems to initiate transfers to and from Blue Book end



                          -- 4 --








systems on JANET.)  This  includes  the  ability  to  access
archives  using  ``anonymous ftp'', but the functionality of
interactive browsing of remote directories is lost.  (Direc-
tory listings can be requested as a file transfer, however).
Similarly, the mode of use for file transfer will be spooled
rather than interactive in the cases where the Blue Book FTP
implementation itself provides this mode of use.

In the case of TELNET, the guest TELNET service  running  on
UK.AC.NSFNET-RELAY.TELNET  may  be  used.   This  provides a
staged login facility ie an X.29 call may  be  made  to  the
service, followed by an onward TELNET call to the end system
on the Internet.  This service is also available to users of
Internet  end  systems - they may login to the service using
TELNET and make an onward X.29 call  to  an  end  system  on
JANET.   The use of 3270-mode TELNET is not possible through
this service.

Of course, electronic mail to and  from  the  Internet  will
continue  to  be  available via the mail relay UK.AC.NSFNET-
RELAY as before.

There is no current alternative to the use of X-Windows over
TCP/IP.   X-Windows will not become available as part of the
Coloured Books suite.  A mapping of X-Windows  over  an  OSI
stack has now been defined at a European level, and develop-
ment work is under way on implementations  for  VAX/VMS  and
for  Unix.   This  is  planned  to  include a relay function
between OSI and TCP/IP networks.  However, service provision
based  on  such  implementations is realistically still some
way off.

3.  Overview of Requirements on an Institution Connecting to
the JIPS

Broadly, there are five requirements on an institution  con-
necting  to the JIPS.  These are dealt with in detail in the
JIPS Technical Guide - each is outlined here to give an idea
of what will be involved.

3.1.  Registration of IP Networks

All IP networks connected to the JIPS must have ``legal'' IP
numbers  assigned ie numbers that have been allocated by the
Internet authorities, rather than merely  invented  locally.
Many institutions will already have registered existing net-
works in this way, even though connection  to  the  Internet
has hitherto not been possible.

This registration cannot be carried out by the JIPS  manage-
ment on behalf of the institution - the registration must be
made direct.  It is done via a form which is requested, sent
and  returned  using  electronic  mail.   The JIPS Technical
Guide gives details.



                          -- 5 --








There are a number of other registrations  needed  for  suc-
cessful  access to the Internet - these can and will be made
by the JIPS management as part of the JIPS  connection  pro-
cedure.

3.2.  Purchase of Routing Equipment

The method of connection to the JIPS is  via  an  IP  router
connected  to  the  institution's CPSE.  This router must be
purchased by the institution, normally from its  own  funds.
(The  exception  to  this is that, where a router for use on
the institution's LAN has been approved  for  purchase  with
Network  Installation funding, the incremental cost of using
this router for connection to the JIPS as well may  also  be
funded  from  the same source.  However, a router may not be
purchased with Network Installation funding only for use  to
connect to the JIPS.)

The technical requirements on the router used are  straight-
forward  in terms of functionality, as the hard work is done
by the routers  on  the  JIPS  backbone.   In  practice  the
institution's  router  does  not  make any routing decisions
itself - it needs only to forward  packets  to  a  nominated
router on the backbone.

The Shoestring pilot has identified a short list of suitable
routing  equipment,  based  upon practical experience.  This
list is not exhaustive - it is merely an indication of which
equipment  is known to work, and which is likely to continue
to be suitable for the foreseeable future.  It  is  as  fol-
lows.

Cisco Routers (Any Model)

     These routers have performed well in the pilot, and can
     be  recommended  where  a  fully  functional  router is
     required.  The functionality includes management facil-
     ities  (such  as  statistics  gathering, access control
     etc), as well as the capability to run  routing  proto-
     cols.   (This  latter facility may be needed to conduct
     internal routing on institution  LANs  where  there  is
     more  than one IP network, connected via router(s).  In
     such cases the router will need to be able to operate a
     routing  protocol with the other router(s), in order to
     route IP traffic correctly from the JIPS to these  net-
     works.   There  is  no requirement for routing protocol
     exchange with the JIPS backbone, and in fact the  back-
     bone  routers  will ignore any routing information sup-
     plied by institution routers.)

     The precise model of cisco router required will  depend
     on  the  performance and expandability requirements (as
     well as on budget!).  They are all capable of driving a
     wide  range  of  linespeeds, nominally up to the full 2



                          -- 6 --








     Mbps of JANET.  Full details should  be  obtained  from
     one of the distributors.

     Note:At the time of writing - October 1991 - there is a
          known  problem  in  driving  cisco  routers for IP
          routing over  X.25  at  2  Mbps.   This  manifests
          itself  as  an  excessive  number  of aborted X.25
          frames, and a consequent  degradation  in  perfor-
          mance.  The JNT is satisfied that the manufacturer
          is expending all efforts to fix this problem.   In
          the meantime it is recommended that:

          (a)  in any purchase it is made clear  in  writing
               that the equipment must eventually perform IP
               routing over X.25 satisfactorily at  2  Mbps,
               and   that   any   hardware  and/or  software
               upgrades necessary to achieve this  are  sup-
               plied free of charge;

          (b)  in the interim the router is connected to the
               CPSE at a maximum linespeed of 1 Mbps.

          (The JNT's  current  recommended  distributor  for
          cisco  routers - Chernikeeff Systems - has given a
          guarantee that any hardware or  software  upgrades
          necessary to overcome the problem will be supplied
          free of charge  to  existing  systems  on  mainte-
          nance.)

          Connection  to  the  CPSE  at  1  Mbps  will   not
          currently present a performance bottleneck, as the
          JIPS backbone is also being run at 1  Mbps.   This
          is  being  done  as a matter of policy, to control
          the use of bandwidth by the JIPS, rather than  for
          router performance reasons.

Netcomm ECB

     This is a board that fits into a suitable Netcomm  X.25
     switch,   and   provides  IP  forwarding  (as  well  as
     CONS/CONS relaying).  It  is  not  a  fully  functional
     router, having no support for routing protocols, but is
     capable of high performance.  It should be adequate  in
     cases  where the institution's LAN consists of only one
     IP network (and of course  where  there  is  a  Netcomm
     switch  in  use).   There  are  ways of coping with the
     routing problems posed by more complex LANs  consisting
     of  more  than one IP network (this requires the use of
     ``proxy ARP'' which is now supported in the Netcomm ECB
     software), but it may be decided that a more functional
     router is required in such cases.   Management  facili-
     ties  are very limited, apart from configuration of the
     board.  However, these observations as to  the  limita-
     tions   of  the  ECB  should  not  be  taken  to  imply



                          -- 7 --








     inadequacy - within the Shoestring pilot  it  has  been
     found to perform well within its intended limits.

     It was noted by the Shoestring pilot that the  software
     for  the  ECB is relatively immature, with frequent new
     releases being made by Netcomm.   The  latest  releases
     appear  to  give  reliable  operation, and it is recom-
     mended that institutions using the ECB ensure that they
     keep up to date with Netcomm's releases.

Sun Workstation or Server

     A Sun system can be configured as a router for  connec-
     tion  to  the JIPS by use of the Sunlink X.25 software.
     By itself this gives a relatively low-performance solu-
     tion (suitable for connection at up to 64 Kbps, depend-
     ing very much on the model  of  workstation  or  server
     used).   However,  hardware  support  is  available  to
     increase performance - notably  the  recently-announced
     S-Bus HSI interface, or its VME-Bus version (for older,
     larger systems).  These boards give performance  beyond
     the 2 Mbps provided by JANET.  The Sun Operating System
     software includes support for  routing  protocols  (via
     the  routed daemon), but management facilities are lim-
     ited.

     Where a Sun workstation or server already  exists  this
     may be an attractive solution.  The Sunlink software is
     a relatively cheap item, and may well give a  satisfac-
     tory solution in terms of bandwidth, without additional
     hardware support, where the institution's link to JANET
     is of 64 Kbps or lower.  The S-Bus HSI hardware in par-
     ticular is also a relatively cheap  item,  should  such
     support be required.

Whatever choice of  routing  equipment  is  made,  the  JIPS
management  will provide the institution at the time of con-
nection to the JIPS with access to a nominated router on the
JIPS  backbone.   An  ``IP  tunnel''  will  then  be created
between the institution's router and this  backbone  router,
and  all  traffic  between the institution and the JIPS will
pass through this tunnel.  It is a requirement of connection
to  the  JIPS  that  no  attempt  is  made  to set up other,
independent ``IP tunnels''  across  JANET,  unless  explicit
prior permission to do so is given by the JIPS management.

Further detail on the subject of routing can be found in the
JIPS  Technical  Guide, and in the Shoestring pilot's router
evaluation document - see Section 5.

3.3.  The Domain Name Service

The Domain Name Service (DNS) is the name-to-address  trans-
lation  service  integral  to  the  IP world.  It is roughly



                          -- 8 --








analogous in function to  the  NRS  in  the  Coloured  Books
world.  It provides a hierarchical namespace similar to that
of the NRS, with the notable difference that  name  ordering
is reversed (ie names are formed in the DNS in little-endian
order, whereas in the NRS  they  are  formed  in  big-endian
order.)   In recognition of the fact that with the advent of
the JIPS there will be two naming  systems  in  use  in  the
academic  community,  a  mapping  between  names  of systems
registered both in the NRS and the DNS has been devised.  In
normal circumstances this mapping will allow users to deduce
the name of a system in one namespace from  a  knowledge  of
its  name  in  the other - it will usually involve reversing
the ordering of the name he  or  she  already  knows.   (For
example,   the   NRS   name  UK.AC.CAMFORD.IBM  will  become
ibm.camford.ac.uk in the DNS.)

Unlike the NRS, the DNS is a fully  distributed  system,  in
that it distributes the responsibility for the mastering and
storage of the data it contains.  Each institution connected
to  the JIPS will have delegated authority for naming within
its own part  of  the  namespace.   This  implies  delegated
responsibility  for storing all names allocated, and this is
done by running a number of nameservers within the  institu-
tion.

It is therefore a requirement that an  institution  runs  at
least  two  DNS nameservers - a primary nameserver, which is
the master for the institution's namespace, and at least one
secondary  nameserver,  each of which act as backups for the
primary  nameserver  and  thus  increase  reliability.   The
software  for  doing this is bundled into most Unix systems,
and is also available in the public domain.   It  is  recom-
mended  (but not mandated) that the platform used to run the
institution's nameservers is Unix.

To use the DNS, end systems connected to the  JIPS  must  be
configured  with a DNS resolver.  This is able to access the
DNS to perform lookups on behalf  of  applications,  and  is
transparent  to the user.  It is usually part of the Operat-
ing System or basic run-time libraries, and its  commission-
ing is normally only a matter of configuration.

Besides running the  DNS  nameservers,  the  institution  is
required  to  maintain its own namespace correctly.  This is
essential to ensure that, as a minimum, electronic mail from
the Internet (delivered via UK.AC.NSFNET-RELAY) continues to
be received correctly.  It will also  be  necessary  to  co-
ordinate  NRS and DNS registrations of systems, particularly
when they are used for mail.  It is probably  most  sensible
if the NRS Technical Administrator and the DNS administrator
are the same person.

Because delegation of authority for its DNS namespace to  an
institution    implies    a   considerable   responsibility,



                          -- 9 --








institutions will be allowed to connect  to  the  JIPS  ini-
tially  without  this  delegation, and to receive it a short
time later when they are confident that their administrative
mechanisms  are  in  place  to  take  on the responsibility.
There will be a considerable impetus to do this, as full use
of  the  JIPS  connection  will  only be possible when it is
done.

The subject of the DNS is  complex,  and  considerably  more
detail is given in the JIPS Technical Guide.

3.4.  Security Considerations

When an institution connects to the JIPS,  and  then  allows
end systems on its LAN access to the service, there is obvi-
ously an extremely large community of users who  potentially
have access to these end systems.  (Note that this access is
not automatically possible simply as a result of the  insti-
tution connecting - it will normally be necessary to config-
ure each end system's TCP/IP software to ``know'' about  the
connection.)   Thus the issue of unauthorised access becomes
important.  Although unauthorised access from  the  Internet
has  always been a concern (as the existing relays described
in Section 2 provide  interworking),  the  ease  with  which
access  is  provided  via  the JIPS naturally increases this
concern.

The Shoestring pilot has considered  the  security  implica-
tions  of connection to the JIPS, and produced some detailed
advice, pertaining mainly to Unix systems.  As part of  this
advice  it  has produced a strong recommendation that effec-
tive security can only be implemented via  security  on  the
end  systems  accessible  from  the JIPS.  Security measures
applied at the point of connection (eg in  the  router  that
makes  the  JIPS  connection)  are  considered to be at best
short-term palliatives.

It is therefore recommended that institutions  give  thought
to  this  topic  before  connecting  to  the JIPS.  Detailed
advice is given in the JIPS Technical Guide.  The Shoestring
pilot  also  recommends  a  practical guide to Unix security
published by SRI International - see Section 5.

3.5.  Contacts at the Institution

Connection to the JIPS requires that the institution's  Com-
puter Services provides two contact points:

 -   an administrative contact for matters  of  policy,  its
     implementation, and similar issues;

 -   a technical contact for  all  matters  of  a  technical
     nature  -  initial connection, liaison over fault diag-
     nosis etc.



                          -- 10 --








These names will be entered in the international database of
contact  points  maintained  by the Internet authorities, as
well as  being  used  by  the  JIPS  management.   Therefore
resource must be made available to ensure that the nominated
persons can fulfil their roles in a timely manner.  In  par-
ticular,  technical  support  for  users  of the JIPS at the
institution will be expected  by  the  JNT  to  be  provided
through  the  technical  contact (ie his or her name will be
given should a user approach the JNT directly).  He  or  she
will  also be expected to respond to technical requests from
the JIPS management, and possibly from his or her  peers  on
the Internet.  (This latter might happen if an administrator
of a network other than those connected to the JIPS finds an
operational  difficulty  and  traces it to the institution's
network.  Such contacts may not always be  filtered  through
the JIPS NOSC, as administrators of other networks will have
direct access to the contact information through the  inter-
national database of contacts.)

4.  Acceptable Use of the JIPS

Acceptable use of the JIPS is  considered  to  comprise  the
following:

(1)  respect for the ISC's strong discouragement of the  use
     of  the  services  and or protocols currently listed in
     Section 1.3 as not in the  interest  of  the  community
     (and  of  any  others  that  it subsequently decides to
     categorise in this manner);

(2)  operation of the router providing the connection to the
     JIPS  in  the manner outlined in Section 3.2, with par-
     ticular respect to  the  use  of  ``IP  tunnels''  (and
     according  to  any  other operational requirements that
     may be made by the JIPS management);

(3)  provision and proper running of a DNS  service  in  the
     manner outlined in Section 3.3;

(4)  provision of suitable administrative and technical con-
     tacts, each of whom shall respond in a timely manner to
     reasonable requests for their assistance,  made  either
     by  the JIPS management or by their peers on the Inter-
     net.

Furthermore, the use of the JIPS must always  remain  within
the  general Acceptable Use guidelines for JANET.  (The next
edition of these  guidelines  will  have  the  JIPS-specific
guidelines above incorporated.)

5.  Further Information

Further information on the technical aspects  of  connection
to  the  JIPS,  and  on  the  subsequent  operation  of  the



                          -- 11 --








connection may be found in the JIPS Technical Guide,  avail-
able  from  the JNT.  This will be provided automatically to
all applicants for connection, but may also be  obtained  in
advance  of  applying  for  connection  if  wished  (from  1
November 1991).  To obtain a copy contact the JANET  Liaison
Desk:

        E-mail:   janet-liaison-desk@UK.AC.JNT

The  document  giving  details  of  the  Shoestring  pilot's
evaluation  of  routers  for  connection to the JIPS is also
available from the JANET Liaison Desk, as are copies of  SRI
International's  document on security Improving the Security
of your Unix System.

Technical queries  on  connection  to  the  JIPS  should  be
addressed to the JIPS NOSC:

        E-mail:   jips-nosc@UK.AC.ULCC.NOC

Please note, however, that it is expected that such  queries
from individual users within an institution will normally be
filtered through its Computing Services organisation.   This
is  necessary  both to ensure that the Computing Services is
aware of potential issues, and to keep the load on the  NOSC
at a reasonable level.

Any questions relating to the JIPS  Technical  Guide  and/or
aspects  of  the JIPS not covered above, should be addressed
to Dr Bob Day, the manager of the service:

        E-mail:   R.Day@UK.AC.JNT

























                          -- 12 --