Local IR minutes, 29-30 Jan 1996
Mike Norris mnorris at dalkey.hea.ie
Mon Feb 12 09:38:29 CET 1996
Lo and behold, the Local IR minutes which Anne had produced
ages ago, but which got delayed by....
...your humble servant,
Mike Norris
Local IR working group
Minutes RIPE 23
Amsterdam, 30th January 1996
Chair: Mike Norris
Scribe: Anne Lord
At the working group meeting there were 111 attenders.
1. Preliminaries
A scribe was volunteered :) and the agenda which was previously circulated
to the Local IR mailing list was agreed with some modifications to the
order of the discussion. The minutes will reflect the order in which items
appeared on the agenda.
2. RIPE 22
2.1 Minutes
The minutes of the 22nd RIPE meeting had been circulated shortly after that
meeting to the Local IR mailing list for comment and minor corrections
were made to the text. The minutes were then accepted.
2.2.Review of actions
Action 21.3 on Daniel Karrenberg, Mike Norris
To draft a recommendation on charging by local IRs until September.
Action is still open. A first outline had been written but needed
further study and elaboration before a draft would be sent to the list.
Action 22.1 on Mike Norris and RIPE NCC
To find volunteers from the Local IR working group to
continue working on the revision of ripe-104++ without
waiting for the publication of rfc1466++.
This action was closed. In addition to the RIPE NCC, the members of the
editorial committee were:
Mike Norris
Wilfried Woeber
Sabine Dolderer
Hans Petter Holen
Holger Weinhardt
Janos Zsako
3. Reports from registries
3.1 European Regional Registry (RIPE NCC)
As the formal report from the European IR was presented in the RIPE meeting
plenary, the report to the working group was brief. The shortened report
was as follows:
* there are now 308 local IR`s.
* the predictions for the workload for 1995 were accurate.
* new staff are now fully trained.
* the "wait" queue is now empty ("wait" queue is non-assigned requests).
* approximately one new registry per working day is now being signed up.
3.2 Other Registries
There were no comments from other local registries.
It was suggested that this might be a good opportunity to organise a
local IR workshop in conjunction with the next meeting. There was
consensus within the group that this should not be organised in parallel
with the EOF meeting. An action item was taken on by the RIPE NCC.
Action: RIPE NCC
To organise a Local IR workshop in conjunction with RIPE24.
4. Registry Procedures
4.1 European registries - ripe-104++
The draft document "European Internet Registry, Policies and Procedures"
(ftp://ftp.ripe.net/ripe/drafts/ripe-104++.{txt,ps} was previously circulated
to the Local IR mailing list for comment. There has been and still was
considerable discussion on the mailing list. Within the working group the
aim was to isolae the salient points and to resolve any differences of
opinion so that consensus could be agreed and the document progressed.
The following points were discussed:
Assignment procedures
VSE's
- - It was commented that the assignment procedures are too complicated for
VSE's. The common situation being one or two externally facing hosts and
the rest behind a firewall. It was suggested that the end customer does
not necessarily have to complete a network number application form in such
cases, but the information might be collected by the Local IR. The
important point is however, that the information is archived.
PI/PA address space issues
- - There was a discussion about PA (Provider Aggregatable) and PI (Provider
Independent) address space. If your customer insists, PI address space
can be allocated. Local IR's can apply on a per case basis for PI address
space from the EU IR or they can apply for a PI block. As specified in
ripe-127, there will be no guarantees over the routability of such blocks
assigned and using such address space is *strongly* discouraged.
- - It was also suggested that ripe-104++ could include a sentence to strongly
recommend that ISP's/Local IR's should *not* accept PA address space from
new customers which is outside their own CIDR address space. This was
agreed.
- - There was a question about the existing allocation registration information
in the RIPE database. It was agreed that unless a contractual arrangement
existed with the customer, assignments in the RIPE database without the
"status" attribute marked as PA are considered PI (Provider Independent).
If local IR's can make such contractual arrangements retrospectively, then
such allocations can be considered PA and marked as such. Agreed.
- - Assignments of address space are only valid as long as the assignment
criteria under which the original addresses were allocated are still true.
Agreed.
- - It was suggested that the assignment messages from the RIPE NCC could be
made clearer to reflect the significance of the PA assigned address space.
Renumbering
- - There was some discussion around the procedures for renumbering.
It was agreed, that this would be encouraged by making the procedures
as easy as possible for those who had agreed to renumber and words to the
effect that the size of the previous assignment would not be questioned
unless the efficiency was extremely low.
Reservations Policy
- - It was agreed to base assignments on a 2 year plan from the requestor.
No reservations policy was endorsed.
Static assignments for dial up
- - The document strongly discourages the use of static IP assignments for
dial up service. Strongly discourages means that if a strong technical
reason is given and accepted, then assignments will be made for a vastly
shortened time scale - 3 months was mentioned.
Assignment window anomaly
- - The largest current assignment window for any local IR is /19 -1. This
refers to the amount of address space that they can assign without
referring first to the RIPE NCC. The proposal in ripe-104++ was to
reduce this to /20. After some discussion and by way of compromise, it
was agreed to make the new maximum /19 rather than /20. However, for
every local IR with a /19 -1 assignment window, the current value of
it's assignment window will be set to /20, with the understanding
that it can be increased to a /19 based on the usual criteria (as
specified in ripe-104++). It was agreed that this would come into
effect immediately after the meeting.
Work remaining on ripe-104++
Sections 5,6,7 and 8 remain to be drafted. Section 5 will be drafted shortly
after the RIPE meeting when the editorial committee meet and the draft will
be circulated to the list shortly after the meeting.
5. Registry services and charges
5.1 RIPE NCC charging model
The contributors committee had agreed on a charging model for 1996. All
documents relating to the Contributors Committee meetings and revenue
and expenditure documents can be found in:
ftp://ftp.ripe.net/ripe/new-registry/ncc-co/
5.2 Charging by local IR's
As reported under item 2.2 a draft outline had been prepared.
The reviewed document will be circulated to the mailing list after the
RIPE meeting, once it has been reviewed and edited. The main emphasis
of the document is that it is acceptable practise for Local IR's to
charge for their services. There will probably also be some wording
included to the effect that any remaining Last Resort Registries should
not charge for profit.
6. Tools
All Local IR's were encouraged to make any tools developed for local use
available to the wider community if they thought that they could be
useful to others. The RIPE NCC offered to "house" these tools and make
their location visible.
7. Input from other Working Groups
7.1 DNS
Ripe-105 will be incorporated into ripe-104++.
7.2 Database
A proposal was made to the Database WG mailing list to incorporate
the functionality of <auto-inaddr at ripe.net> into the general database
update procedure. In future, it was proposed that in-addr updates could
be sent to <auto-dbm at ripe.net> with a special tag which could be something
like "INADDRREQUEST".
8. AOB
8.1 Reverse delegation of networks for partially assigned class B networks
There was a question about in-addr.arpa delegations for assigned portions
of class B address space. It was suggested that either you could ask the
Internic to delegate 128 zones to the Local IR or to channel this request
through the RIPE NCC. It was suggested that it might be useful to include
a reference to this in ripe-104++.
Action: RIPE NCC
To include a paragraph on procedures for the reverse delegation of partially
assigned class B networks.
8.2 Handing back of networks from block 192.0.0.0/8
In a mail of the PIER working group it was proposed that by 1997
users of non-aggregatable 192 address space should consider renumbering.
There was a question concerning where 192 address space should be
returned to. It was suggested to return it to the RIPE NCC in all cases,
and the RIPE NCC will handle it as appropriate. Any queries can be
sent to the RIPE NCC <hostmaster at ripe.net>.
[ lir-wg Archives ]