Minutes of mtg at RIPE 21
Mike Norris mnorris at dalkey.hea.ie
Tue Jun 13 12:08:50 CEST 1995
RIPE Meeting 21, Rome
May, 8-10th, 1995
Chairman: Mike Norris
Local IR Working Group Minutes
Agenda
1. Select scribe
2. Agree agenda
3. Minutes ripe meeting 20
4. Actions outstanding
5. Reports from registries
- local registries
- RIPE NCC
- global coordination
6. Charging for services
- report of position for 1995
- billing procedures
- model for future years
- ticketing system
7. Training of (new) registries
8. Tools
9. Others
- ripe-104
- database issues
- reverse domains
10. AOB
1. Select scribe
The meeting was held in two sessions, on 8th and 9th May 1995.
Mike Norris, chairman of the WG, presided. Mirjam Kuehne kindly
volunteered to take a record of the proceedings. There were about
110 people in attendance.
3. Agree agenda and
4. Actions outstanding
Referring to the minutes of RIPE 20, it was noted that all actions for
the working group had been completed.
5. Report from registries
5.1. Global Registries
Mike Norris reported on a meeting of the three regional
registries (RIPE NCC, APnic, InterNIC) held in January 1995
in Amsterdam after the last RIPE Meeting. Mike Norris attended
this meeting as a representative of the local IR's in Europe.
His report was sent to the local-ir mailing list at 29 Apr 1995.
This meeting and another held in San Diego confirmed the good
working relations and close cooperation between these registries
at worldwide level.
Daniel Karrenberg reported that procedures and criteria
were being harmonised. The three regional registries are
singing from the same hymn-sheet, and contacts between
them were being intensified.
5.2. NCC
Daniel Karrenberg reported on the activities of the RIPE NCC
as the regional IP registry for Europe. A big change had been
the introduction of a ticketing system to track transactions.
He outlined the formalities this system required of people
mailing queries to the NCC and urged all to read ripe-183
where these were documented.
Daniel Karrenberg gave some reasons for the introduction of a
ticketing system at the RIPE NCC:
- Since the RIPE NCC receives more and more requests multiple
hostmasters work on one mailbox. The ticketing system helps
coordinating this activity.
- Sometimes aditional information is sent by the requestor and not
by the local IR that sent the requests originally. Ticketing system
helps tracking requests.
- Statistics will be included in the ticketing system that shows how
long a requestis pending and why. This is not implemented yet.
- Ticketing system can help supporting the model of usage based charging.
Another new prodecure has been introduced at the RIPE NCC:
the Reg ID that every registry is assigned must be mentioned in every
request sent to the RIPE NCC, preferably in the form of
X-NCC-RegID: regID. Please read ripe-183 for more details.
Currently ticketing is still done by hand, but it will soon be
overtaken by a robot. This requires strict adherence to the new
formats. If the registry ID is not mentioned in a request sent to
the RIPE NCC the ticketing procedure has to be done manually. This
will produce delay in processing the request.
A new request can be sent with a new ticket line:
NCC#new-request-number
This is not specified yet in ripe-183.
*Action Daniel Karrenberg: Daniel Karrenberg will specify exact format
of NCC#new-request-number and send it to the local IR mailing list.
Details of growth in the activities of the NCC and of the
Internet in Europe would be reported to the plenary session.
Daniel Karrenberg reported the current staff situation at the
RIPE NCC. He noticed a tremendous increase in number of registries
and requests. Unfortunately there is not the same increase in the
number of staff. But in June Hatice Kuey will join the RIPE NCC as
Junior Hostmaster staff.
5.3. Reports from Local Registries
No workshop has been organised between local IR's before the RIPE
Meeting as usual. None of the present local registries had a report
about unusual occurencies in the registries.
Daniel Karrenberg mentioned a problem that occured with requests
from large organisations that had large address space assigned in
the past. These assignments were justified by the number of subsidaries.
The address space was meant to be distributed among the subsidaries.
The situation has often changed so that the subsidaries do not
receive address space from the mother organisation and submit requests
for address space to local IR's or directly to the RIPE NCC.
Daniel Karrenberg suggested the following procedure:
Ask the subsidary to provide a letter (or e-mail) with a statement
that no address space can be received from mother organisation
and why.
This could help to ask address space back from mother organisation
since original conditions are not held anymore.
Daniel Karrenberg said he understands problem for provider to refuse
address space to customers but the community needs to avoid that
organisations are stockpiling addresses. The RIPE NCC wants to know
where addresses are and if they are used. Maybe addresses can be asked
back in the future when we run out of address space.
6. Charging for Services
Details of commitments and payments for NCC services in 1995
were circulated. Daniel Karrenberg said that the problem of
contributions from EUnet constituents had been resolved. This,
together with natural growth in the number of new registries, meant
that the current financial position was quite healthy, with 67% of
the budget for the year already banked after four months.
*Action Daniel Karrenberg: to put billing information in the database.
The meeting discussed charging arrangements for 1996 and
subsequent years. In September 1994, the RIPE NCC Contributors'
Committee, representing the paying customers, had decided that
from 1996 onwards, charging should be related in some way to the
volume of service provided. The Committee would meet again in
September 1995 to agree on a charging model, which would be
prepared by the NCC and discussed on the list beforehand.
It was agreed that the model should be transparent, with
subscribers being able to find out what their bills were going
to be. Automated transactions would not be counted for billing
purposes. The fixed charges for small, medium and large
subscribers would probably account for 50% of the budget in
order to provide for financial stability and continuity.
*Action Daniel Karrenberg and Mike Norris: to draft a recommendation on
charging by local IRs until September
The RIPE NCC will restart the publication of Quartely Reports. Production
has been simplified.
Questions:
Q: Do last resort registries run by EUnet remain?
A: Yes, but RIPE NCC will watch carefully that addresses are really
assigned as last resort.
Q: What is the difference between the prices on the list?
A: Different prices for different sized registries; registries determine
their size themselves. The size and the price is published and can be
seen and compared by all registries. Size can be changed over the time.
Q: Some registries have higher billing/income than committed.
What does this mean?
A: These are new registries and the sign-up fee is added in the income column.
Q: How is the time-permitting procedure working (has it effect)?
A: Is works excellent!
Q: How long is the delay?
A: Technically the RIPE NCC maintains two queues of requests (normal-service
queue and time-permitting queue). Hostmasters can proceed with a request
in the time-permitting queue when the normal-service queue is empty.
This has not happen too often (not at all).
Q: How much resources take referrals to service providers?
A: The RIPE NCC doesn't advertise itself as such a service and doesn't
answer end user questions in general. When the RIPE NCC receives requests
for service providers, requester will be pointed to the ip-provs
mailing list. We should continue doing this. This does not require
too much resources. We don't spend local IR's money to provide
consultancy for customers of the competitor.
Q: If RIPE NCC could publish referral information, this would relief the
NCC.
A: Referral service is not a problem yet. The RIPE NCC receives 2 of such
questions per week. When it becomes a remarkable amount of time, we will
find a solution.
Q: Couldn't we take the amount of e-mail messages registry sends to
the RIPE NCC as indicator for usage based charging?
A: This is not such a good idea. It discourages registries to ask questions.
What, if the RIPE NCC has a question about a request and the registry
sends the answer back, should they be charged for this message? No.
Q: Shouldn't we improve a model that combines the size of a registry with
with the usage?
A: This is a good idea.
Q: Couldn't we take inetnum objects in DB as criteria?
A: This could also be a possibility.
Q: What is the current relation between the RIPE NCC and TERENA?
A: The RIPE NCC is still under the umbrella of TERENA. Staff of RIPE NCC
is employed by TERENA. But the NCC does all dealings with the registries
on its site, apart from the real billing process.
We pay 10,000 ECU to TERENA for administrative work.
current problem: TERENA is shrinking, RIPE NCC is growing, problems with
hiring more staff.
Q: Can local IR charge customer for their services? If yes, who has
implemented it?
A: Yes, local IR's can charge for their services. The RIPE NCC does not know
who has implemented it, since no registry informs us about it.
Note: It is only allowed to charge for services, it is not allowed to
sell address space!
Q1: Should the RIPE NCC publish a document with charging recommendation?
Q2: Should the RIPE NCC publish a list about charging registries?
A1: Yes, some recommendations would be useful: For what services can be
charged and for which not; helping with the right language.
A2: No, this is not a good idea. This could be interpreted as selling
addresses.
7. Training
On the last ncc-co meeting was agreed to produce a training course to
help new registries to fulfil their function as Local Internet Registry.
This was coppeled with the charging model: New registries pay a sign-up
fee that will be used to produce such a course. But while the course were
intended primarily to help new registries, "old" IRs were welcome to
attend if places were available (those registries that have payed sign-up
fee will be preferred).
Mike Norris encouraged all registries to avail of this valuable training/
re-training resource for their staff. A lot of procedures and guidelines
have changed in the past.
The RIPE NCC has started in March to produce a training course. A project
framework has been published to the local-ir mailing list. Some help and
input has been offered to the RIPE NCC. Anne Lord and Mirjam Kuehne are
running the project. They are currently busy to prepare the course.
Please note that they have only two hours per day to do so. The first
course will be held at 26 June 1995 and a training guide would soon
be published. After this first course as much course as necessary will
be held. The RIPE NCC is also prepared to give courses abroad, when
enough registries come together in one country.
8. Tools
The monthly host count condicted by the NCC had been further
delegated, with sixteen European top-level domains now doing
the count locally and making the results available to the NCC.
The NCC had refined existing tools in order to analyse the
reverse DNS for IP networks in European blocks. The results
showed a very poor picture, with low coverage and lots of
errors. People were urged to avail of the tools and to try
to improve the situation.
8.1. Geert Jan de Groot produced tools that check for errors in reverse
delegations and complains if they sustain for a week or more.
The tools are available at:
ftp://ftp.ripe.net/ripe/local-ir/{inaddrcount, revcheck}
8.2. David Kessens from the RIPE NCC has written a tool to automize
requests for reverse domain delegations. It checks the zone that
asks for reverse delegation and produces a fairly long output
containing all errors found. The requests sent to the RIPE NCC
still contain 70% errors but usually the errors are removed at
the second time the RIPE NCC receives the request (that was not
always the case in the past). The output that is send back to the
requestor helps to correct the request and the zone. The tool is
still in the test period at the RIPE NCC. After it is stable, it
will be published.
9. Other Issues
9.1. ripe-104
Daniel Karrenberg has circulated his draft about VSE's again.
He also reported on the current discussion about address space
allocation and assignment procedures: On the IETF has been agreed
to distinguish between two different kinds of address space:
- provider agreegatable address space (PAS)
- povider independent address space (PIS)
Daniel Karrenberg summarized other topics in the current discussion:
The exhaustion of IPv4 address space is not the main problem. The
main issue is the growth of the routing tables.
On average there are 4000 hosts per route. This shows that CIDR works,
but still not enough. Some routers begin to fall over.
Service Provider and local IR's should only use and assign PAS
(see draft from Yakov Rekhter:
ftp://ftp.ripe.net/internet-drafts/draft-ietf-cidrd-ownership-01.txt)
The current debate mentiones sizes of address space for PIS and PAS:
smaller and equal than /19 (32 C's): PIS
greater than /19 (32 C's): PAS
This discussion delayed the revision of ripe-104.
The providers should decide what prefixes they will route and for
what price. It should not be the regional registrie's task to make
this decision. The registries should clarify the implications of PIS
and PAS but not regulate.
Daniel Karrenberg has written a draft that lists the possible
implications: If customers receives PAS they may have to renumber when
they change service provider. If they receives PIS the addresses might
not be routable in the future. There must be a clear contractual
agreement between customers and registries, when registries assign PAS.
The IANA has been asked to circulate this draft.
Questions, Comments:
Suggestion: RIPE should provide recommendation about prefix length. It
is not clear yet where the boundary between PIS and PAS will be
(/19?). PAS must be easy to renumber (rather short prefix). But this
issue needs more discussion in the Local IR group.
Comment against recommendation: The recommended prefix length will probably
change over the time. A recommendation would produce false security.
DFK: This has to be clear in the recommendation.
Q: Problem with large multinational organisations that contact varies
last resort registries to request address space. A clear statement
or recommended guidelines from RIPE is needed.
A: The basic principle is already included in ripe-104:
If the multinational organisation is connected only in one place,
addresses should be received from this one service provider.
If the multinational organisation is connected in varies places/countries
it should receive address space from these different service providers.
The problem is rather that it is easier for these organisations to ask
for small amounts of addresss space at different registries than for
a large amount of address space at one place. It is easier to provide
an addressing plan for small parts of a network than for the whole
network. There is no clear procedure how this can be prevented apart
from being careful and asking carefully for detailed documentaion.
Q: Can't the RIPE NCC make a clear recommendation that these kind of
organisations should contact the RIPE NCC for address space?
A: There are clear guidelines in ripe-104:
4. Organisations operating a network which spans several countries
may obtain address space from a service provider, the RIPE NCC,
or the global NIC, as is appropriate to their network confi-
guration. In many cases it will be best to obtain addresses
for the whole network from the provider operating the main
connection of the multi-national network to the Internet. When
in doubt, contact the RIPE NCC for guidance.
9.2. DB issues
On the last RIPE Meeting it has been agreed that the technical
contact in an object can also be a role, e.g. a NIC instead of a
person. Harvard Eidnes has written a draft about tyhis issue and
circulated to the local-ir mailing list in advance to the 21. RIPE
Meeting.
9.3. Reverse Domains
The group endorsed the recommendation of the DNS WG that the
reverse domains of connected IP networks be name served.
*Action Mirjam Kuehne and Anne Lord: to incorporate strong recommendation
regarding reverse DNS in training materials.
------- End of Forwarded Message
[ lir-wg Archives ]