RIPE 16 minutes - DRAFT


Dear All,

Below is the .txt version of the draft minutes from the 16th RIPE meeting.
Both PostScript and the ASCII can be retrieved from the RIPE document store
in directory:

	ftp:ftp.ripe.net:ripe/docs/ripe-minutes/ripe-m-16.{ps,txt}

*Many thanks* to all those who sent me text.  As usual comments are invited.

Regards,
Anne

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



DRAFT  DRAFT  DRAFT  DRAFT  DRAFT  DRAFT  DRAFT  DRAFT




                                                        ripe-m-16
                     16th RIPE meeting


                         Minutes


                        Anne Lord


               Amsterdam, The Netherlands
                 September 15-17th, 1993
                                  - 2 -


AGENDA

1.  Opening

2.  Minutes of the last meeting and review of action list

3.  RIPE NCC Report

4.  Joint Projects progress

5.  RIPE NCC Review

6.  RIPE NCC Activity Plan

7.  RIPE and RARE

8.  Network Resource Discovery

9.  How do we ensure a good working European Internet in 1995?

10. Update on the new JIPS services

11. Update on EMPB services

12. Update on EBONE

13. Update on EUnet

14. Update on SPRINT infrastructure support

15. RIPE European Internet Architecture WG

16. Introduction of DANTE

17. Update on networking with Russia

18. Reports from the parallel sessions

19. Next RIPE meetings

20. AOB

21. Closing


APPENDICES

Appendix 1: List of Participants
Appendix 2: Open Action Items
                                  - 3 -


1. Opening

Apologies were received from the following persons  who  were  unable  to
attend the meeting:


 o Jan Guntograd - Technical University, CZ
 o Roland Acra - CISCO
 o Stephan Biesbroeck - Leuven, BG
 o Bob Collet - SPRINT
 o Ljubomir Stefanov - Bulgarian Academy of Science
 o Radoslav Dakov - Bulgarian Academy of Science
 o Oliver Korfmacher - NetCS
 o Clemens Schrimpe - NetCS


1.1.  Welcome


Rob Blokzijl welcomed the participants to the 16th RIPE meeting hosted by
NIKHEF and held at WCW, Amsterdam

1.2.  Approval of the agenda

The agenda was approved.

1.3.  Papers tabled:


Papers:
  - Agenda for the 16th RIPE meeting
  - Working Group Agendas - one document
  - Map of International IP connectivity in Central & Eastern Europe
  - RIPE Connectivity Report - draft
  - RIPE NCC Review - draft paper
  - Decisions of the RARE/RIPE Coordination Meeting (CoA (93)052)
  - Current version of DNS advice txt - P. Beertema

Presentation notes:
  - DANTE Mission Statement
  - GARR on-line Network Resource Guide

Publications:
  - EUnet Infrastructure Map
  - ACOnet 5th Network Seminar - Notice
  - EARN Resource Discovery Pamphlets


2. Minutes of the last meeting.

2.1.  Approval of the minutes

The minutes from the 15th RIPE meeting were approved.  The  action  items
from  the  15th  RIPE  meeting minutes were reviewed.  The following list
                                  - 4 -


comprises the ongoing action items only.  All  other  action  items  were
closed.

Action: 15.4 Bob Day/NCC To fold in the comments of the working group  on
the  ripe-draft-hints-v1.txt,  circulate  the document to the wg list and
publish as a ripe document.  It was confirmed that Bob Day was  extremely
busy  and that the action should be taken off him.  NCC to take up action
and find replacement.

Action: 15.7 Marten Terpstra  Fold  in  comments  and  republish  amended
ripe-72.

Action: 15.10  Daniel  Karrenberg  To  propose  new  tags  "created"  and
"assigned" to the database working group for consideration.

Action: 15.17 Glenn Kowack and Tony Bates Write a top level  introduction
for the user as an add-on to the GISS paper once it has been written.

Action: 15.19 Peter Lothberg To draft document on Inter-AS local informa-
tion.

Action: 15.21 Daniel Karrenberg To draft document on colouring.

3. RIPE NCC Report (Daniel Karrenberg)

The RIPE NCC Report was given by Daniel Karrenberg and included a presen-
tation  by  Marten  Terpstra  on the new RIPE Network Management Database
software.  Copies of both presentations can be found in the RIPE document
store in the presentations directory, files:


o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-dfk-NCC-REPORT.ps.Z
o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-marten-DBPLEN.ps.Z


4. Joint Projects Progress (Tony Bates)

Tony Bates reported on the status of the three Joint  RARE/RIPE  projects
carried  out  at the NCC.  Copies of these presentations can be retrieved
via ftp from:


o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-tony-GISSREP.ps.Z
o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-tony-RSREP.ps.Z
o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-tony-PRIDE.ps.Z


5. RIPE NCC Review Board (Rob Blokzijl)


Rob extended thanks to all those who provided input to  this  activity  -
especially  Wilfried  Woeber and Milan Sterba.  A draft document has been
produced summarising the outcome of the review.  This document was circu-
lated  as a tabled paper at the meeting and can also be found in the RIPE
                                  - 5 -


document store in the following directory in file:


o ftp:ftp.ripe.net:ripe/docs/ripe-drafts/ripe-draft-ncc-review.txt

The above draft was would be  discussed  further  at  this  meeting  (see
below) in two BOF sessions.


6. RIPE NCC Activity Plan (Rob Blokzijl)


One outcome of the NCC Review process will be a new Activity Plan for the
RIPE  NCC.   Further refinement of the draft RIPE NCC Review document and
further input to the new RIPE NCC activity plan was identified as immedi-
ately  necessary.   This RIPE meeting would be the forum to discuss these
agenda points further.  The outcome of  these  discussions  are  reported
under item 18 of the agenda "Reports from the Working Groups/BOF's".


7. RIPE & RARE (Rob Blokzijl)


Rob Blokzijl reported on a coordination  meeting  that  had  taken  place
between  Kees  Neggers (RARE President), Tomaz Kalin (RARE Secretary Gen-
eral) and himself.  A write up of that meeting, produced  by  Kalin,  was
distributed at the meeting.

The main conclusions of the meeting  were  that  the  following  mode  of
operations and coordination is still valid:


o RIPE and RARE are independent organisations.

o RARE has a technical program, but will not include IP coordination in
this program: it will rely on RIPE for all IP related matters.

o RIPE will not set up a technical program of its own, it will use the
mechanism of the RARE technical program for executing projects.

o To ensure close cooperation on the technical level, RIPE appoints a
representative on the RARE technical committee.

It was concluded that the Route-Server and GISD project was a good  exam-
ple  that this set of agreements is able to get good progress in organis-
ing new projects.

On a related subject, Rob Blokzijl mentioned that the RIPE NCC  is  still
mainly  funded  by  RARE member organisations.  An organised drive to get
funding contributions from non RARE member organisations is on  the  way;
results are coming in, but more is still needed.
                                  - 6 -


8. Network Resource Discovery


8.1.  GARR on-line network resource guide (Giuseppe Romano)

GARR presented the results of their On-Line  Network  Resource  Discovery
work.   The  resource guide can be accessed via telnet:gopher.nis.garr.it
or gopher:gopher.nis.garr.it The presentation  concluded  that  the  RIPE
database,  relating  to network operations, was not an appropriate medium
for storing this kind of information.  It was  therefore  suggested  that
the  results of this valuable work should be discussed further within the
NIDUS working group with a view to identifying future developmental  work
and possible collaboration with related interest groups.

Photocopies of the presentation were distributed at the meeting.  Further
information  relating  to  this  project  can  be  obtained from Giuseppe
Romano, email romano@localhost.

8.2.  Guide to Network Resource Tools (Daniele Bovio)

Hard copies of the EARN Network Resource guides were distributed  at  the
meeting.   The guides are intended to provide a service to end-users.  It
is planned that these documents will eventually be available on  line  as
rfc's.  Updated revisions to the guides will be forthcoming shortly.


9. How do we ensure a good working European Internet in  1995  (P.  Loth-
berg)


Peter Lothberg presented his view of the technical developments necessary
to  ensure  a  good  European  Internet operation in 1995.  Contact Peter
Lothberg roll@localhost for more details.


10.  Update on the new JIPS services (Phil Jones)

The ASCII text of this presentation can be found  in  the  ripe  document
store in the presentations directory:


o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-pwj-JIPS.txt


10.1.  Introduction

It seemed timely to have an update for RIPE  on  what  was  going  on  in
JANET.   This  relates  substantially  to IP.  RIPE members had noted the
large and expanding number of DNS-named hosts in the United Kingdom. This
was  by  no means all JANET developments of course: there were commercial
providers in the United Kingdom, and the numbers of these  were  increas-
ing.   However,  there was much activity in the JANET community, and that
was the subject of the talk.
                                  - 7 -


10.2.  Requirements(1)


o the latest!  ...  audio, video, high speeds, etc.
o plus'more of the same', much more.
o connectivity: general, but with emphasis on'similar communities', i.e.
  those around the world (as well as in the United Kingdom) involved in
  research, academic work and education.


This much was probably as expected.

10.3.  JANET - Status Quo

JANET was an X.25 network, with IP running as an  optional  service  over
that.   (The JANET IP Service, JIPS, offered a full routing service, with
connected institutions having to concern themselves with routing only  in
so  far  as  it was necessary for them to deal with it.) There were other
network level protocols run over the X.25 service too, e.g.  CLNS.   How-
ever,  it was X.25 and IP that were the JNT-supported services.  Over 75%
of the JANET traffic was IP-related, and this proportion was rising.

Of the 200 or so institutions connected to JANET, some 50 or so were con-
nected  by  leased  lines  at 2mbps, with the rest connected at 64kbps or
less.

JANET had international links via the US/UK `fatpipe', and via both Ebone
and Europanet.

10.4.  Requirements Revisited - Network Services

These were:


o IP
o CLNS
o YBTS ("Yellow Book")
o CONS
o X.25 per se (e.g.  for X.29)
o Proprietary methods
o + (later?) as required for `isochronous services'.  (ATM?).


In summary, the major requirement was clearly IP, but the requirement  of
users  in  the JANET community for X.25 needed to be catered for, and for
the indefinite future.

10.5.  Plans and Developments

Higher Speeds (34mbps+) were required  internationally.   On  a  national
basis, the SuperJANET project was developing services at these speeds and
greater to add to the JANET profile of operational Network  services  and
to enhance JIPS.
                                  - 8 -


To make JANET more efficient and effective, the `base' protocol on  JANET
will  change  to  IP.  To cater for X.25, the JNT was seeking ways to run
X.25 over IP, and X.25 alongside IP (e.g.  using frame relay).

10.6.  SuperJANET

12+  PDH-connected  institutions,  4*34mbps.   (Later:   SDH).45+   SMDS-
connected  institutions,  10  mbps, including the above.  SuperJANET will
provide IP connections at higher speeds to be incorporated  within  JIPS.
There  was obvious (e.g.  financial) pressure to remove leased lines from
institutions connected via SuperJANET....  and later,  there  was  to  be
ATM.

10.7.  Special Issues

Name Ordering

There will be an announcement soon of a date  after  which  the  official
ordering  will  change  to  be consistent with the `international' order.
Phil would keep RIPE informed.


11.  Update on EMPB services


11.1.  Status EUROPAnet (Svend Moeller Nielsen)

The slides of the presentation given at the RIPE meeting plenary  can  be
found in the document store in directory and file:


o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-EMPB-status.txt

The developments of the  EuropaNET  since  the  last  RIPE  meeting  were
presented together with the near term enhancements.

The major activity was the execution of the IP Pilot which started  March
1,  1993.   It entered a preproduction phase June 16, 1993 and ended suc-
cessfully September 2, 1993.

6 regional networks had participated in the  Pilot:  SWITCH,JANET,  GARR,
RCCN,  DFN and SURFnet.  All were using BGP3.  Some connections were done
on 64 kbps running IP encapsulated inX.25 to a EuropaNET internal  decap-
sulation point.  Others were made on 1.5 and 2 Mbps lines using HDLC/LAPB
or PPP.Everyone had a back-up connection  via  X.25  to  a  decapsulation
point  inside EuropaNET.  In addition hereto a gateway was established by
DANTE between EuropaNET and EBONE to provide Internet connectivity.   The
gateway  which  now  is  operational at512 kbps is managed by SURFnet.  A
second gateway will  be  established  shortly  in  London.   It  will  be
operated by JANET.

During the Pilot basic connectivity was checked  using  PING,  and  trace
route  and  by  running  TCP  and  UDP based applications PING tests were
furthermore used to monitor availability and to measure round trip times,
                                  - 9 -


RTTs.  Average RTT between an IP host in Amsterdam and an IP host in Lon-
don, Dusseldorf or Zurich is 30 msecs.  With a host in Madrid  it  is  70
msecs.  This corresponds in practice to the propagation delay.

Different aspects of the routing protocols EGP 2 and BGP  3were  investi-
gated,  like distributing of routing information and timers to update and
to reconnect.

Throughput was tested at 2 Mbps between DFN and SWITCH by means of a  UDP
based program implemented by DFN.  For 64-byte packets the results were:


o switch -> dfn: 1736 pps
o dfn -> switch : 1781 pps
o For 1024-byte packets: 223 pps


This corresponds quite good to the lab-tests where  a  little  more  than
1800  pps  was measured without the EuropaNET nodes being fully loaded. A
TTCP test carried out by SURFnet between DFN and SURFnet gave:


o 64 bytes packets : 898534 bps
o 1024 bytes packets : 941969 bps


The result is practically independent of the packet size  and  shows  the
limitation of the TCP window in use.  Tests were also done using TCPBLAST
for connections involving 64 kbps.  Up to 57 kbps was achieved.  Now  the
service  has  entered  the  production  phase.  Connected are besides the
pilot participants, RED-Iris, BELnet, HEAnet and RESTENA.

In the coming weeks the X.25 tunnels will be moved from NIKHEF and  JANET
to internal EuropaNET decapsulation points.

The EuropaNET NMC runs a primary  name  server:  (dns1.empb.net)  in  The
Hague backed up by two secondary name servers:


o switch: (scsnms.switch.ch)
o surfnet: (ns.surfnet.nl)


For the DNS the following naming convention:


o each europanet ip access module: <city><serial number>.empb.net
(amsterdam1.empb.net)

o each interface:<name>-if.<city><serial number>.empb.net
surf-if.amsterdam4.empb.net


In addition to the DNS host the NMC runs a host which constantly monitors
                                 - 10 -


availability  by means of PING tests.Alarms are generated on PING failure
and PING reports are made per day to investigate stability and RTTs.

For troubleshooting and performance testing the hosts  canparticipate  in
FTP and UDP tests.

o Mail can be sent to the NMC: nmc@localhost orinfo@localhost.

Within the near future a new access method will  be  released.   It  will
provide  IP connectivity in the beginning and CLNP connectivity later via
Ethernet or connectivity via serial line for IP, CLNP and X.25  from  the
outset.   The IP, CLNP and X.25 routing is done in the Access Box, called
the Magic Box.The Magic Box is managed by  the  NMC  which  can  monitor,
troubleshoot, download software to and configure the Magic Box.

The Magic Box is of the same make as the EuropaNET nodes and connects  to
a  EuropaNET  node  via the EuropaNET internal protocol.  Hence the Magic
Box will automatically perform rerouting if more access  lines  are  used
and  one of the access lines are failing.  This rerouting will take place
without affecting the IP, CLNP and X.25 routing.

During the fourth quarter, 1993 BGP 4 will be deployed  providing  inter-
working  with  BGP 3 and EGP 2 with the possibility for route aggregation
and selective deaggregation.

11.2.  Status EUROPAnet/EBONE gateways (Erik-Jan Bos)

For 1993 the "DANTE Gateways" will serve as the  connection  between  the
EMPB  IP  Service  and Ebone.  The Amsterdam gateway is fully operational
now at a speed of 512 kbit/s, there is work in  progress  on  the  London
gateway.  From an Ebone perspective these gateways are known as the DANTE
RBS, from an EMPB IP perspective these gateways are the connection to the
Internet at large.

Since the connection of the EMPB IP Service to the Internet there is work
in progress on the rehoming of the old "IXI tunnels" to NIKHEF and JANET.
EMPB IP is fully capable of handling the  decapsulation  of  IP  in  X.25
internal  to their network.  All regionals still having tunnels to either
NIKHEF or JANET have been contacted to migrate to the new situation.

The sheets of the presentation can be retrieved as:


o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-ejb-DANTE.ps.Z



12.  Update on EBONE (Bernhard Stockman)

Bernhard Stockman outlined the plans for EBONE in the future.  There  was
discussion  over  the organisational structure governing the GIX and dis-
tributed RBS`s.  Further information can be obtained from Bernhard Stock-
man boss@localhost.
                                 - 11 -


13.  Update on EUnet (Glenn Kowack)

EUnet has been operating since 1982.  It connects over ten thousand sites
and  networks,  with  gateways  to major commercial and research networks
around the world including the Internet, the Commercial Internet Exchange
Association  and  NSFnet.   Services  are  provided in 27 European-region
countries at 50 Points of Presence.

EUnet International Structure

EUnet services are provided in two layers.  The centre of the  system  is
EUnet's  European Network Operations Centre (NOC) in Amsterdam, The Neth-
erlands.  This centre exchanges data between, and provides  services  and
management,  to  each  of  the  National  EUnet Service Provider Networks
located throughout the greater European region.   Each  National  Service
Provider has a connection to the European NOC.

National EUnet Service Providers

Each National Service Provider operates its own Network Operations Centre
(National  NOC),  which  provides  EUnet services and user support in the
local languages.  Technical problems and requests  for  services  at  the
national  level should be addressed to postmaster@localhostcountry>.eu.net.  Many
EUnet service providers offer unique services.

Each national EUnet (through their national NOCs and  various  Points  of
Presence  (EU-POPs))  acts  as  a point of concentration for all traffic.
This traffic is then transmitted from each EUnet provider to the European
NOC in Amsterdam for distribution to the other EUnet providers, peer net-
works, and intercontinentally.  In some cases, EUnet providers connect to
intervening EUnet providers, and from there to the European NOC.

The vast majority of EUnet traffic travels over EUnet's  own  infrastruc-
ture.   From  Amsterdam,  EUnet  connects to every major R & D network in
Europe and, via EUnet's transatlantic digital  line,  to  UUnet  and  the
NSFnet in the United States.

EUnet is also a member of Ebone '93 (European Backbone), and The  Commer-
cial Internet Exchange (CIX) Association.


14.  Update on SPRINT infrastructure support (Bob Collet/Peter Lothberg)

Bob Collet was unable to attend the meeting at the last minute  and  sent
this  apologies.   Peter Lothberg gave a presentation in his place. Peter
outlined the historical development of SPRINT and some of its more recent
activities.  Contact Bob Collet rcollet@localhost for further infor-
mationon SRINT.


15.  RIPE European Internet Architecture WG-BOF Report

Chair: Bernhard Stockman Minutes: Mike Norris
                                 - 12 -


Bernhard Stockman had circulated a  proposal  for  an  European  Internet
Architecture  (EIA)  WG  within  RIPE, together with a draft charter.  He
developed some of the operational issues such as:


o What is routing stability and how is this achieved?

o Multiple ISPs (Internet Service Providers) providing full connectivity
to the global Internet give needs for traffic interchanges.

o Where should such interchange points be located and who should be
allowed to connect?

o Need for a management framework for such interchanges.


The technical issues need to be specified and timetabled.  There was sup-
port  for  the  idea  of  a EIA laboratory, so its needs would have to be
determined, its tasks defined and resources specified.  One possible task
would be to participate in SDRP pilot.

In the general discussion, it was reported that there was support for the
model of a distributed GIX (D-GIX).  The D-GIX could be see as an interim
solution awaiting a more full-fledged solution  providing  the  necessary
tools for multiple independent interchanges.

The immediate problem would have to be defined and  an  interim  solution
based  on the separation of routing and payload traffic developed as out-
lined in the D-GIX model, presented earlier at  this  RIPE  meeting.  The
solution would demand a fully populated routing registry.  Aiming at full
connectivity, it should not limit flexibility, but should make choices of
connections possible.

It was agreed there should be an EIA WG within RIPE.  There was some dis-
cussion  over  possible confusion arising from the suggested name for the
group.  A name was finally settled as European Engineering Planning Group
(EEPG).  It should be open and neutral.  While focusing on the D-GIX now,
it should be conscious of the need for development beyond this  strategy.
The WG should have formal liaison and reporting procedures with the IEPG,
which was seen as the appropriate forum for the D-GIX activity.  Bernhard
Stockman agreed to be the chairman for the new RIPE working group.

Action: 16.1 Bernhard Stockman. To define scope and work plan for the new
RIPE working group.


16.  Introduction of DANTE (Howard Davies)

Howard Davies, General Manager of DANTE, gave a presentation of the  com-
pany,  its  current  activities, and future plans.  The mission statement
for the DANTE organisation was distributed at the meeting.  A summary  of
the presentation is as follows and is available by ftp from the presenta-
tions directory
                                 - 13 -


o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-hd-DANTE.txt

Following extensive discussions within RARE, and with particular relation
to  the  need to provide continuity of services established by the COSINE
Project, the basic structure of  a  new  organisation  which  would  take
responsibility  for the provision and management of international network
services for the academic and research community was proposed in a  docu-
ment  towards  a  Single  European Infrastructure , the Final Report RARE
Task Force on the Establishment of the Operational Unit  (commonly  known
as the Green Book) which was published in January 1992.

Following widespread agreement in principle with the proposals  contained
in  the  Green  Book,  a  group of 12 European national research networks
signed a Heads of Agreements which defined in outline the legal structure
of a non-profit company in which all members of the group would be share-
holders.  A draft Shareholders Agreement has since  been  produced  which
specifies the internal procedures of the company in full detail.

Because the Shareholders Agreement is necessarily complex and has  to  be
approved  by  many  countries  which  have different legal systems, final
agreement on its contents necessarily takes a long  time.   In  order  to
make  progress  more quickly, RARE agreed to purchase an off-the-shelf UK
company (which was named Operational Unit Limited) as an interim measure.
The  company name was subsequently changed to DANTE (Delivery of Advanced
Network Technology to Europe Limited).  DANTE is still  wholly  owned  by
RARE  but  ownership will be transferred to the national networks as soon
as the Shareholders agreement has been finalised.

DANTE was formally launched on 5 July 1993 in Cambridge, UK, where it has
established its offices.  As of 15 September 1993, DANTE has 4 employees.
This number will increase to 8 by 15 October 93.  The planned staff  com-
plement at the end of the first year of operation, i.e.  in July 1994, is
12.

DANTE's Mission Statement is exactly as proposed in the Green Book.   The
full  statement is provided as a separate paper available with the papers
available for the RIPE meeting

DANTE has taken over a number of Application Level services from  COSINE,
notably the MHS service and management of the PARADISE Project.  There is
also a software portfolio (EXPLODE, FORTRESS) which may be exploited.

The most important DANTE services are however the network level services.
DANTE  is  taking  responsibility  for  the  EMPB  service  (operated  by
Unisource Business Systems) which has been operational for some time; the
2  Mbps  native  IP component of the service completed all aspects of its
acceptance test on 2 September 1993.

DANTE will combine transatlantic connections and an interconnection  with
Ebone  with EMPB as the European backbone to provide a packaged EuropaNET
service which offers full connectivity with the global  Internet.  Inter-
connection with Ebone under an agreement valid until the end of 1993 pro-
vides intercontinental access at present.  DANTE will have its own  tran-
satlantic  capacity  from  the  beginning  of 1994 and expects to use the
                                 - 14 -


proposed distributed GIX as a means  on  interconnection  with  Ebone  2,
EUnet and other services from mid-1994.

DANTE is examining a number of aspects of high  speed  service  planning.
The  extension of the EMPB service to 4/8 Mbps would provide a short term
increase in available capacity.  Many new applications however require an
order of magnitude increase in bandwidth and the possibility of introduc-
ing a 34 Mbps service is being examined.   Several  technologies  are  in
principle  available  to  support such services - native IP, ATM (with IP
over ATM) and SMDS are all being considered - but the lack of  availabil-
ity of lines or other PTO services inhibits progress. Developments within
programmes such as tenibc and the HPCN initiative will also be followed.


17.  Update on networking with Russia (Rob Blokzijl)

Progress was reported on the following projects:


o NASA: the NSI link to Moscow is expected to be installed in November
this year.  The link will be operated under the standard NSI AUP.

o DoE: ESnet is progressing with the definition of their requirements
for networking with Russia.  First investigations on the possibility
of combining their efforts with those of NASA are under way.

o Novosibirsk: a new project has been identified to connect the Siberian
branch of the Russian Academy of Sciences in Akademgorodok (Novosibirsk)
to the Internet via a satellite link with the Institute of High Energy
Physics at the University of Helsinki.  The technical specifications
are ready, some of the funding is still missing.

o DESY/DFN - MSU: the remaining administrative obstacles have been
removed.  The link is expected to be installed in October 1993.

o Gran Sasso - Dubna: this link is expected to be delivered by the end
of 1993.

o Moscow Backbone: the fiber backbone in Moscow has been progressed in
the sense that all the necessary administrative work is accomplished.
Installation is expected to be finished before the start of the winter
season.

o ISF Moscow: the first international links supported by the ISF are
operational.

o NATO: an introduction of NATO plans for support of networking was
presented.  NATO has initiated, together with RARE, the organisation of
a networking seminar in April 1994 in Moscow.  The aim is to get
Russian policy makers around the table in order to ensure
                                 - 15 -


18.  Reports from the working group parallel sessions

The agendas of each of the working groups are in Appendix 3.

18.1.  Local-ir Working Group (D Karrenberg)

Chair: Daniel Karrenberg Scribe: Anne Lord,  Daniel  Karrenberg,  Martijn
Roos Lindgreen

The proposed agenda was accepted after extra points were added:


o discuss needed documentation
o discuss the procedure to set up new top level domains


Reports for information:

The DE-NIC will be shut down and moved to another place from the 15th  of
December.  It will be funded by all the DE service providers.

A local-IR workshop was held on Wednesday 15th September in the  morning.
As  it  was  an informal meeting no minutes were taken.  The workshop was
considered useful and will be held in conjunction with a RIPE meeting  on
a  yearly  basis.  A more extensive reporting was asked for, but was con-
sidered inappropriate because of the informal nature of the workshop.

Proxy network entries:

Many participants felt that the network proxy entries should be  avoided.
After  intensive  discussion  it was decided that a draft policy for this
will be worked out by Duncan Rogerson and Daniel Karrenberg.   This  will
not  happen  without input from those service providers who are in favour
of the proxy entries.

Action: 16.2 Daniel Karrenberg/Duncan Rogerson To draft policy  on  proxy
network entries.

Autonomous Systems Database Template

The AS Database template was formally accepted.

Should we maintain a list of local IRs and publish it?

After intensive discussion it was decided that a list of Internet  Regis-
tries  will  be maintained and published by the RIPE NCC.  This list will
be sorted by country  and  contain  all  local  providerand  non-provider
registries.   A draft of the list will be circulated on the local-ir list
by the NCC.

Action: 16.3 NCC To publish a list of Internet Registries - draft list to
be circulated on the local-ir list.

Input for the Activity Plan
                                 - 16 -


It was suggested to add the following activity:  Maintain  and  regularly
publish the list of local Internet registries.

Action: 16.4 NCC Propose to add to the new RIPE NCC Activity Plan -  pub-
lishing and maintaining a list of local IRs

Another suggestion is to  strengthen  the  local  registry  liaison  with
tutorials  and  workshops,  but no decision was taken on how to implement
this.

AoB

It was felt that more documentation is needed.  The following  volunteers
were appointed to edit the documents:

Action: 16.5 Juliana Tamorri FAQ on CIDR and subnetting.

Action: 16.6 Daniel Karrenberg Why return unused IP address space and  be
a good network citizen.

The problem of finding registrars for new top level domains  was  raised;
there  was  consensus that the RIPE NCC shall offer to serve as temporary
registrar for top level domains in our region, until about a  dozen  sub-
domains have been registered.

Action: 16.7 NCC To offer to serve as temporary registrar for  top  level
domains in Europe.  Contact IANA.

18.2.  Database working group (Wilfried Woeber)

Chair: Wilfried Woeber Scribe: Daniel Karrenberg

The proposed agenda was accepted.

The new Database Software

Marten Terpstra provided a detailed report on the current  state  of  the
DB-Software,  both  from  a  software  point  of view as well as from the
deployment point of view.  The slides for this presentation can be  found
in the presentations directory in the RIPE document store:


o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-marten-DBDETAILS.ps.Z


The new software is in production use since  Friday  September  10th  and
until  now there have not been any major problems.  During the discussion
it was again stressed, that the current implementation  is  built  to  do
syntax  checks  according  to the object description and not according to
common usage practice.  The RIPE NCC welcomes suggestions as to where the
syntax checking needs to be changed.

Currently those attributes marked illegal are deleted from the  database,
but not the objects as a whole.
                                 - 17 -


One of the things discussed was how to avoid a possibly large  number  of
bounced  submissions.   One  way of doing this is to obtain (part of) the
new software to do the checking locally.  The betaversion of the software
is available, although it probably makes more sense to wait for the offi-
cial software distribution which will provide a dedicated syntax-checker.

A syntax checker daemon at the NCC  was  also  suggested  to  remove  the
requirement  to  run the software locally.  A template generator was sug-
gested as well.  This needs more discussion on the mailing list.

The NCC has run a syntax check on the whole database  and  was  asked  to
make the syntax error output available.

Daniel Karrenberg gave an overview on the "Authorization and Notification
of  Changes  in  the RIPEDB" proposal.  It was decided to implement it as
proposed.  Proposals on how to better support  the  distribution  of  the
update process are very welcome.

The discussion of  implementing  "guarded  attributes"  revealed  concern
about  the  possibility to delete an object that has a guarded attribute.
It was agreed that the implementation will not delete any object as  long
as guarded fields are present.  This will force removal of guarded fields
from the object before the delete operation is  accepted.   The  database
wil  NOT  keep track of "pending deletes", thus the delete request has to
be submitted again after removal of the guarded  attribute(s).   The  NCC
will  look into ways to notify guardians of failed deletes.  The origina-
tor of the delete request will of course be notified.

The procedure to convert existing information  into  guarded  information
(eg.aut-sys: for the network object) was agreed as follows:


o the NCC moves the information from the database to the guardian files
  initially the NCC is the guardian

o as soon as possible, responsibility for the files is transferred to
  the real guardian(s)


In instances of where two or more guardians  want  to  set  an  attribute
which  can  only  have one value, the current state of the attribute will
not be changed and all guardians concerned will be notified.

Example:

The aut-sys attribute of network 193.193.193.0 in the database is  AS193.
AS4711  adds  this  net  work  to his guardian file. At the next database
cleanup all guardian files will be examined.
                                 - 18 -



o If the AS193 guardian file still contains 193.193.193.0 a conflict
  exists and the current database state prevails: AS193 will remain.

o If 193.193.193.0 has been removed from the AS193 guardian file no
  conflict exists and AS193 will be replaced by AS4711.


Similarly the aut-sys attribute will remain undefined if it is  undefined
and two guardians add it simultaneously.

Since the cleanup runs every 24 hours  guardians  involved  in  a  change
should  coordinate  their  changes such that they are done in the same 24
hour period.

18.2.1.  Database (and Software) Documentation

The documentation will be structured to consist of:

o object definitions and  general  background  information,  by  Wilfried
Woeber and NCC and available before the end of 1993


o software documentation, provided by the NCC asap
o maintainer's guide (for e.g.  the Local-IRs)
o additional input and support is expected from the Local-IRs and others
o Secondary Server Guide


Additional input and support is expected from the Local-IRs  and  others.
The  Objects  Definition  and  the  SW-Documentation get priority, in the
listed order.

18.2.2.  Unique Person Handles

Given the growth of the database, it  is  urgent  to  distinguish  person
objects for people with the same name!

After another round of thorough discussion it was decided that RIPE  sug-
gests  a global scheme to the InterNIC.  One of the possible solutions is
to reserve a sub-range of the NIC handle space for RIPE allocation,  e.g.
XY3000-XY5000.   If this approach fails, then WW and the NCC will propose
a unique identifier scheme for RIPE (aka "RIPE Handle").

18.2.3.  Objects Review and Proposals

The proposed CLNS routing object  (dom-prefix:)  was  presented  by  Henk
Steenman and accepted.  Some minor loose ends how to check for syntax and
maybe semantics of the hexadecimal strings that  are  the  CLNS  address-
prefixes  have to be ironed out (Henk Steenman and Tony Bates). The long-
standing proposal to build a "Resource Object" was formally withdrawn.

Then the discussion moved on to agree on how to make a smooth  transition
from  ripe-60  to  the ripe-81 format to describe the routing.  The steps
                                 - 19 -


are as follows:

o as soon as the guarded fields are implemented, ripe-60 entries will  no
longer be accepted.

o ripe-60 information is converted to ripe-81 format.

when there are no longer any operational dependencies  then  all  ripe-60
data will be removed from the database.

Jean-Michel Jouanigot is the  focal  point  for  the  ripe-60  -->  ripe-
81transition coordination.

Also the gateway: field for the  network  objects  was  confirmed  to  be
obsolete and can be removed from the database.

18.2.4.  DB Exchange format(s) and procedures

The circulated document about the agreed interchange format  was  briefly
reviewed.   Everything  seems  to be in place to actually start exchanges
with the InterNIC.  There was consensus that this has a very high  prior-
ity.  Currently the recommendation is not to try to get the various data-
bases in sync manually.

18.2.5.  DB usage conventions and recommendations

Quite some time was spent to discuss the connect: attribute of  the  net-
work  object.   It  was agreed that the only well-defined value is LOCAL.
This attribute should eventually be obsoleted.  Later it was  noted  that
it  is currently mandatory and should be made optional after one round of
mailing-list discussion.

However, there is a need for  the  functionality,  maybe  the  community:
approach  is  the  right  way  to go (e.g.  create community NSF).  Still
there is concern that some of the approaches that are  obvious  for  "old
hands  in networking" are not necessarily useful for the end-users. Maybe
the tools coming out of the PRIDE project can help to solve this problem.
NCC  to  start the discussion with a rough proposal before the next meet-
ing.

18.2.6.  whois++ by Peter Deutsch et.al.

The whois++ project was briefly mentioned, although the DB group had  too
little information to actually discuss the issue.

18.2.7.  AOB

It was mentioned that there is a  need  for  new  tools  to  support  the
Local-IRs.  This needs more discussion on the e-mail list.

Action-List:

Action: 16.8 NCC Put together a consolidated distribution of the  new  DB
software, including a separate syntax checker for objects.
                                 - 20 -


Action: 16.9 Wilfried Woeber Start discussion on the DB mailing  list  on
new  tools needed, e.g.  template generator, syntax checker daemon at the
NCC.

Action: 16.10 NCC Make the error reports form the DB  syntax  check  pub-
licly available.

Action: 16.11 NCC Implement changes to DB  procedures  according  to  the
proposal  "Authorization  and  Notification of Changes in the RIPE-DB" by
Daniel Karrenberg.

Action: 16.12 NCC Implement changes to  DB  procedures  for  the  guarded
attributes according to the agreement.

Action: 16.13 Wilfried Woeber and NCC Produce documentation about  "Back-
ground,  History  and  Object  Definitions" for the new database software
before the end of 1993.

Action: 16.14 NCC Produce "Software Documentation" for the  new  database
software asap.

Action: 16.15 NCC To approach the InterNIC to agree on the use of a  sub-
range of the global NIC-Handle space for RIPE usage.

Action: 16.16 Henk Steenman and  NCC  (Tony  Bates)  Implement  the  dom-
prefix: object for CLNS routing, after tightening the syntax defini- tion
and semantics of the CLNS-address hexadecimal string.

Action: 16.17 Jean-Michel Jouanigot To  coordinate  the  transition  from
ripe-60 to ripe-81 format for routing description.

Action: 16.18 NCC Try to actually get the synchronisation of the  various
databases going, using the recently agreed DB Exchange Format.

Action: 16.19 NCC Start discussion on the mailing  list  by  providing  a
first proposal how the functionality of the badly defined connect: attri-
bute could be replaced (with the target group of the end-user  in  mind!)
by using e.g.  community: and other forthcoming tools from the PRIDE pro-
ject.

18.3.  Connectivity (Milan Sterba)

18.3.1.  ECE Connectivity Update


o DFN announces a 64 kbit line between DFN office in Berlin and Riga
  Univ.
o Albania has now a first MX entry in the DNS


Roman Adamiec : Polish connectivity
                                 - 21 -



o Warsaw is now a full dual homed RBS (2 MBit satellite connection to
  Stockholm paid by NASK, 128 kbit to Vienna)

o a project of a Warsaw MAN based on ATM is under way (partners are not
  only academia and PTT's but also gov.  and com.  institutions)

o plans to upgrade majority of intercity lines to 64 kbit (these lines
  do not bear an "academic" AUP)

o major nodes are now being upgraded to professional routers

Balazs Martos: Hungarian connectivity

o estimated need for connectivity to EBONE for 1994 is 128-192 kbit
o Budapest has now a very meshed FDDI MAN operational
o 6 major cities are now connected to HUNGARNET by 19.2 lines (upgrades
  to 64 kbits planned)
o 300 institutions are connected over IP over public X25 (using mostly
  PC routers and cisco routers in concentration points)
o the AUP on HUNGARNET allows only for R&D traffic (no matter whether
  private or public institution is connected)
o the HEPnet line to CERN is subject to strong usage restrictions
  imposed on the hungarian side of the line (this is no longer a problem,
  the line is only 9.6 kbit/s)
o two ECE IXI lines running (to Bern at 64 kbit and to Prague at 9.6)
  (used for tunnelling IP/X25
o problems mentioned on the London gateway to EBONE)

Tomaz Kalin: IXI

The contract covering ECE IXI has been modified as to cover also native
IP access.  ECE countries are now free to negotiate migration to native
IP with the provider.  EC financing for ECE "IXI" in 1994 is under
negotiations

Petr Kral: Czech connectivity

o CESNET now covers ten major academic cities with intercity connections
  migrating to 64 kbit.  Other connections are planned for later this year
o CESNET now has 64 kbit lines to Vienna and Bonn EBS's and an ECE IXI
  line to Amsterdam (upgraded to 64 kbit only recently) emphasis now given
  to user support and user services
o the 19.2 line to Banska Bystrica carries an important part of the
  international traffic of Slovakia
o FDDI MAN projects exist in Prague and Brno areas

Tomaz Kalin: Slovenian and Croatian connectivity

o Zagreb has its own 19.2 line to Vienna
o the line from Ljubljana to Vienna should be upgraded to 128 kbit
o there is a 19.2 line between Zagreb and Ljubljana carrying IP and
  DECnet
                                 - 22 -


Rob Blokzijl suggests to stop doing the ECE connectivity map  and  invite
ECE countries to store their maps into the RIPE map store

Tomaz Kalin reports on joint government level networking workshops organ-
ized by RARE and NATO in Budapest in October and later planned for Moscow
(April 1994?)

18.3.2.  Connectivity Data Store

Final version of the CDS fact sheet guidelines will be produced including
comments from RIPE members and stored as a RIPE draft

An umbrella hypertext document will be produced which will  describe  the
CDS  as  a  whole and rules for contribution and will contain pointers to
fact sheets and maps of:


o networks operating on international scale
o countries and networks operating in one single country

Fact sheets and maps will be stored as they are  submitted  (unless  they
are not conforming to the CDS guidelines) and will stay under the respon-
sibility of the contributor

The CDS is open for all contributions from networks operating in  Europe.
A  first  solicitation for contributions will be done to populate the CDS
with first data.

Contributions will be sent to cds-editor@localhost

The technical maintenance of the CDS belongs to the NCC

The CDS should be accessible by WWW as  a  primary  method  but  also  by
gopher, ftp and e-mail

Action: 16.20 Milan Sterba Produce a revised version  of  CDS  guidelines
and submit it as a RIPE draft

Action: 16.21 Milan Sterba, Anne  Lord  Produce  the  umbrella  hypertext
document for the CDS

Action: 16.22 Milan Sterba Solicit first contributions to the CDS.

Action: 16.23 NCC Create the cds-editor@localhost alias and establish pro-
cedures to integrate new CDS contributions and maps to the CDS.

18.4.  DNS Working Group (Francis Dupont)

Chair: Francis Dupont Scribe: Lars-Johan Liman

18.4.1.  Opening

Francis Dupont opened the session.  Lars-Johan Liman was appointed secre-
tary.
                                 - 23 -


18.4.2.  Old Items Including a Second Name Server in Europe

The possible need for a second root name server in Europe was  discussed.
Of  the  1.4 million hosts now registered, 400,000 are located in Europe.
This ought to cause a lot of unnecessary traffic  across  the  US  lines.
Suitable  location  for  a second European root server was discussed, and
suggestions were Paris (GIX pilot), Amsterdam  (many  IP  providers  join
there), and Vienna (many connections to the fast growing Eastern Europe).

It was decided to contact the Connectivity WG to check if Vienna would be
a suitable site, taking future plans for Eastern Europe into account, and
if so, and if someone in Vienna is willing to host and tender a root name
server,  the  WG  would  suggest  Vienna for a second root name server in
Europe replacing one of the existent US root servers.

18.4.3.  IPng support

Discussions on IP Next Generation are taking place in the  IETF,  but  no
clear  decisions  were  heard  of, and therefore it seemed useless to get
lost in discussions on software support for it.

18.4.4.  Software and Tools

Experiences with the new versions of the name server kit  (named)  showed
that  it  is  not  very stable.  Version 4.9 is clearly broken in several
places and should not be recommended for use anywhere.  Version 4.9.1  is
a  BSD 4.4 Unix special version.  4.9.2 is much better than 4.9 but still
not good.  It should not be used for production in  "unattended  environ-
ments".

The question was raised whether there is a name server for the  Microsoft
Windows NT platform.  No answer was found.

18.4.5.  Input for Piet Beertema's Internet Draft on DNS (BIND) ConfigEr-
rors.

the paper was discussed in detail and approved unanimously.  A note  from
Rob  Elz  kre@localhost  on  the subject of reverse mapping for the
127.0.0.1 local host address was circulated and  approved  to  be  incor-
porated in principal in the draft.

The WG would like RIPE to recommend that, if possible, local IP  registry
is performed by a nonpolitical 3rd party organisation, not a service pro-
vider.  This to avoid any chance of political friction.

18.4.6.  Closing

Francis Dupont thanked everyone for their contributions, and  closed  the
meeting.

18.5.  Routing Working Group (Jean-Michel Jouanigot)

Chair:Jean-Michel Jouanigot Scribe:Gilles Farrache
                                 - 24 -


Previous minutes; action list; agenda

Open action items comprise the following:

Action: 15.19 Peter Lothberg To draft document on Inter-AS local informa-
tion.

Action: 15.21 Daniel Karrenberg/ Jean-Michel Jouanigot To draft  a  docu-
ment on colouring.

The Agenda was approved.

18.5.1.  Ripe-81 status

Tony Bates (RIPE NCC) presented the RIPE-81 statistics.   Among  the  103
known  ASes  in Europe, only 49% are registered in the RIPE database, and
among these 49%, only 60% are syntactically correct.  The fact that  some
of  the  entries are syntactically incorrect is due to the lack of syntax
checking in the previous version of  the  RIPE  database  software.   The
slides of this presentation are available from


o ftp:ftp.ripe.net:ripe/presentations/ripe-m16-tony-RRSTATS.ps.Z

Service providers are urged:

o For those having already registered their ASes, re-send their entries,
so that all entries will be syntactically correct,

o For all the others, send their entries in the RIPE-81format.


It is extremely important that all ASes are registered as soon as  possi-
ble.   The  PRIDE  project  and the GIX route server cannot be successful
without this information.

Once the ASes are registered in the RIPE-81 format,  the  networks  them-
selves  will have to be tagged.  This is not yet possible, but will be in
the very near future (see database Working Group).

18.5.2.  Guardians and procedures (brief)

Marten Terpstra gave a short introduction on the guardian  mechanism  for
the  'aut-sys'  and  'community' tags.  This mechanism will be applied as
soon as the Database working group agrees with it (see  Database  working
group minutes).  Three questions are addressed to this working group:


o What will happen to the current 'aut-sys' tags already stored in the
  Ripe database?
o How will a conflict between two guardians be resolved?
o How will the database software react if somebody tries to delete a
  guarded network entry?
                                 - 25 -


18.5.3.  Use of Ripe-81; conversion of Ripe-60

Ripe-60 objects are no longer accepted.  These objects have  to  be  con-
verted  into the RIPE-81 format, but this should be straight forward.  As
soon as the NCC is able to tag networks with their AS number, the current
users of Ripe-60 should convert to Ripe-81.

Action: 16.23  Jean-Michel  Jouanigot  coordinate  this  conversion  from
ripe-60 -> ripe-81.

18.5.4.  Ripe-81 enhancements

DMZ

There was only positive comment on Daniel Karrenberg's proposal  for  DMZ
networks attributes, that was sent to the list on May 93: "Description of
Inter-AS Networks in the RIPE Routing Registry" (ptraceroute issue). This
paper will therefore be included in the next revision of the paper.

18.5.5.  Colouring

Several ideas were presented to increase the granularity of the  policies
expressed in RIPE-81.  RIPE-81 only deals with ASes, but ASes may contain
several "sub ASes", that have to be  differentiated  within  another  AS:
colours.  Colours are internal to an AS, but could be exported to another
AS for its own purpose.  An example of  this  could  be  that  a  network
tagged  with  a  special  colour would mean "Please do not aggregate this
network", in the CIDR context.  The entries in the  Ripe  database  would
then look like:


o aut-num: AS1111

o as-in: AS1234 100 AS7890/<16 bits representing the colour>

        [...] and

o netnum: 199.199.199.0

o aut-sys: AS7890/<16 bits representing the colour>

BGP4 has the possibility to carry this 16 bits information.

Do to the lack of time, it was decided to go on with  the  discussion  on
the list.  Action is still on JeanMichel Jouanigot & Daniel Karrenberg to
write a draft on colouring (previously action 15.21)

Inter-AS Local Information

Due to the lack of time, this item was postponed and should be  discussed
on the list.  Action remains on Peter Lothberg (previously action 15.19):
                                 - 26 -



o Multi-homed, multi-inter AS connection
o Local inter-AS information.


CIDR

Introduction

The basic principles of CIDR were  briefly  presented.Services  providers
are  encouraged  to  read the RFC 1467: "Status of CIDR Deployment in the
Internet (Topolcic) Aug.  93".

Discussion

Stephan Biesbroeck sent a case study on the list on May 1993  and  Duncan
Rogerson  presented  and distributed a text explaining the impact of CIDR
on their network.

A few remarks were made concerning the availability of CIDR capable  code
in  the  routers:  this code should be widely available before any "real"
route gets aggregated.

BGP4: What's new?

Peter Lothberg presented the BGP4 principles and emphasized  the  differ-
ences between BGP3 and BGP4.  As an application example, he discussed the
EBONE plans concerning BGP4 usage.  The presentation  is  available  from
him.

18.6.  NIDUS Working Group (Nandor Horvath)

Chairman: Nandor Horvath Scribe: Anne Lord

Joyce Reynolds IETF User Services Area Report

The following fyi documents have been updated/issued:


o fyi 2 - FYI on a Network Management Tool Catalog
o fyi 19 - FYI on Introducing the Internet
o fyi 20 - FYI on "What is the Internet?"
o fyi 21 - A Survey of Advanced Usages of X.500


GARR on-line Network Resource Guide

Giuseppe Romano presented the results of the work done by  GARR  on  this
project  and  there  followed  a  general  discussion.  The tool is built
around extended WAIS searches.  A document summary and access  method  to
an  actual  document  are  the  result  of  a  search.  It was noted that
developing the project involved two particular areas of  work  which  are
ongoing:
                                 - 27 -



o developing and refining the tool
o completing the resource description templates


Currently, completing the templates is a manual process and labour inten-
sive.

Future plans for this project were discussed and it was agreed to contact
related IETF working groups (Jill Foster) and to draft a proposal outlin-
ing the project which would be submitted to the RARE RTC for  evaluation.
The  draft  proposal  would  be  circulated to RIPE and the NIDUS working
group for comments.

18.7.  RIPE NCC Review and Activity Plan BOF (Rob Blokzijl)

Based on the outcome of the RIPE NCC review, a new Activity plan for  the
NCC  has to be written.  The results of a first round of discussions dur-
ing two BOF sessions at this RIPE meeting identified the  following  ele-
ments for the new activity plan:


o a detailed description of all technical and administrative activities
currently undertaken by the NCC.

o an important new element will be the involvement of the RIPE NCC in
  technical development work as defined by approved joint RIPE/RARE
  projects.
o the lifetime of the Activity Plan must be clearly defined.
o review procedures must be defined.
o a mechanism for change control must be defined.
o Mike Norris suggested that the final report should incorporate the old
  RIPE NCC Activity Plan (Doc ID: ripe-035).


A first draft of the activity plan will be written based upon  the  above
conclusions, and circulated to RIPE for discussion.  The aim is to final-
ise and approve the new plan during the next RIPE meeting.

Action: 16.24 Rob Blokzijl To finalise the RIPE NCC Review  draft  report
and  document and  send the reportto the ripe-list for approval.

Action: 16.25 Rob Blokzijl Comments received will be incorporated into  a
first  draft  and circulated to the ripe-list for further comments. Dead-
line: next RIPE meeting in January 1994.

19.  Next RIPE meetings

The scheduling of the next two meetings was extensively discussed and the
following dates and locations were agreed:


o January 24-26th, 1994 - Amsterdam
o May 16-18th, 1994 - Amsterdam
                                 - 28 -


20.  AOB

20.1.  RARE CoA

The next CoA meeting is the last CoA  to  be  attended  by  Rob  Blokzijl
representing  the  HEPnet community.  He will be replaced by a consortium
from EKFA.

20.2.  RIPE meetings

Concern has been expressed that the size of RIPE meetings has  grown  too
large  for  efficient work to be done any longer.  Rob Blokzijl agreed to
draft a document on possible ways to reorganise the meeting

Action: 16.26 Rob Blokzijl Draft document  with  suggestions  on  how  to
reorganise RIPE meetings.  Circulate to the RIPE list for discussion


21.  Closing

Rob Blokzijl thanked the participants for attending and declared  the16th
RIPE meeting closed.


Appendix 1 - List of Participants


Roman Adamiec            NASK                     rha@localhost
Dmitry Avdeyev           MSU/Moscow               dmitry@localhost
Tony Bates               RIPE                     tony@localhost
Per Bilse                EUnet                    bilse@localhost
Antonio Blasco Bonito    GARR CNR                 blasco@localhost
Rob Blokzijl             RIPE Chairman, NIKHEF    k13@localhost
Erik-Jan Bos             SURFnet Utrecht          Erik-Jan.Bos@localhost
Daniele Bovio            EARN                     hi@localhost
Graca Carvalho           RCCN                     gracat@localhost
Yves Devillers           INRIA                    Yves.Devillers@localhost
Francis Dupont           INRIA Rocquencourt       Francis.Dupont@localhost
Havard Eidnes            UNINETT                  Havard.Eidnes@localhost
Stefan Fassbender        EASInet GMD              stf@localhost
Gilles Farrache          IN2P3                    farrache@localhost
Peter Ford               Los Alamos               peter@localhost
Elise Gerich             NSF MERIT                epg@localhost
Herluf Hansen            Unisource                hha@localhost
Ian Harding              chernikeeff              ih@localhost
Hakan Hansson            Unisource                hh@localhost
Nandor Horvath           HUNGARnet                horvath@localhost
Willi Huber              SWITCH                   ch-zone-contact@localhost
Avgust Jauk              ARNES                    jauk@localhost
Phil Jones               JANET JNT                p.jones@localhost
Tomaz Kalin              RARE                     Kalin@localhost
Daniel Karrenberg        RIPE NCC                 Daniel.Karrenberg@localhost
Joachim Klaus            DE-NIXC                  jk@localhost
Lothar Klein             GMD/EASInet              lok@localhost
                                 - 29 -


Glenn Kowack             EUnet Amsterdam          glenn@localhost
Petri Kral               CESNET                   pkl@localhost
Jason Leake              RAL                      leake@localhost
Lars-Johan Liman         SUNET                    liman@localhost
Martijn Roos Lindgreen   NLnet                    martijn@localhost
Anne Lord                RIPE NCC                 anne@localhost
Peter Lothberg           EBONE                    roll@localhost
Balazs Martos            HUNGARNET                Balazs@localhost
Joseph Michl             Belwu                    michl@localhost
Kit MIles                InterAccess              kitm@localhost
Dave Morton              ECRC                     Dave.Morton@localhost
Sven Moller Nielsen      Unisource                smn@localhost
Mike Norris              HEAnet                   mnorris@localhost
Willem-Derk Nydam        Unisource                none
Petri Ojala              EUnet                    ojala@localhost
Willi Porten-Herzig      GMD                      porten-herzig@localhost
Juergen Rauschenbach     DFN ZPL                  rauschenbach@localhost
Niall O'Reilly           Univ.  College, Dublin   noreilly@localhost
Joyce Reynolds           ISI                      jjkrey@localhost
Duncan Rogerson          JANET/JNT                D.Rogerson@localhost
Guiseppe Romano          GARR                     romano@localhost
Artur Romao              FCT/UNL-RCCN             artur@localhost
Jos de Ronde             Unisource                none
Pavel Rosendorf          PICT                     prf@localhost
Miguel Sanz              RedIRIS, Spain           miguel.a.sanz@localhost
Willem van der Scheun    IBC SARA                 scheun@localhost
Andreas Schachtner       EUnet/Uni Do             afs@localhost
Henk Steenman            SARA                     henk@localhost
Milan Sterba             CESNET                   Milan.Sterba@localhost
Don Stikvoort            SURFnet                  stikvoort@localhost
Bernhard Stockman        NORDUnet KTH             boss@localhost
Juliana Tamorri          GARR                     tamorri@localhost
Marten Terpstra          RIPE NCC                 marten@localhost
Geza Turchanyi           HUNGARNET                turchanyi@localhost
Daniele Vannozzi         GARR/NIS                 Vannozzi@localhost
Cristina Vistoli         INFN                     Vistoli@localhost
Ruediger Volk            Uni Do, DE-NIC           rv@localhost
Harm Werkman             Unisource                none
Marcel Widget            SWITCH                   wiget@localhost
Wilfried Woeber          ACONET                   woeber@localhost



Appendix 2 : List of Open Action Items

Action: 15.4 Bob Day/NCC To fold in the comments of the working group  on
the  ripe-draft-hints-v1.txt,  circulate  the document to the wg list and
publish as a ripe document.  It was confirmed that Bob Day was  extremely
busy  and that the action should be taken off him.  NCC to take up action
and find replacement

Action: 15.7 Marten Terpstra  Fold  in  comments  and  republish  amended
ripe-72
                                 - 30 -


Action: 15.10  Daniel  Karrenberg  To  propose  new  tags  "created"  and
"assigned" to the database working group for consideration.

Action: 15.17 Glenn Kowack and Tony Bates Write a top level  introduction
for the user as an add-on to the GISS paper once it has been written.

Action: 15.19 Peter Lothberg To draft document on Inter-AS local informa-
tion.

Action: 15.21 Daniel Karrenberg To draft document on colouring.

Action: 16.1 Bernhard Stockman To define scope and work plan for the  new
RIPE working group

Action: 16.2 Daniel Karrenberg/Duncan Rogerson To draft policy  on  proxy
network entries

Action: 16.3 NCC To publish a list of Internet Registries - draft list to
be circulated on the local-ir list.

Action: 16.4 NCC To add to the new RIPE NCC Activity  Plan  -  publishing
and maintaining a list of local IRs :

Action: 16.5 Juliana Tamorri FAQ on CIDR and subnetting.

Action: 16.6 Daniel Karrenberg Why return unused IP address space and  be
a good network citizen.

Action: 16.7 NCC To offer to serve as temporary registrar for  top  level
domains in Europe.  Contact IANA.

Action: 16.8 NCC Put together a consolidated distribution of the  new  DB
software, including a separate syntax checker for objects.

Action: 16.9 Wilfried Woeber Start discussion on the DB mailing  list  on
new  tools needed, e.g.  template generator, syntax checker daemon at the
NCC.

Action: 16.10 NCC Make the error reports form the DB  syntax  check  pub-
licly available.

Action: 16.11 NCC Implement changes to DB  procedures  according  to  the
proposal  "Authorization  and  Notification of Changes in the RIPE-DB" by
Daniel Karrenberg.

Action: 16.12 NCC Implement changes to  DB  procedures  for  the  guarded
attributes according to the agreement.

Action: 16.13 Wilfried Woeber and NCC Produce documentation about  "Back-
ground,  History  and  Object  Definitions" for the new database software
before the end of 1993.

Action: 16.14 NCC Produce "Software Documentation" for the  new  database
software asap.
                                 - 31 -


Action: 16.15 NCC To approach the InterNIC to agree on the use of a  sub-
range of the global NIC-Handle space for RIPE usage.

Action: 16.16 Henk Steenman and  NCC  (Tony  Bates)  Implement  the  dom-
prefix: object for CLNS routing, after tightening the syntax defini- tion
and semantics of the CLNS-address hexadecimal string.

Action: 16.17 Jean-Michel Jouanigot To  coordinate  the  transition  from
ripe-60 to ripe-81 format for routing description.

Action: 16.18 NCC Try to actually get the synchronisation of the  various
databases going, using the recently agreed DB Exchange Format.

Action: 16.19 NCC Start discussion on the mailing  list  by  providing  a
first proposal how the functionality of the badly defined connect: attri-
bute could be replaced (with the target group of the end-user  in  mind!)
by using e.g.  community: and other forthcoming tools from the PRIDE pro-
ject.

Action: 16.20 Milan Sterba Produce a revised version  of  CDS  guidelines
and submit it as a RIPE draft.

Action: 16.21 Milan Sterba, Anne  Lord  Produce  the  umbrella  hypertext
document for the CDS.

Action: 16.22 Milan Sterba Solicit first contributions to the CDS.

Action: 16.23 NCC Create the cds-editor@localhost alias and establish pro-
cedures to integrate new CDS contributions and maps to the CDS.

Action: 16.23  Jean-Michel  Jouanigot  coordinate  this  conversion  from
ripe-60 -> ripe-81.

Action: 16.24 Rob Blokzijl To finalise the RIPE NCC Review  draft  report
and  document and  send the report to the ripe-list for approval.

Action: 16.25 Rob Blokzijl Comments received will be incorporated into  a
first  draft  and circulated to the ripe-list for further comments. Dead-
line: next RIPE meeting in January 1994.

Action: 16.26 Rob Blokzijl Draft document  with  suggestions  on  how  to
reorganise RIPE meetings.  Circulate to the RIPE list for discussion.