DRAFT minutes of the 18th RIPE Meeting
-
From: Anne Lord <>
-
Date: Thu, 09 Jun 1994 15:15:38 +0200
Dear All,
Below are the draft ASCII minutes of the 18th RIPE meeting held
in Amsterdam, May 16-18. Both ASCII and PostScript versions of
the minutes can be retrieved from the document store:
o ftp:ftp.ripe.net:ripe/minutes/ripe-m-18.{ps,txt}
*Many* thanks to everyone who contributed text.
As usual, comments and queries are welcome and should be sent to me.
Anne
-------------------------------------------------------------
DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT DRAFT
ripe-m-18
18th RIPE meeting
Minutes
Anne Lord
Amsterdam, The Netherlands
May 16-18th, 1994
- 2 -
AGENDA
AGENDA
1. Opening
2. Minutes RIPE 17th meeting
3. Actions RIPE 17th meeting
4. RIPE NCC Report
5. Joint Projects - Status and Progress
6. The Merit Routing Registry
7. RIPE: Restructuring the Organisation
8. RIPE NCC - Finance and Management
9. Report - RARE ATM WG
10. Reports from the working groups
11. Next RIPE meetings
12. AOB
13. Closing
APPENDICES
Appendix 1: List of Participants
Appendix 2: Open Action Items
- 3 -
1. Opening
1.1. Welcome
Rob Blokzijl welcomed the participants to the 18th RIPE meeting hosted by
NIKHEF and held at WCW, Amsterdam, The Netherlands.
1.2. Approval of the agenda
The agenda was approved. Note: some of the agenda items were rescheduled
during the meeting but they are minuted as originally scheduled.
1.3. Papers tabled:
Papers
- Agenda for the 18th RIPE meeting
- Working Group Agendas - one document
- RIPE NCC Management Structure
- RIPE NCC Financial Contributions
- Representation of Complex Routing Policies of an Autonomous System
- Representation of IP Routing Policies in the RIPE Routing Registry
(RIPE 81++) DRAFT
- Report on the RARE ATM Task Force
- Support for Classless Internet Addresses in the RIPE database - DRAFT
- RIPE Database Template for Networks and Persons - DRAFT
- RIPE NCC Annual Report 1993
- Personnel Paper advertising new NCC position
2. Minutes of the last meeting.
The minutes from the 17th RIPE meeting were approved with no changes.
3. Review of the action list of the last meeting
The action items from the 17th RIPE meeting minutes were reviewed. The
following list comprises the ongoing action items only. All other action
items were closed.
Action: 15.10 Daniel Karrenberg To propose new tags "created" and
"assigned" to the database working group for consideration - pending.
- 4 -
Action: 16.6 Daniel Karrenberg Why return unused IP address space and be
a good network citizen. Daniel to find volunteer to continue the work.
Action: 16.18 NCC Try to actually get the synchronisation of the various
database going, using the recently agreed DB Exchange Format. Action is
dependant on the NIC handle - pending.
Action: 17.1 Glenn Kowack Volunteered to write a paper for discussion
which would focus on a funding model for the RIPE NCC.
Action: 17.7 Wilfried Woeber, NCC To produce the necessary documentation
for the new DB software.
Action:17.8 NCC To update and re-circulate the RIPE-Handle proposal and
then go ahead with the implementation - pending.
Action:17.11 NCC Investigate and propose a syntax-checking facility for
the new database software.
Action:17.15 NCC Propose and implement a mechanism to properly keep track
of individual updates of objects and automatic merge/modification opera-
tions.
Action:17.17 Bernhard Stockman Draft a new version of the EEPG Terms of
Reference and distribute this on the mailing list ASAP.
Action:17.18 Bernhard Stockman Draft a new version of the EEPG Workplan
and distribute this on the EEPG mailing list ASAP.
Action:17.20 Oleg Tabarovsky To collect data on external lines and res-
trictions applying to each line that will form part of the Russian back-
bone. Send details to oleg@localhost.
Action:17.25 NCC, Juliana Tamorri To make FAQ on CIDR by Juliana avail-
able in the RIPE document store.
4. RIPE NCC Report
Daniel Karrenberg presented the NCC Report. The report focused on the
personnel shortage at the RIPE NCC. Statistics showing the increase in
the number of Internet hosts in Europe were presented as well as statis-
tics relating to the growth of the Internet Registry function. Whilst the
growth rate over the last two years for all the statistics presented had
increased - indicating therefore a much higher workload for the RIPE NCC
staff - there had been no increase in the NCC Core Staffing level at all
since the inception of the RIPE NCC. This clearly illustrated the need
for more staff to work on the "Core" activities at the RIPE NCC. One
such administrative position has been approved and the job announcement
was distributed as a paper at the meeting. One further technical
engineer position is sought for the Autumn, but this position has not yet
formally been approved. Copies of the presentation slides can be found
in the RIPE document store in the presentations directory, file:
o ftp:ftp.ripe.net:ripe/presentations/ripe-m18-dfk-NCC-REPORT.ps
- 5 -
5. Joint Projects - Status and Progress
Daniel Karrenberg gave an update report on the status and progress of the
PRIDE project. Since the last RIPE meeting the following progress can be
reported:
o many of the PRIDE tools have been improved
o a draft PRIDE guide has been written
o the PRIDE course has been announced to take place end of May (and is
fully booked).
o ripe-81 extended the Routing Registry at MERIT.
o In general, the PRIDE project is behind schedule because of CIDR.
o Much of the PRIDE effort has been on ripe-81++
The plans for PRIDE in the coming months are to:
o announce more courses
o release the PRIDE guide
o adapt the tools to ripe-81++ specifications
o develop more tools (prconfig)
o extend the project for 2 month period (budget neutral)
o propose a follow on (simulation, more tools)
Copies of this presentation can be found in the RIPE document store,
file:
o ftp:ftp.ripe.net:ripe/presentations/ripe-m18-dfk-PRIDE.ps
6. The MERIT Routing Registry Elise Gerich introduced the background to
the NSFnet Backbone Policy Routing Database (PRDB). The PRDB was devised
to stabilise routing for the NSF regionals and has been in place for 6
years. There are some 93 routers and 72 ASes peered with. However the
end of the NSFnet backbone is scheduled for November 94 (1st transition
phase) and April 95 (a second transition phase). The new NSFnet program
incorporates:
o VBNS (Very High Speed Backbone). The proposed awardee of this
backbone is MCI but the award has been contested by SPRINT.
o NAPs (Network Access Points). The proposed awardees are AMERITECH
(Chicago); MFS Datanet (Washington DC); Pacific Bell (San Francisco);
SPRINT (NYC). The NAPS will no longer maintain an acceptable use policy.
o RA (Routing Arbiter). The proposed awardee is ISI (California) and MERIT.
Responsibilities of the RA:
o maintain the route servers at NAP
o provide a routing registry service
o routing engineering (Merit Routing Registry). ISI are developing the
route server.
Transition plans:
- 6 -
o PRDB -> Merit Routing Registry
o 93 Routers -> It is not known yet who the VBNS will be managed by
o 72 ASes -> NSP's at NAPs (will be fewer)
The transition started on May 1st, 1994 and is scheduled to be completed
by April 1995.
What is the MERIT Routing Registry?
o Ported RIPE DB software
o Added support for aggregates
o Added support for network lists
o Proposed new optional attributes
o Collaboration with RIPE NCC on design of Distributed Registry Architecture
o New attributes added.
Status of the MERIT Routing Registry
o MERIT Routing Registry has 4 ASes registered: AS690, AS233, AS237 and AS1133.
o Routing Policy Server (ALC) beta version is available.
o New tools:
astrace - next generation prtraceroute - beta v. available
aggrwalk - lists aggregates
netlist - generation of network lists in alpha text.
If you would like more information,
o ftp:ftp:rrdb.merit.edu/meritrr
o or send mail to rradmin@localhost
There was one question from Tony Bates questioning the planned scope of
the routing arbiter. The answer was that it would not be limited by the
NSF funding body, therefore any network could be registered.
7. RIPE: Restructuring the Organisation
Rob Blokzijl introduced the BOF on "RIPE Restructuring" that would be
held on the last day of the meeting. Prior to the meeting, a mailing
list was set up and announced (apologies for the lateness of this) and
several RIPE participants had already contributed to the discussions. The
BOF held at this meeting progressed the discussions already held. A
report of the discussions that took place at the BOF can be found under
item 10. "Reports from the Working Groups". A draft document is
scheduled for the next RIPE meeting, and a final document by the January
1995 meeting. Everyone is encouraged to particpate in the discussions.
To do so you need to subscribe to the mailing list.
Send mail to:
majordomo@localhost
body text: subscribe new-ripe@localhost [your email address]
- 7 -
8. RIPE NCC - Finance and Management
Rob Blokzijl described the current arrangement for the funding of the
RIPE NCC and introduced an arrangement for the funding of the RIPE NCC of
the future as proposed by RARE. The current situation is that RARE
members contribute a major part of the income of the RIPE NCC. Further
income is contributed by the service providers. The "underwriting" of
the NCC operations has been undertaken by RARE since the beginning of the
RIPE NCC. This arrangement has worked successfully and will continue in
the future. Tomaz Kalin assured the audience that the RARE Executive
would recommend this and that it would be agreed at the RARE CoA meeting
on Friday 18th May. However, the RARE Executive has also proposed that a
more diirect management of the RIPE NCC by RARE will be necessary if RARE
is to underwrite the naturally increasing financial risks of the RIPE NCC
budget. Kees Neggers commented that it is not just a RARE issue, but
there is a need for financial planning and "professionalism" which RARE
feels qualified to undertake on behalf of the RIPE NCC. The RIPE NCC is
a recognised valued service and a world leader. The financial control
needs improving and restructuring to be consistent with this.
It was observed that if this proposed arrangement was not felt to be
satisfactory, then the underwriting of the RIPE NCC needs to be supported
by more than one organisation or more money needs to come from service
providers. Stephan Biesbroeck commented that it should be more attrac-
tive for non-members to contribute more money to the RIPE NCC budget.
9. Report - RARE ATM Working Group
The RARE ATM Task Force has been set up by RARE WG-LLT in the middle of
1993. At this moment, most European countries are taking part in this
Task Force, which is, in turn, stimulating the international usage of
ATM. This by means of:
o trying to use the European PNO ATM pilot (an ATM test
network installed by some 18 PNO's in Europe);
o sharing experience on hard- and software;
o coordinating international ATM networking;
o coordinating international applications over ATM and
o providing recommendations on ATM- and higher layers.
The applications this Task Force is coordinating at this moment are:
o LAN/WAN interconnection
o Desktop video and audio
o Conference room video-conferencing
In future, Cooperative Working, ATM-multicast, Quality of Service and
Network Management will be covered.
One of the applications (LAN/WAN interconnection) is important in the
area of IP. The Task Force would like to coordinate the work on IP over
ATM in such a way that the operational IP services are not endangered.
Already a few countries have shown their interest: CH, ES, FI, NL, NO and
UK. Other organizations that are interested in taking part, should
- 8 -
contact the chairman of the Task Force: Les Clyne (L.clyne@localhost).
Important documents on IP over ATM are: RFC1483, RFC1577, RFC1293 and the
Internet Draft on MTU sizes. Routing will be covered by the IETF working
group "Routing over Large Clouds". The IETF distribution list on the IP
over ATM subject is: IP-ATM@localhost. The sheets of the presen-
tation can be retrieved from the ftp-server of RIPE:
o ftp:ftp.ripe.net:ripe/presentations/ripe-m18-reijs-atm.ps.Z
10. Reports from the Working Groups
10.1. Local-ir Working Group (D Karrenberg) Chair: Daniel Karrenberg
Scribe: Mike Norris
10.1.1. Opening The agenda as circulated beforehand was agreed. The
minutes of the meeting held during RIPE-17 in January 1994 were agreed.
10.1.2. Election of New Chairman Daniel Karrenberg explained why he had
announced his resignation as chairman. The efficacy of the WG might be
questioned given that the manager of the NCC presided over a group drawn
from the membership of RIPE, which set the agenda of the NCC. In addi-
tion, the workload of the NCC was now so onerous that all other activi-
ties had to be reviewed. Following discussion, the meeting unanimously
expressed its complete satisfaction in the chairmanship by Daniel of the
Local IR Working Group. The Group had found the close linkage with the
NCC to be of great benefit, and that this had never impeded its work nor
imposed any limitations on its freedom of action. The meeting reluc-
tantly accepted the resignation of the chairman. Mike Norris agreed to
act as chairman, with effect from the end of the meeting.
10.1.3. European Registry Report by the NCC Daniel Karrenberg reported
that, from experience, it may be that enterprise networks, such as those
belonging to large multi- or trans-national organisations, needed their
own IP registries. As a rule, such organisations did not get delegated
address space. However, coordination between local and regional regis-
tries was important.
10.1.4. Reports of Significant Events at Local Registries Question: In
light of renumbering caused by CIDR, what should be done with returned
addresses? It was agreed that such addresses could be returned, and wel-
come, to any European IR. Such IRs would return addresses to the NCC.
If the addresses could be aggregated, they would be re-used, otherwise
they would be returned to IANA.
Question: Will someone write a paper on why it is a good idea to return
unused addresses? Some discussion took place, but there were no takers.
It was agreed that incidents of note should be reported to the list and
to the NCC, and not reported only at WG meetings. Incidents were
reported of applications being rejected in Europe but accepted on re-
application to other regional registries. The group expressed concern at
the disparity in the criteria applied by RIPE and InterNIC registries.
Action:18.1 Daniel Karrenberg Convey RIPE's concern at the disparity in
criteria with respect to IP network number applications to the InterNIC.
- 9 -
10.1.5. Standard IP Application Form There was a discussion of multiple
applications to different registries by the same organisation, or by dif-
ferent components of the same organisation. It was agreed that the stan-
dard form should be revised to guard against such abuses. The following
changes should be made:
o Indicate that any statements made in the form could be used
in consideration of future applications
o Applicants should indicate their parent organisation and its
assigned address space, if any
o Applicants to state whether they had made any applications for
IP addresses in Europe or elsewhere and also to indicate whether
they had requests turned down in the past.
Action: 18.2 NCC Draft new standard European Internet Network Number
Application Form (formerly ripe-107) in light of recommendations from the
working group.
10.1.6. Default Range of AS Numbers D Karrenberg had asked IANA for a
default range of AS numbers, but this had been refused. The previous
request to take advantage of reserved networks and AS numbers had been
partly honoured by the recently published RFC 1597 which allows
10.0.0.0/24, 172.16.0.0/20 192.168.0.0/16 to be used by networks that, by
design, do not want to be connected to the Internet.
John Postel of IANA had rejected the request by RIPE that AS numbers
65530 through 65535 be reserved for similar uses (e.g. a corporate
unconnected network consisting of many ASs), as when an AS number is
required but not used (as in EGP, see overuse by RENATER with over 400
ASs allocated though never used). The reasons for refusal were:
o the resource is not close to exhaustion (about 3000 ASs
being currently allocated out of a total of 65535);
o a robust argument was still required.
On the latter point, Daniel asked the audience for volunteers to write
trhis up as a paper (he would give assistance with the writing. No
volunteers came forward.
10.1.7. Report from Local IR Workshop The workshop held before the start
of RIPE-18 was well attended, the numbers exceeding those who had booked
and the number of lunch equivalents.
RFC 1597, concerning the allocation of private IP addresses, was noted.
The use of the RIPE NCC developed stt tool was presented and anyone
interested in using this tool locally was encouraged as welcome to do so.
The presentation can be retrieved from the RIPE document store:
o ftp:ftp.ripe.net:ripe/presentations/ripe-m18-dfk-stt.ps
Common errors with the administration of reverse DNS zones were summar-
ised. Geert Jan de Groot gave a short presentation explaining some of
- 10 -
these errors. A copy of his presentation can be retrieved from
o ftp:ftp.ripe.net:ripe/presentations/
file : ripe-m18-geertjan-COMM-INADDRARPA-PROB.ps.Z
Action: 18.3 NCC Investigate monthly publication of error files on
reverse zone files, similar to the host count error files.
10.1.8. Funding of and Charging for Local Registry Service The meeting
agreed that these were important issues and that the group should make
recommendations as soon as possible.
Action: 18.4 Mike Norris Initiate discussion w.r.t the funding and charg-
ing for the service of a Local IR on the Local-IR discussion list and
aim to summarise the discussions by way of a draft recommendation.
10.1.9. Assignment Statistics W Woeber and Willi Huber had suggested
means of representing address space assignment status. This would be dis-
cussed on the list. 10.2. Database working group (Wilfried Woeber)
Chair: Wilfried Woeber
Due to the importance and the length of discussions regarding the ripe-
81++ proposal, the DB-WG had to meet once again in parallel with the
routing group. Attendance was *very* small this time and the group did
not feel to represent quorum. Thus no formal decisions of greater
relevance were taken this time. The items treated worth noting for the
minutes are as follows:
10.2.1. the "class-less database" The NCC is going to implement the
classless indexing stuff for the database software. This is first prior-
ity and is not directly affected by any decisions about external
representations of address ranges.
10.2.2. Removal of retired attributes These attributes are scheduled to
disappear when the changes are implemented that split the current network
object into the "new" inetnum: and the "route:" object. The functions
currently provided by "connect: LOCAL" can be provided by "comm-list:"
and "component:" attributes.
10.2.3. Review of the expected guardian procedure for the "route:" object
When discussing the guardian procedure for the "route:" object there was
some concern that the registering of route objects could become out of
synch with the up-load of the guardian files. One of the possible solu-
tions proposed would cause registrations to become re-queued for evalua-
tion after the next scheduled guardian update. This is for further study
and discussion.
10.2.4. National characters in database objects There was a common feel-
ing that - given what we aim for with the database - the use of national
special characters in database objects is not useful. It is thus
strongly discouraged. However, objects currently registered will be kept
and this recommendation shall not be enforced.
- 11 -
10.2.5. Shortage of personnel resources at the NCC Again there was con-
cern that many necessary activities cannot be pursued due to the shortage
of personnel at the NCC (e.g. RIPE-Handles, RWhois,etc.). A.B.Bonito
proposed to get external help for the NCC to work on well-defined short-
term projects. It is expected that this help could and should be pro-
vided by staff from the individual NICs. 10.3. Connectivity (Milan
Sterba) Chair: Milan Sterba Scribe: Elise Gerich
10.3.1. Central and Eastern Europe - CEENet initiative Wilfried Woeber
presented an introduction to the CEEnet Initiative. This is an effort to
plan for network infrastructure for the Eastern European countries with
government endorsement. Two organizations are involved in planning this
infrastructure: Europanet and EBONE. Wilfried indicated that a map
detailing the proposed structure is available on the ACOnet file server.
10.3.2. Russia and former Soviet Union Ilya Mafter presented a summary of
ISF's activities in Russia and the Ukraine. He indicated that ISF
(International Science Foundation) is a $100 million foundation of which
$5 million is decided to improving the network infrastructure in the
Former Soviet Union to support basic research scientists. The projects
that ISF is currently working on are:
o Moscow - fiber backbone project; no target time for delivery as of yet
o Kiev - local backbone and connectivity to Moscow
o Novosibirsk - project is under development; external satellite links
A new "megaproject" has been initiated which aims at a much larger user
community (education, culture, religious communities etc.) promoting the
creation of a new communication infrastructure for the "open society" at
large. Alexey Platonov (RosNIIROS/RELARN director) drew a map of the
proposed fiber backbone in Moscow and indicated that the project is now
one year old. The status of the backbone project is:
o fiber is in place between M9 and IKI
o fiber is in place between KIAE and IASnet
o termination equipment is still needed
o Russian fiber has been used and there is a need to test single mode FDDI cards
o a management plan is still under discussion
Platonov stated that the Moscow backbone would establish a MIX (Moscow
Internet Exchange) for network service providers and that there is
already connectivity between the MIX and St. Petersburg at 2Mb. The
connectivity between Moscow and St. Petersburg is operated by Relcom.
Dimitry Burkov (Relcom R&D director) elaborated on the drawing of Plato-
nov. He described a T1 microwave between KIAE and M9; E1 fiber between
KIAE and DEMOS; 64K between DEMOS and Ostankino Tower; and a 64K satel-
lite link to New York. The 64K to New York is in the process of being
upgraded to 256K. In addition, from M9, there is an E1 microwave to St.
Petersburg (not sure about where the E1 terminates), and then 256K ter-
restrial link to Helsinki (FUnet -EUnet). This provides Relcom in
partnership with DEMOS connectivity to Europe and the United States.
- 12 -
Currently Relcom and Demos are in partnership on a new project to provide
Japan, Russia, US connectivity. In addition, there is a 64K link between
KIAE and ROSSprint with an agreement for mutual backup between Relcom and
Sprint.
Dimitry Avdyev (Moscow State University/DESY) presented the Radio-MSU
activity which is based on microwave connectivity within Moscow and a
satellite link to Hamburg, Germany. There is a 3.5m dish in Hamburg and
a 4.8m dish in Moscow (Russian equipment), and Radio-MSU has a license to
operate Russian equipment in Germany. They are in the process of upgrad-
ing to a bigger dish in Germany, and plan to the upgrade the satellite
capacity from 256k to 512K in September'94. Then in summer of 1995 the
plan is to upgrade to 1M. Dimitry agreed to provide postscript versions
of his slides.
Sam L. Musher (Novosibirsk - Academgorodok Internet Project) presented a
picture of a star topology within Academgorodok with the centre of the
star at COMCEN. From COMCEN there is high speed connectivity to INP,
IAE, NSU, and Chemistry. The project proposes to install a 256K satel-
lite link to Finland from INP. Currently the only connectivity from
Academgorodok to Moscow is:
o 4 leased lines at 14.4 to M9
o an ISKRA line to ITEP
o a 19.2 line to SOVAM teleport running IP over X.25 The current
access to the Internet is too slow to permit interactive connections.
E-mail is the extent of their connectivity.
The Academgorodok Internet Project plans two external connections: one to
Radio-MSU and the MIX, and the second to the Northern Part of Finland
(with connectivity to FUNET and KTH). Academgorodok hopes to fund this
project with contributions from ISF, DOE and the Russian Academy of Sci-
ence.
Misha Popov (Dubna) announced for the fourth year a 56k line from Dubna
to GARR (Italy - Gran Sasso). (During the meeting itself and recently
there have been connectivity problems - but the situation is now
improved: all (98%) traffic is vai the GARR gateweay: ~2% at low speed
link to Relcom; ~0% at Dubna-Potsdam 64K link.
10.3.3. Albania Milan Sterba made a short report on activity to Albania.
Greece (FORTH) works on email connectivity to Institute of Informatics,
Tirana. In CNUCE - Italy there is an activity to set up an IP link to
Tirana University.
10.3.4. RIPE Connectivity Document Store Milan Sterba reported on the
status of the RIPE CDS (Connectivity Document Store) which is now used as
the main RIPE vehicle to publish information about connected networks in
Europe. Because publishing information in the CDS means utilisation of
RIPE NCC resources the CDS apply the policy of only publishing informa-
tion about networks which contribute to the RIPE NCC budget. It has been
stated that all known Eastern and Central European networks fill this
criterion.
- 13 -
Eleven networks have answered the call for CDS fact-sheets up to now:
o DANTE - Europanet
o Unicom - B
o Belnet
o CESnet
o SANET
o HEAnet
o NASK
o EUnet (BG,CZ,FR,SK)
All others are encouraged to submit Fact Sheets for inclusion in the CDS.
The CDS is currently accessible over WWW, gopher, ftp and e-mail. (for
further information see http://www.ripe.net/ripe/cds.html).
The CDS fact-sheet layout described in:
ftp:ftp.ripe.net:ripe/drafts/connectivity-report-plan.txt will be pro-
moted to a regular ripe document.
Action Items Action: 18.5 Wilfried Woeber Post the CEEnet Initiative
maps to the RIPE FTP server.
Action: 18.6 NCC Set-up a mailing list for the connectivity WG. 10.4.
Routing (Jean-Michel Jouanigot) Chair:Jean-Michel Jouanigot Scribe:Gilles
Farrache
10.4.1. Previous minutes, agenda. The previous minutes were approved.
Gilles Farrache (volunteered?) as a scribe.
10.4.2. CIDR deployment status CIDR development is progressing well. All
the organizations that participated in this effort should be thanked and
the networks that did not yet convert to CIDR should do it as soon as
possible.
Tony Bates presented a few graphs on the evolution of the number of
routes and paths in the Internet. The slides (and other useful data) are
available from
oftp.ripe.net:/cidr
Computations are made on an AS basis to estimate the routing table reduc-
tion if these ASes convert to CIDR. Everyone was encouraged to study
these data.
We can observe a quite significant decrease of the number of routes
(20400 down to 18400) and paths (53000 down to 50000), but this is prob-
ably not going to last very long.
Regular messages are sent by the Ripe NCC and list the first 10 Auto-
nomous systems Internet wide that would really save a significant amount
of routes if they convert to CIDR. If your AS is listed in there, you
should definitely do something!
- 14 -
With the recent development of CIDR in the Internet, the current model
for policy based routing has to be reviewed, since aggregates are not
taken into account. Two proposals have been made: one from Tony Bates,
Marten Terpstra and Daniel Karrenberg (RIPE NCC) and another one from
Laurent Joncheray and Elise Gerich (Merit). Both proposals were
presented first (see below), and then a general discussion took place
with the aim to come to a general proposal to be used by both the RIPE
and Merit RRs.
10.4.3. Ripe-81 ++ and related documents Marten Terpstra presented a pro-
posal for representing classless addresses in the database. For more
details, please read the draft document 'ripe-clarep' available from
ftp.ripe.net.
Examples:
o classful address: 193.48.80.0
o classful range: 193.48.80.0 - 193.48.85.0
o prefix/length: 193.48.80.0/24 193.48.80.0/20
o classless range: 191.1.1.0 > 192.1.1.255
Does not need to be aligned on a bit boundary. Tony Bates then presented
the enhanced version of Ripe-81 called Ripe-81++. This proposal intro-
duces new concepts:
o the allocation registry and the routing registry are now separate.
The current 'inetnum' object is split into two new objects: a new
obsolete information have been removed.
o in the route object, the aut-sys tag is replaced by an 'origin' tag
which indicates the AS number which injects this route in the Internet.
The route is obviously classless, with a prefix/length representation.
o There is no major modification on the routing policy description
except that AS-MACROS and COMMUNITIES can now be used, and an
Transition issues:
o The database software should be modified (classless indexing)
and the various tools should understand both the old and the
new structure.
o The new objects should be supported by the end of the summer,
and all the routing information moved to the new 'route' object
by the end of fall.
Open issues:
o The PRIDE tools have to be modified, and the exchange of routing
information with other routing databases should be possible.
For more information, please read ripe-81++, available from:
o ftp:ftp.ripe.net:ro[e/draft/ripe-81++.{txt,ps}
- 15 -
10.4.4. Extensions proposed by Merit. Laurent Joncheray presented the
work currently being done at Merit. The RIPE database software was used
and modified to support classless addresses, but:
o It should be possible to distribute the database (by design)
o New extensions are needed to implement all the policies.
ALC is a new routing server developed by Merit. It makes the tools data-
base syntax independent (ASCII protocol between client and server, the
server computes the answers), and allows several ALC servers to exchange
information.
An ALC server is already running at Merit, and gets information from
three databases (Ripe, Prdb and NSFnet db). It is proposed to run such a
server at the Ripe NCC and connect the two servers; a natural extension
would then be to add more ALC servers to the system.
The current Ripe-81 syntax has been extended:
o keywords have been added (from, accept,...) to make the policy
descriptions more readable
o list of networks are allowed
o proposes a solution to represent serveral connections between
two ASes (using router addresses)
o possibility to use a database selector
o optional metric in as-out
o static routing support
o as-default extension (default route generation)
o new 'as-exclude' tag
o new 'as-transit' tag
Some questions were raised concerning the distribution of the database
and how some sort of security can be implemented. This point is for
further study.
10.4.5. Discussions, conclusions A long discussion took place to compare
the two proposals and try to merge them. These minutes do not reflect
each and every point discussed, but will report on the conclusions
reached. The Reader is asked to consult Ripe-81++ and Merit's proposal
for details.
Ripe-81++ will integrate the following extensions:
A. Network lists are accepted wherever a community can be used with the
following syntax:
o {36.0.0.0/8, 191.1.0.0/16}
B. The 'default' tag will now allow an optional field explaining how the
default route is derived. The Merit 'as-default' tag extension is
accepted, but will be called 'default'.
- 16 -
C. The need for a way to express 'local' policies when two ASes are con-
nected through several links is agreed. There's still no agreement on
the final syntax, except that this information should not be in the to
the as-in and as-out attributes which describe the overal policy of the
AS while they describe local policy between the AS and (some of) its
direct neighbours. If the 'interas-in' or 'interas-out' tags are
present, then there should be a mechanism to generate the corresponding
information) to guarantee the integrity of the 'route' object. This
should be done (on request, using a special keyword) by the software when
registering the object.
D. The Merit syntax introduces keywords like accept, from,... It is
agreed that this should be accepted when registering the objects, and
that these keywords should be present when a query is performed "in ver-
bose mode". Queries in "non verbose mode" is still possible. All key-
words are in lower-class and a list of allowed keywords will be provided.
Action: 18.7 Elise Gerich To supply a list of keywords allowed that can
be used when querying the database.
E. The Merit syntax also proposes a way to "compress" the information
like: o as-in: from AS690:1, AS701:2 accept AS237
This new syntax is not accepted because there was consensus that the
additional functionality does not warrant the extra complexity in the
descriptions. Many of those present expressed that they prefer a uniform
description because it makes reading other people's policies easier.
F. Network numbers representation: It is agreed that the prefix/length
syntax is the only representation accepted. Network numbers should con-
tain 3 dots: 35.0.0.0/8
G. The classless range notation for the 'inetnum' object is not to be
discussed in this group but in the database group. The 'route' object
only accepts what is agreed on point F.
H. Optional as-out metric: this information has to be evaluated in the
same way by the various neighbours, and is the only information of the
proposal is rejected.
I. Static route support: Everybody agreed on the principle: static rout-
ing should be represented in the database. A metric should be associated
with a static route, and this metric should be relative to the 'as-in'
metric.
J. Ripe-81++ component tag in the route object: This tag is optional, and
a better definition of the 'component' tag is needed, as well as a review
of the definition of a 'HOLE'. In case of proxy-aggregate, Ripe-81++
should indicate that the listing of the components is mandatory. In case
an aggregate is performed with as-set, and that all the networks aggre-
gated are announced by the same AS, then this AS should appear as origin
in the 'route' object. There's still a pending issue concerning the com-
munity list usage in the component tag: this needs to be better defined
and how will this be guarded?
- 17 -
K. The key in the Ripe database used to be the network number. It will
become 'route/origin'. Several route objects with the same 'route'
fields but different 'origin' fields are accepted.
L. Even though host routes could perfectly be represented in the new
database, it is strongly discouraged (ripe-81++ page 56).
M. Line splitting: the notation is accepted
o as-in: AS1234 100 (AS-EBONE
o as-in: AS1234 100 AS1234) AND NOT AS2345
N. as-reject and as-exclude: It is decided to rename as-reject in ripe-
81++ into as-exclude (proposed from Merit). The keyword 'exclude' will
be a reserve keyword.
O. 'as-transit' is included in Ripe-81++, but for experimental purposes.
It was agreed that experimental additions should be moved a separate
document which summarizes all experimental attributes and a pointer to
this mechanism should be put into ripe-81++. The additions document
should comprise all experimental additions being used a the time.
P. The database selector (Merit's proposal) needs to be better specified.
In conclusions, there was a general consensus on most of the extensions
and it is proposed to include all of these in the new version of the
Ripe-81++ draft. This draft will be sent to the RIPE list for comments
within two weeks, a final version being released in six weeks (June
28th).
Action: 18.8 NCC Fold in comments from routing-wg to the ripe-81++ draft,
send to the RIPE list and release final verison - June 28th, 1994.
10.4.6. Closing, AOB The action on Jean-Michel Jouanigot to coordinate
the migration from ripe-60 to ripe-81 is almost complete. Only three
'bdry-gw' are still present in the RIPE database: DESY, ACONET and INFN.
The action is to be changed into 3 separate actions on these sites:
Action: 18.9 Christina Vistoli, Ewald Jenisch and and MIchael Ernst (or
Hans Frese) To convert from ripe-60 to ripe-81 (or Hans Frese) before
July 1st, 1994.
[At the time of writing, ACONET bdry-gw seems to have been removed]
10.5. DNS Working Group (Francis Dupont) Chair: Francis Dupont Scribe:
Andreas Knocke
10.5.1. Opening An agenda circulated beforehand was agreed. The minutes
of the meeting held during RIPE-17 in January 1994 were agreed upon.
10.5.2. Workplan and Charter of the Group The question of folding down
this working group was discussed. It was stated by R Volk that the wide
usage of the BIND implementations in Europe and the global development
plans for new versions of BIND no longer require a standing working
group. For these reasons (no technical development) the IETF DNS working
group was finished at the last IEFT meeting. The working group is still
- 18 -
useful for help and/or pressure then it should be kept but that a meeting
will be held at the next RIPE meeting only if an agenda requires.
10.5.3. BIND status The current status given by F Dupont [as quoted from
his email to the dns-wg] was:
o the last experimental release is BIND 4.9.3 alpha4 (join the mailing
list bind-workers@localhost if you want to use/debug it). [there is a
new op-guide, if interested you should read it]
o the last official release is BIND 4.9.2 and final distribution can be
found in gatekeeper.dec.com:[~ftp/]pub/misc/vixie/4.9.2-940221.tar.{Z,gz}
and on several anonymous FTP servers.
o known problems are negative caching and validating then switch OFF the
options NCACHE and VALIDATE. Another problem is resolver library
security with SunOS, use the SUNSECURITY switch.
o SIPP support has been done by Susan Thomson set@localhost
and can be found in :
thumper.bellcore.com:[~ftp/]pub/pip/code/dns/feb94.tar.Z
o NSAP support has been done by Paul Traina pst@localhost and can
be found in ftp.cisco.com:[~ftp/]bind/4.9.2-beta5-nsap-diffs
NSAP support for nslookup (i.e. easy way to find PTR for NSAP addresses)
has been done by Richard Colella colella@localhost and is in
osi.ncsl.nist.gov:[~ftp/]pub/ncsa_tuba/nslook_rev_nsap.tar
(note: the reverse map root is nsap.int)
10.5.4. DNS security This is done by an IETF WG, with RSA digital signa-
tures as a possibility which has to be implemented in an exportable
fashion to make it available outside the United States of America.
10.5.5. Review of the Domain object Some attributes (zone-c, nserver,
sub-dom) of the domain object were mandatory but had no meaning for some
domains (for instance a MX only domain is not a zone then has no zone
contact). So the domain object should be updated (or removed), defini-
tions and status (mandatory or optional) of attibutes should be refined.
The registration of domains for different top level domains (TLDs) vary a
lot in range and it was asked if the domain should be kept in the RIPE
database or whether it would be better if this information was stored in
the DNS (TXT RRs for the attributes). The need for high availability of
addresses and phone numbers in case of misconfiguration makes it desir-
able to have it in the RIPE data base for all the subdomains of the
national structure,i.e. first level subdomains for flat TLDs and the
subdomains of co, ac,.. for TLDs following this model. The necessary
information for these domains as seen by the Registrar for the domains
SHOULD be mirrored in the RIPE data base.
Some changes to the domain object were discussed:
- 19 -
o putting the zone-c as another tech-c, she/he can be identified from
the SOA-RR, don't make zone-c a mandatory attribute
o make nserver optional, eventually marking it as obsolete for future
releases of the domain object because this is already stored in the
DNS tree in a probably more up to date fashion
o this means rev-srv for the in-addr.arpa domain entries shall be
regarded the same way, make it optional - it maybe obsoleted in due course.
o sub-dom should also only be optional
Action: 18.10 Francis Dupont Circulate a proposed new domain object with
the list of attributes necessary, marking others optional, maybe obsolete
them in the future. Update to RIPE-049.
10.5.6. Discussion about the document of A Romao The document "Taking
Care of your Domain" was welcomed by the participants and it was agreed
to put it in the RIPE document store and to propose it as an informa-
tional RFC. The participants want to thank him for his work and ask for
further input from 'old hands'.
Action: 18.11 NCC Put A. Romao's paper "Taking Care of your Domain" into
the RIPE document store as a RIPE document. 10.6. MBONE Working Group
(Erik-Jan Bos) Chair: Erik-jan Scribe: Michael Behringer
Mailing lists: o Europe: mbone-eu@localhost o Global: mbone@localhost
10.6.1. Agenda The agenda was presented, and agreed by the participants.
10.6.2. Workplan Currently there is no WG for Mbone under the auspices of
RIPE. EJB proposed that such a WG should be set up, which was agreed
generally. Next step then is that there is a Terms of Reference and a
Workplan to be agreed. EJB wants to set them up, as well as a Euro-FAQ,
and will send them to the list, for discussion. At the next RIPE meeting
these documents should be agreed then.
Action: 18.12 Erik-Jan Bos Set up Workplan, Terms of Reference and Euro-
FAQ, to be send to the mailing list. Tony Bates said he could help EJB on
the FAQ.
10.6.3. Mbone in Europe Status There are two PS'es available that show
the European Mbone topology: - ftp.nic.surfnet.nl:ftp/surfnet/net-
management/mbone/mbone-eu.ps (EJB picture) -
aun.uninett.no:pub/misc/ipmulti/mbone-eu.ps (picture from Havard) These
pictures represent the current Mbone situation in Europe. Maintenance has
to be done permanently, as the topology probably will face frequent
changes. This is an ongoing action on the authors of the pictures.
There is also a worldwide PS picture on Mbone tunnels available, which
gives on overview about the worldwide situation. EJB asked Havard to
maintain his picture as *the* Mbone picture for Europe.
Action: 18.13 Erik-Jan Bos Send to the mailing list query on where to
find the worldwide PS file (done through these minutes).
10.6.4. Short Term Work items
- 20 -
10.6.4.1. Email lists In some countries there are local fan-out lists are
available. There should be a list for each country, so that local
matters are not to be discussed on international lists.
Action: 18.14 All members of the Mbone WG See if there is a local Mbone
mailing list in your country, if not, create one and add this list to the
European list, so that European information is passed on.
10.6.4.2. Central FTP server There is a central FTP server needed, con-
taining not only the picture of the Mbone topology in Europe, but also
the latest versions of the software.
Action: 18.15 Erik-Jan Bos Start up a central European Mbone FTP server.
10.6.4.3. Discussion on the topological structure Currently there are
Mbone tunnels on the CERN T1, Stockholm line, Paris line. There is no
feed on the Amsterdam E1. Havard mentioned the overload of the Paris E1.
He would also consider it a matter of fairness to Ebone, which was sup-
plying most parts of Europe with Mbone so far, for DANTE providing this
feed now on the Amsterdam E1.
Michael Behringer stated on behalf of DANTE that there is no concern
about having a Mbone feed on the Amsterdam E1 as part of the accounted
traffic of a regional network like e.g. SURFnet. But supplying a feed
as a part of the general service would involve additional overhead costs,
so that this kind of agreement has to be considered carefully, it is how-
ever open for suggestions.
EJB could provide some statistical figures on that. In march 94 the
Amsterdam Mbone server sent 32 Gbyte per tunnel, which makes 100 kbit/s
on average in a month. But if there is a Mbone connection running, it
uses 512 kbit/s permanently.
At the moment some participants have quite high costs for bandwidth con-
sumption, that are not shared at all. Given that Mbone traffic is likely
to rise in the near future, this problem should be addressed soon, as
long as it is not a problem.
The group did neither come to a conclusion on a possible funding model
for Mbone, nor if the financial problem should be discussed at all in
this WG. The comment was made that users are seeing Mbone as a service
already, and are complaining if this service fails. On that the question
was raised if people should consider Mbone as experimental, or if it has
come to a production state already. There was general agreement that
users should be aware that due to non-technical issues the Mbone topology
might change quite rapidly. But the question if Mbone can be considered
a production service could not be answered clearly. Kevin Hoadley stated
on behalf of Janet that a Mbone feed is seen as part of the service
there.
10.6.4.4. INET setup (presentation by John Martin) Current tunnels avail-
able to Prague: NMS.CESNET.CZ (NMS.CVUT.CS) Mrouter on Czech Technical
University Prague Planned for the conference is 1 video, 1 audio stream,
appr. 10 hours on June 14-17th.
- 21 -
INET line setup: 2 Mbit MCI line via London to Washington. 512k line to
EMPB. Tunnels proposed for INET:
o 1 AV Tunnel -> London (principal feed to Mbone)
o 1 AV Tunnel -> Amsterdam (backup feed to Mbone)
o 1 AV Tunnel -> Local (to NMS.CVUT.CS)
The proposal was made to route the EMPB tunnel not via Amsterdam, but
directly to London Tests for this setup are due 7-13th June. John also
presented some pictures on the physical setup of the Prague configura-
tion. These can be obtained via him.
10.6.4.5. Local setups
Regionals are encouraged to store maps of their local Mbone setups. Kevin
Hoadley volunteered to present the JANET setup during the next RIPE meet-
ing.
Action: 18.16 Everyone in the Mbone WG Send in your Mbone maps to Erik-
Jan Bos.
10.7. RIPE Restructuring BOF Report
Rob Blokzijl chaired the BOF session. On the recently announced mailing
list there had been some contributions to the topic. Willem van de
Scheun briefly presented his ideas as sent to the list. This together
with the RIPE Terms of Reference document (ripe-001) was the starting
point for the discussion.
Some discussion took place over the "openness of RIPE" and the overly
academic focus of the organisations represented. Glenn Kowack suggested
there was a need for more aggressive publicity to attract more service
providers and operators to RIPE (especially new and existing commercial
providers who are currently under-represented). Reference was made a UK
"DGix co-ordination meeting" that was planned to attract just the people
that RIPE is lacking. It was suggested by Glenn Kowack that RIPE as an
organisation needs to adapt to the changing infrastructure of the Global
Internet.
There was a further suggestion that the "non-formal" structure of RIPE as
it currently stands is a deterrent for some organisations to become
involved. It was suggested that RIPE needed to take action to become a
legal entity.
In conclusion the BOF session agreed on the following actions:
Action: 18.17 RIPE Chairs Promote a more aggressive "outreach" programme
to introduce and encourage new service providers to join RIPE.
Action: 18.18 RIPE Chairs Continue the RIPE restructuring discussions on
the new-ripe@localhost mailing list focusing on restructuring the techn-
ical work of RIPE.
- 22 -
Action: 18.19 RIPE Chairs Develop a draft model for "new-RIPE" by the
next RIPE meeting in September, with the final report ready by January
meeting in 1995.
11. Next RIPE meetings The scheduling of the next two meetings was dis-
cussed and the following dates and locations were agreed subject to con-
firmation from the local hosts in Portugal for the meeting in September:
o RIPE 19 September 12-14, 1994 - Lisbon, Portugal
o RIPE 20 January 25-27, 1995 - Amsterdam, The Netherlands
o RIPE 21 end April/May 1995. Location to be discussed. Offers have
been received by GARR and by Juergen Rauschenbach for Berlin, Germany.
o RIPE 22 - was not discussed.
12. AOB There was no business reported under this agenda point. 13.
Closing Rob Blokzijl thanked the participants for attending and declared
the 18th RIPE meeting closed.
- 23 -
Appendix 1 - List of Participants
Roman Adamiec NASK coirha@localhost
Dmitry Avdeyev MSU add@localhost
Wiel Backhuijs UNISOURCE info@localhost
Natalia Baranova ISF, Novosibirsk Branch nata@localhost
Tony Bates RIPE tony@localhost
Michael Behringer DANTE M.H.Behringer@localhost
Stephan Biesbroeck BELNET Stephan.Biesbroeck@localhost
Antonio Blasco Bonito GARR CNR blasco@localhost
Rob Blokzijl RIPE Chairman, NIKHEF k13@localhost
Sergey Bredikhin COMCEN, Novosibirsk bred@localhost
Erik-Jan Bos SURFnet Utrecht Erik-Jan.Bos@localhost
Dmitry Burkov EUnet/RELCOM dburk@localhost
Yves Devillers INRIA Yves.Devillers@localhost
Herman van Dompseler NIKHEF a61@localhost
Franics Dupont INRIA Rocquencourt Francis.Dupont@localhost
Havard Eidnes UNINETT Havard.Eidnes@localhost
Stefan Fassbender EASInet GMD stf@localhost
Gilles Farrache IN2P3 farrache@localhost
Elise Gerich NSF MERIT epg@localhost
Geert Jan de Groot RIPE NCC geertj@localhost
Kevin Hoadley JANET kevin@localhost
Nandor Horvath HUNGARnet horvath@localhost
Willi Huber SWITCH ch-zone-contact@localhost
Avgust Jauk ARNES jauk@localhost
Ewald Jenisch Vienna University cc. Ewald.Jenisch@localhost
Laurent Joncheray MERIT lpj@localhost
Phil Jones UKERNA p.jones@localhost
Jean MIchel Jouanigot CERN jimi@localhost
Tomaz Kalin RARE Kalin@localhost
Daniel Karrenberg RIPE NCC Daniel.Karrenberg@localhost
Bettina Kauth DFN-NOC kauth@localhost
Rafal Klauzo RACN (NASK) coirk@localhost
Andreas Knocke DE-NIC knocke@localhost
Rick Kuhlbars netCS rick@localhost
Glenn Kowack EUnet Amsterdam glenn@localhost
Ingrid Ledererova CESNET il@localhost
Anne Lord RIPE NCC anne@localhost
Peter Lothberg EBONE roll@localhost
John Martin RARE martin@localhost
Balazs Martos HUNGARNET BALAZS@localhost
Semen Musher IAE, Novosibirsk musher@localhost
Marmary Nazeman EUnet Germany mn@localhost
Ireneusz Neska NASK irek@localhost
Svend Moeller Nielsen Telebit Communications A/S smn@localhost
Van Ngoc Nguyen France Telecom nguyen@localhost
Arnold Nipper XLINK nipper@localhost
Mike Norris HEAnetr mnorris@localhost
Jos Noteboom Unisource j.noteboom@localhost
Vaclav Novak CESNET NOVAKV@localhost
Petri Ojala EUnet ojala@localhost
Lukasz Ploszajski NASK ukasz@localhost
- 24 -
Alexey Platonov ROSNIROS plat@localhost
Misha Popov JINR popov@localhost
Juergen Rauschenbach DFN ZPL rauschenbach@localhost
Victor Reijs SURFnet Victor.Reijs@localhost
Joyce Reynolds ISI jkrey@localhost
Pavel Rosendorf EUnet Czechia pavel.rosendorf@localhost
Artur Romao RCCN/FCT artur@localhost
Huub Sanders Philips sanders@localhost
Miguel Sanz RedIRIS, Spain miguel.a.sanz@localhost
Willem van der Scheun IBC SARA scheun@localhost
Andreas Schachtner EUnet/Uni Do afs@localhost
Viacheslav Shkarupin ISF slava@localhost
Milan Sterba Prague Univ. of Economics Milan.Sterba@localhost
Tim Streater DANTE t.c.streater@localhost
Oleg Tabarovsky ROSNIIROS olg@localhost
Pantelis Tzortzakis FORTH pantelis@localhost
Marten Terpstra RIPE NCC marten@localhost
Geza Turchanyi RIPE NCC geza@localhost
Bernhard Tuy RENATER Bernard.Tuy@localhost
Cristina Vistoli INFN Vistoli@localhost
Ruediger Volk Uni Do, DE-NIC rv@localhost
Hans Werkman Unisource address supplied
Marcel Widget SWITCH wiget@localhost
Dick Wiersma PHILIPS C&P wiersma@localhost
Wilfried Woeber UniVie - ACOnet woeber@localhost
- 25 -
Appendix 2 - List of Open Action Items
- 26 -
Action: 15.10 Daniel Karrenberg
To propose new tags "created" and "assigned" to the database working
group for consideration - pending.
Action: 16.6 Daniel Karrenberg
Why return unused IP address space and be a good network citizen.
Daniel to find volunteer to continue the work.
Action: 16.18 NCC
Try to actually get the synchronisation of the various database
going, using the recently agreed DB Exchange Format.
Action is dependant on the NIC handle - pending.
Action:17.1 Glenn Kowack
Volunteered to write a paper for discussion which would focus on
a future funding model for the RIPE NCC.
Action:17.7 Wilfried Woeber, NCC
To produce the necessary documentation for the new DB software.
Action: 17.8 NCC
To update and re-circulate the RIPE-Handle proposal and then go
ahead with the implementation.
Action: 17.11 NCC
Investigate and propose a syntax-checking facility for the new
database software.
Action: 17.15 NCC
Propose and implement a mechanism to properly keep track of
individual updates of objects and automatic merge/ modification
operations.
Action:17.17 Bernhard Stockman
Draft a new version of the EEPG Terms of Reference and distribute
this on the mailing list ASAP.
Action:17.18 Bernhard Stockman
Draft a new version of the EEPG Workplan and distribute this on
the EEPG mailing list ASAP.
Action: 17.20 Oleg Tabarovsky
To collect data on external lines and restrictions applying to
each line that will form part of the Russian backbone. Send details
to oleg@localhost
Action: 17.21 Rob Blokzijl
Summarise in a paper discussions on RIPE re-org and publish before
next meeting.
Action:18.1 Daniel Karrenberg
Convey RIPE's concern at the disparity in criteria with respect to
IP network number applications to the InterNIC.
- 27 -
Action:18.2 NCC
Draft new standard European Internet Network Number Application
Form (formerly ripe-107) in light of recommendations from the
working group.
Action:18.3 NCC
Investigate monthly publication of error files on reverse zone files,
similar to the host count error files.
Action:18.4 Mike Norris
Initiate discussion w.r.t the funding and charging for the service
of a Local IR on the Local-IR discussion list and aim to summarise
the discussions by way of a draft recommendation.
Action: 18.5 Wilfried Woeber
Post the CEEnet Initiative maps to the RIPE FTP server.
Action: 18.6 NCC
Set-up a mailing list for the connectivity WG.
Action: 18.7 Elise Gerich
To supply a list of keywords allowed that can be used when
querying the database.
Action: 18.8 NCC
Fold in comments from routing-wg to the ripe-81++ draft, send to
RIPE list and release final version - June 28th.
Action: 18.9 Cristina Vistoli, Ewald Jenisch, Michael Ernst (Hans Frese)
To convert from ripe-60 to ripe-81 before July 1st, 1994.
Action:18.10 Francis Dupont
Circulate a proposed new domain object with the list of attributes
necessary, marking others optional, maybe obsolete them in the future.
Update to RIPE-049.
Action: 18.11 NCC
Put A. Romao's paper "Taking Care of your Domain" into the RIPE
document store as a RIPE document.
Action: 18.12 Erik-Jan Bos
Set up Workplan, Terms of Reference and Euro-FAQ, to be send to the
mailing list. Tony Bates said he could help EJB on the FAQ.
Action:18.13 Erik-Jan Bos
Send to the mailing list where to find the worldwide PS file (done
through these minutes).
Action: 18.14 All members of the Mbone WG
See if there is a local Mbone mailing list in your country, if not,
create one and add this list to the European list, so that European
information is passed on.
Action: 18.15 Erik-Jan Bos
- 28 -
Start up a central European Mbone FTP server.
Action: 18.16 Everyone in the Mbone WG
Send in your Mbone maps to Erik-Jan Bos.
Action: 18.17 RIPE Chairs
Promote a more aggressive "outreach" programme io introduce and
encourage new service providers to join RIPE.
Action: 18.18 RIPE Chairs
Continue the RIPE restructuring discussions on the new-ripe@localhost
mailing list focusing on restructuring the technical work of RIPE.
Action:18.19 RIPE Chairs
Develop a draft model for "new-RIPE" by the next RIPE meeting in
September, with the final report ready by January meeting in 1995.
|
you are here: RIPE -> RIPE Maillists > Archives
